Remote AP's fail to connect to controller

[Craig_Sakach]

This is my first time working with Extreme Networks equipment so excuse any lack of knowledge I may have on these products.

The clinic I work for has 3 locations connected via WatchGuard Remote Office VPN. Subnets are as follows with the WatchGuard firewalls doing the routing:
Main Office: 172.20.1.0/24
Remote Office 1: 172.20.2.0/24
Remote Office 2: 172.20.3.0/24

We have a C25 Controller running v09.12.01.0067 located at the Main Office with IP 172.20.1.25.
We have 13 total AP-3825i AP's with 9 at the Main Office, and 2 at each Remote Office.

The Main Office has a Microsoft DHCP server and the Remote Office's get their DHCP addresses from their respective WatchGuard firewalls.

A security firm has control of the WatchGuard firewalls so I don't have direct access to their configuration and I'm not sure if the WatchGuard supports option 43. Because of this, it is why I took the following steps;

I installed the AP's at the Main Office and they connected up to the controller and are working beautifully! Because I couldn't add the Option 43 to the remote WatchGuard's, I connected the 4 Remote Office AP's to the Main Office network so they would obtain a DHCP address and configuration. Once the software was upgraded, I changed the IP's to manual IP's (172.20.2.x and 172.20.3.x) and set the controller IP as well.

I installed the AP's at the Remote Office locations but they show up on the controller as Inactive Local AP's even though I can ping and SSH into each AP from the Main Office. I can also ping the controller from the Remote Office's. This tells me that they are being seen on the network but something is keeping them from connecting to the controller properly.

Any idea's or suggestions is greatly appreciated!

[John_Kaftan]

Also make sure the AP can talk to the controller on UDP port 13910. That is the port that the APs use to connect to the controller.

As for discovery you can add an a record in your DNS for "controller" and point it at your controller. The APs will query DNS for that you won't have to set it statically. The APs will look for the DHCP option first and then do a DNS lookup for "controller" and then do multicast to try and find the mother ship. Not positive on the order but I think that is it.

You can log into your AP to see what is going on. You can do a "cget config global" to get the settings on your AP. Default login for your APs should be admin and new2day.

You can also see what is going on currently in the AP log by doing the following

cd /tmp/log
tail -f ap.log

You can manually set the controller address by doing a

cset authip 1

When things get ugly you can set the AP to factory by doing a

cset factorydefaults

You could also log into your controller and do a tcpdump and filter out for any traffic from your AP to see what is making it to your AP. Let me know if you need help doing that.

My guess is that your firewall is blocking UDP 13910 and not allowing the tunnel traffic through.

[Ronald_Dvorak]

Craig,

could you please set the controller log level to information as this might give us some hints what is going on, you could find the setting in > controller > logs > logs configuration > wireless controller log level.

Then connect the remote AP again ... or reboot the AP via remote and let me know whether you get log messages in the log and which one.
The normal logs for a AP that connect to the controller will look like that...

I think in your case that last one "Blacklist successfully sent..." is missing.
In that case it's a MTU problem = the AP can't discover the MTU on the VPN link.
Just set it in the static AP config to MTU=1300 - if the VPN uses a smaller value try it with a even smaller MTU.

For even more detail what is going on you'd ssh to the AP and go in the /tmp/log directory.
Then do a "tail -f ap.log" to see what the AP is trying to do.

Ron