RED15w Access Point not showing up as pending access point

After some digging and googling, i found a solution for this problem. Thank you Stefan for pointing me in the right direction.

The problem was the DHCP option 234 and the Magic IP broadcast (TCP 2712).

Here are the configuration details (sorry but in german) [:D]

Sophos SG UTM – RED15w als Bridge Device einrichten, inkl. Wireless.

Von Bytecom 13.09.2016

Bei der Verwendung von Sophos RED15w im selben LAN Segment gibt es einige speziellen Konfigurationseinstellungen die beachtet werden müssen. Dies betrifft, neben dem korrekten Bridging, auch die Freischaltung der Magic IP für die Access Points der RED15w.

Anforderungen:

• Sophos UTM 9.4x,
• DHCP Server mit gültigem und aktivem Bereich im entsprechenden LAN Segment.
• RED15w Devices

Quellen:

• www.nudelsuppen.com/sophos-utm-red-als-bridge-device-einrichten
• ictschule.com/.../
• community.sophos.com/.../119131

Schritt 1) In der Sophos UTM RED Management aktivieren

Schritt 2) Daten korrekt ausfüllen

Schritt 3) RED manuell hinzufügen und nicht mittels „Server Deployment Helper“

Folge Daten ausfüllen:

• Branch Name: z.b. welche Außenstelle
• Client Type: Welcher Typ RED (z.b. RED 15w)
• RED ID: Seriennummer der RED
• Tunnl ID: Automatic
• Unlock Code: Wird nur benötigt falls die RED schon einmal konfiguriert wurde. Falls es sich um eine neue RED handel bleibt das Feld leer.
• UTM Hostname: Name (z.b. remote.demo.ch) der Sophos UTM oder IP-Adresse. Muss von extern übers Internet erreichbar sein. Keine interne IP!
• Uplink Mode: Wie soll sich die RED verhalten, in unserem Fall Standard / Unified.

Schritt 4) Unlock Code notieren! Ansonsten kann die RED nicht mehr auf einer anderen Sophos UTM neu konfiguriert werden.

Schritt 5) Geduld haben!!! Die RED kommuniziert nun mit der Sophos UTM und konfiguriert sich. Sollte z.b. ein Firmware Update anstehen erledigt die Sophos UTM dies automatisch. Nicht wundern, wenn die RED einige Male neu startet. Auf der RED sollten nach einigen Minuten folgende Lampen konstant grün leuchten: Power, System, Router, Internet und Tunnel.

Schritt 6) RED und Internes Netzwerk verknüpfen (Bridge erstellen). Unter „Interface & Routing“ –> „Interfaces“ das interne Netzwerk editieren. Das interne Netzwerk wird meist mit „Internal“ bezeichnet.

Bei „Type“ den Netzwerktyp „Ethernet Bridge“ auswählen und beide Schnittstellen (eth0 und alle mit reds bezeichneten Schnittstellen) aktivieren. Unter „Advanced Bridge“ den Punk „Allow ARP broadcasts“ aktivieren. Mit „Save“ das ganze speichern.

Schritt 7) Firewall-Regeln und Definitionen erstellen! Damit die DHCP-Anfragen von der Bridge weitergeleitet werden, muss man die Paketfilterregeln anpassen. Beim DHCP-Request wird folgendes Paket erzeugt: Source: 0.0.0.0 Source-Port: 68 Destination: 255.255.255.255 Destination-Port: 67.

Eine weitere, wichtige Regel für das Magic IP Packet (Auffinden des WLAN Controllers durch die RED Access Points) muss zusätzlich erstellt werden (TCP 2712).

Neue Netzwerk-Definition anlegen:

• Name:              any internal
• Type:               Network
• IP V4 Address: 0.0.0.0
• Netmask:         0.0.0.0
• Name:              Broadcast all
• Type:               Network
• IP V4 Address: 255.255.255.255
• Netmask:         32/255.255.255.255

Service Definition erstellen:

• Name:                          DHCP
• Type:                           UDP
• Destination Port:         67:68
• Source Port:                 67:68
• Name:                         MagicIP
• Type:                           TCP
• Destination Port:         2712
• Source Port:                 1:65535

Firewall Regeln hinzufügen:

• Name:              RED Bridge Broadcast
• Position:          tbd
• Sources:           any internal
• Services:          DHCP und MagicIP
• Destination:     Broadcast
• Action:             Allow

Für die weitere interne Kommunikation zwischen Außenstelle und Zentrale muss man nun noch weitere benötigte Regeln anlegen z.B. im Windows-Netzwerk:

• Name:              RED Bridge Traffic
• Position:          tbd
• Sources:           internal(Network)
• Services:          z.b Windows Network, HTTPS oder any je nach Bedarf.
• Destination:     internal(Network)
• Action:             Allow

Regeln noch aktivieren!!!

Schritt 8) Nun muss der RED über DHCP noch mitgeteilt werden, wo genau sie der WLAN Controller (UTM) befindet. Sobald ein Sophos Accesspoint am Netzwerk angeschlossen wird, versucht er Kontakt mit der Sophos UTM aufzunehmen. Dazu schickt er eine Anfrage an die Adresse 1.2.3.4 über den TCP Port 2712. Da die Adresse 1.2.3.4 im internen Netzwerk nicht existiert, wird sie weiter nach “draussen” geroutet, bis beim Übergang zum Internet die Sophos UTM als Firewall und Gateway die Abfrage selber bearbeitet, statt weiter ins Internet zu leiten.

Falls es hier aufgrund von Routern oder VLAN’s zu Problemen kommt, da sie selber als Gateway funktionieren, kann sich der RED Access Point nicht an der UTM registrieren.

Sofern ein Windows Server das Netzwerk mit IP Adressen versorgt, kann man dort die Serveroption 234 erstellen und entsprechend konfigurieren. Diese Option teilt dem DHCP Client mit, wo sich der WLAN Controller befindet. (community.sophos.com/.../56424)

Dazu im Windows DHCP Manager, eine Vordefinierte Option erstellen: (DHCP Server Name, rechte Maustaste, Vordefinierte Optionen erstellen…)

• Klasse:             Global
• Name:              z.b AP Sophos
• Datentyp:         IP-Adresse
• Code:               234
• Beschreibung:  AP zu UTM

Mit OK bestätigen, auf der nächsten Maske:

• Optionsklasse: DHCP Standard Options
• Optionsname:  234 AP zu UTM

Mit OK bestätigen.

Nun nur noch in der für den AP gültigen DHCP Bereich eine Bereichsoption erstellen.

• 234 AP zu UTM auswählen und unter IP Adresse die interne IP der UTM eintragen.

Sobald sich die RED’s beim nächsten DHCP Handshake beim DHCP melden, bekommen sie diese Option mit und finden auch die UTM im Netzwerk.

Die RED kann nun am Zielort eingesetzt werden. Am Zielort muss sich bereits ein Internetrouter befinden. Die RED muss dort per DHCP eine IP-Adresse und Default Gateway erhalten, damit sich die RED zum RED Provisioning Service (RPS) verbinden kann und von diesem die Config bezieht. Nach dem Erhalt der Config startet die RED neu und verbindet sich zur UTM. Die RED Kommunikation läuft über TCP/UDP Port 3400.

This is not an answer to the initial questions 

to understand you right, RED15w is running fine, but you're also do not see the RED's AP in den Controller as pending AP?

Do you run the RED in bridge mode?

I saw it in the past. But somehow, it changed to inactive one day and i did not get it back to active.
First i tried to delete the access point and restarted the RED15w. But the AP wasn't showing up again.
So i decided to completly remove my RED15w configuration including interfaces, SSIDs, rules, etc.

After adding the RED15w again, the SG 550 is still not showing any pending access points. 

The RED15w is sitting behind a cable modem.

ok, check your firewall rules between your RED and the internal network (include TCP 2712). Is the RED in a seperate network segment? If yes...have you add this network tho the allowed networks in Wireless Protection? (Wireless protection - Global Settings)

If you are using the RED in the same network segment (bridged with the internal network), does the RED receive an IP address from your DHCP server?

ok, check your firewall rules between your RED and the internal network (include TCP 2712).

The rule is set to Any, ping and TFTP from/to Campus LAN to/from RED interfaces. There are no drops from Firewall Log.

Is the RED in a seperate network segment? If yes...have you add this network tho the allowed networks in Wireless Protection? (Wireless protection - Global Settings)

Yes it is and yes i did.

I will try to use a different internet access (maybe UMTS) and i will try to connect the RED to my home UTM.

Same with failover via UMTS. But it is working at my home UTM (i can see the pending AP).

Now i have to find out the difference between my home UTM and the office UTM. Both are on latest update version.

have you checked this? https://community.sophos.com/products/unified-threat-management/f/60/t/56424

I am really confused now.

As i said earlier, the AP function works fine, while connected to my Sophos UTM Home Edition. I have checked every setting at home (with scrrenshots) for another try at work.

I have added the RED15w to my SG 550 like i did yesterday, but now with the new unlock key, which do-not-reply@red.sophos.com sent me, and everything works like expected. 

have you checked this? https://community.sophos.com/products/unified-threat-management/f/60/t/56424

I don't know, in which case this would concern me. The AP was recognized with DHCP enabled on SG 550 and with DHCP relay to a Windows Server - which i prefer an which i am using for all networks.

Now i have to find out, why the AP was listed as inactive, why it won't show up at all after removing the RED from the UTM and how i can get an AP back to active without moving the RED to another UTM and back again. Maybe its about certificates which may stay remaining in the UTM until the RED was connected to another UTM. 

Hi Christian

I've got exactly the same Issue/ Problem which you described.

The only difference: If I delete the Red15w, connect it to another UTM (which changes the unlock code), delete it there and connect it to the first UTM again (which again changes the unlock code), it does NOT appear in the pending APs again :-(

The history was the same: It appeared at "Pending Access Points" the very first time I connected it. I authorized it joining an existing AP-Group and after that it changed to be an "Inactive Access Point" with an exclamation mark on the icon. I couldn't make it changing the behavior with changing the configuration -> so I deleted it, waiting for it to appear again.

Is there anything else you probably did except for changing the UTM as described?

Every help is highly appreciated ;-)

Cheers, Janbo

Hi, Janbo, and welcome to the UTM COmmunity!

I know that several people have had similar issues with the RED 15w.  You should get Sophos Support involved.  If they can't fix this immediately, you should lean on them to loan you an AP 15 until they find the bug.

If they do fix it, please find out what they did and share it here with us.

Cheers - Bob

Hi Bob

Thanks for welcoming me!

I involved the Distributor's UTM-Support. Finally they gave up and involved the Sophos Support analyzing my UTM-Logs.

Outcome: The WLAN-Configuration which I pushed to the pending AP of the RED15w at the first (and only) time it appeared under "Pending APs", misconfigured the AP and kept sticky in the device. The config I pushed when I assigned the pending AP to an existing WLAN-Config-Group was not very wise because it only could have functioned in the main office where the UTM and the existing APs are located (different VLANs with a tagged management VLAN to be reached by the APs).

The problem (and the bug) seems to be that this configuration stays sticky in the device - independent of the effort you bring up.
With no wanted result you can:

• Restart the RED15w-device (interrupt power locally)
• Restart the RED15w-device (interrupt connection within the UTM by disabling and enabling it again)
• Delete the RED15w-device from the UTM and redeploy it via Sophos provisioning service on the same UTM
• Delete the RED15w-device from the UTM and redeploy it via Sophos provisioning service on an different UTM (including the need of using the unlock keys -> AP will not be available on the new/ different UTM neither)
• Delete the RED15w-device from the new UTM and redeploy it via Sophos provisioning service on the old UTM (including the need of using the unlock keys)

So how did I solve the Problem:
Following the recommendation of the Sophos Support:

• Configuration of an VLAN-Interface with binding to the virtual RED-Hardware-Interface
• Configuration of an DHCP in the new environment (that might have been not necessary)
• Assignment of the new network to the "allowed interfaces" under "global settings" of the Wireless protection

And uppps: The AP was available and configurable again -> showing up under "Pending APs" :-)
After proper configuration I could delete all the workarounds.
Now I can delete it and it will show up again immediately in "Pending APs" because the sticky configuration is not important if there is no tagged VLAN configured...

I hope that Sophos will catch up and solve this bug. I reported the whole story to the ALSO-Support to forward it to Sophos.This is the first problem I could solve with the RED15 devices (i have some more) and the first time the Sophos Support was of any value during debugging.
But this also might be unfair and based on the support of the distributor that potentially doesn't involve Sophos close enough - I'm not sure...

This forum might be my rescue in the future -> we will see :-)

Cheers from rainy Hamburg, Germany

Janbo

Hi Bob

Thanks for welcoming me!

I involved the Distributor's UTM-Support. Finally they gave up and involved the Sophos Support analyzing my UTM-Logs.

Outcome: The WLAN-Configuration which I pushed to the pending AP of the RED15w at the first (and only) time it appeared under "Pending APs", misconfigured the AP and kept sticky in the device. The config I pushed when I assigned the pending AP to an existing WLAN-Config-Group was not very wise because it only could have functioned in the main office where the UTM and the existing APs are located (different VLANs with a tagged management VLAN to be reached by the APs).

The problem (and the bug) seems to be that this configuration stays sticky in the device - independent of the effort you bring up.
With no wanted result you can:

• Restart the RED15w-device (interrupt power locally)
• Restart the RED15w-device (interrupt connection within the UTM by disabling and enabling it again)
• Delete the RED15w-device from the UTM and redeploy it via Sophos provisioning service on the same UTM
• Delete the RED15w-device from the UTM and redeploy it via Sophos provisioning service on an different UTM (including the need of using the unlock keys -> AP will not be available on the new/ different UTM neither)
• Delete the RED15w-device from the new UTM and redeploy it via Sophos provisioning service on the old UTM (including the need of using the unlock keys)

So how did I solve the Problem:
Following the recommendation of the Sophos Support:

• Configuration of an VLAN-Interface with binding to the virtual RED-Hardware-Interface
• Configuration of an DHCP in the new environment (that might have been not necessary)
• Assignment of the new network to the "allowed interfaces" under "global settings" of the Wireless protection

And uppps: The AP was available and configurable again -> showing up under "Pending APs" :-)
After proper configuration I could delete all the workarounds.
Now I can delete it and it will show up again immediately in "Pending APs" because the sticky configuration is not important if there is no tagged VLAN configured...

I hope that Sophos will catch up and solve this bug. I reported the whole story to the ALSO-Support to forward it to Sophos.This is the first problem I could solve with the RED15 devices (i have some more) and the first time the Sophos Support was of any value during debugging.
But this also might be unfair and based on the support of the distributor that potentially doesn't involve Sophos close enough - I'm not sure...

This forum might be my rescue in the future -> we will see :-)

Cheers from rainy Hamburg, Germany

Janbo