Fortigate and Ruckus AP remote registration issues across a IPSEC VPN
Posted by on August 15, 2014
Recently I and others have had an issue when using interface based VPNs on Fortigate, and remote Ruckus APs are on the other side of the VPN. For some reason these APs cannot register with the ZD – sometimes they never even show up. I can log into the remote APs, SSH, Web, Ping everything works they will just not register with the ZD.
When I see this the most the client has just updated to Fortinet 5.2 firmware, and is using Interface based VPNs instead of policy based.
Now back to the main goal of the entry – If you are using a interface based VPN with Fortinet specifically you might see your APs come up for a while, then drop. Another symptom I have seen is that you have your DHCP options, and DNS record set for the Zonedirector but the APs never show up. The underlying issue is that the interface based VPN will drop sometimes – the Fortigate may not even report the drop. During this time the the Logical VPN interface is no longer attached to the Fortigate, that means the route you set to push traffic over it to the remote subnet no longer exists. So a UDP session is opened to the internet – since there is no other place to send the traffic to. Once that happens the UDP stays active – Even though it should timeout.
So to fix the issue, Add a service for “Ruckus services” and add UDP and TCP ports 12223, and UDP and TCP port 12222. Then create a policy in the firewall to block traffic going to the WAN on those ports. This will make sure that remote sessions are never created to the internet interface. So if the tunnel drops you will not have to worry about this. You could also just create an address object for your remote subnet and create a policy blocking any traffic matching that object going to the WAN interface.
Here is the policy to block the traffic from leaving the WAN interface
Note – Make sure this policy is above any traffic that would be go from internal – to VPN.
After the policy is created to blog those ports – lets clear the sessions in the firewall. We can do this using the CLI command in the Fortigate:
Dia system session clear
So how did we figure this out? If you do a packet capture on the Fortigate matching the ZD or AP ip addresses, you will see registration attempts trying to go through the WAN interface, even though the VPN is up. Since UDP is connectionless, it never expects a response on the session, so it stays up. If you see the session going through your WAN interface, and your VPN is up, just kill that session. You will see your AP come up very quickly, but the same issue will happen if you don’t make sure the session is never created.
This has fixed the issue for a few clients having this problem.
I want to kiss you .. thank you!!!!
I’ll agree with Matt, can I pay you a beer?
Lost a lot of time with Ruckus trying factory reset and stuff I had already done! 🙂
Plus, it’s a good thing, now I know UDP session can be keep open by the Fortinet, so I can clear them manually.
Thanks! 😀
Thanks!
Thank you! When you come to Brazil we will pay you a beer!
I’m was using FortiGate 5.4.6 and another customer FortiGate 5.2.12. After the new policy with deny, the problem was solved.
All three of the remote APs I’m referring to go through a site-to-site VPN set up between two Fortigates and are in the same physical location, connected to the same switch. All three of them worked great for a couple of weeks and two of them disconnected inexplicably one weekday morning. There were no network changes made. Latency is a fairly steady s from AP to ZD, and of all the test pings I have run I haven’t seen any dropped packets. The APs are mounted very high in a ceiling so I can’t see the lights. I have tried rebooting them with no improvement. There really is nothing different between the three APs, they were all configured identically and have the same firmware. MTU size is 1024. Forgot to add, all traffic is allowed over this site-to-site VPN tunnel and SSHing into the problem IPs they report their status as “sulking.” However, doing a show director returns the correct IP address and pinging the ZD address and DNS name is successful from the problem AP.
I would check to see if sessions could be build to the WAN and not over the IPSEC tunnel. You can clear only your ap-to-zd sessions with a session filter, and then clear those.
I am guessing its a session issue. Whats your ZD IP?
This solved my problem today, thank you very much! Fortigate on 6.2.4 to SonicWALL IPsec BTW in case that helps. Just stuck the deny rule above the VPN rules and was good to go after clearing sessions.
Glad it could help!
I used Ruckus Unleashed, and I have problem AP Master and Slave always up and down. Connection is Ruckus AP connected to Fortigate port direct. So everyone have meet this problem or not? Thanks.