Getting Unifi AP's to be discoverable from a remote site

Hello everyone!

 

I have 2 XG firewalls one here at the office LAN that a unifi controller is sitting on. I have 2 AP's sitting at this location on the DMZ and they are working great. I was able to discover them and attach them to the controller with Firewall rules to allow the DMZ to communicate only to the specific IP that the controller is on. 

 

My problem is my remote location. I have a main LAN and a DMZ. Main LAN is for our corporate network and the DMZ has all of our AP's on it. After A LOT of trouble shooting I finally was able to get the AP to ping the controller and visa versa due to a missing service item in the firewall rules. My setup: (Controller on LAN <--> XG Firewall <--> internet <--> XG firewall <--> DMZ with AP's). The problem is when I SSH into the AP and run the set-inform command in the AP and point it to the controller, nothing happens.Nothing shows up in the devices screen and the network discovery tool cant find them either. Again, It can ping back and forth but cannot discover it. 

 

The biggest conundrum is that this worked previously. Today, we just went from software on a server to a stand alone Cloud key and now its not working. We have factory reset all AP's and installed latest firmware before the inform command and after. The only difference is the IP address of the controller changed.

 

More info: I have ran a Diagnostic from both XG firewalls to capture packets as I do both the pings and the set-inform command and I am not getting any violations. just incoming and forward statuses.

  • Would recommend to buy Sophos APs ;) 

     

    Just kidding, lets wrap this up. 

    You should start to dump this traffic on the CLI. 

    https://community.sophos.com/products/xg-firewall/f/community-corner/114837/sophos-xg-firewall-how-to-tcpdump

     

    Would recommend to draw a little network map with flow chart. 

    Who is connecting to which AP? 

    Then start to follow the packets with tcpdump on both appliances.

    The TCP Protocol has something called Handshake. 

    https://en.wikipedia.org/wiki/Transmission_Control_Protocol

    https://en.wikipedia.org/wiki/Transmission_Control_Protocol#/media/File:TCP_CLOSE.svg

    Which means, A sends a Packet to B.

    B answers this packet to A.

    And A will respond to B for a last time.

    After those three packets, the connection is established. 

    And you should see this in the dumps. 

    Tcpdump considers this as S / S. / . 

     

    If something gets lost in the way, you should be able to figure out, which component is causing this. 

  • In reply to LuCar Toni:

    Thanks for the reply!

    I would love to try out the Sophos APs. This was in place when I got here. 

     

    We use the wireless in both locations as guest access. Everything we need for corporate work is wired. I will give this a try over the weekend and let you know how this goes.

  • In reply to LuCar Toni:

    I have looked at the tcpdump logs over and over for port 8080 (Unifi's inform port for the AP to signal the controller) and port 10001 (Unifi's discovery port) before, during, and after issuing the inform command from the AP. Everything seems like its flowing correctly. I am new to tcpdump so I may be looking at it and understanding it wrong, but I see the path from the AP into the remote firewall IP to the main location public IP and into the controller IP and back. The output says that all packets were sent and received with 0 being blocked.

  • Turns out I was looking in the wrong area. It was a Unifi Problem. The AP's are EOL and the controller software was too new to handle the discovery for the AP's. I had to downgrade the software to get them to work. Not a Sophos problem.