Sophos - DHCP - Vlan IP Zuweisung schlägt fehl

[Campkom]

Hallo. Kurz zur Erklärung eine kleine Beschreibung meines Heimnetzwerkes.

Ich betreibe Sophos als Firewall und DHCP-Server. Sophos ist mit 3 NIC's ausgestattet (WAN, LAN1 -> Hauptnetz VLAN 20, LAN2 -> Gastnetz VLAN 30).
Zu einem zentralen Switch (Netgear GSM 7224) gehen zwei physische Kabel für die beiden VLAN's. Dort sind dann die Ports (außer einem Managementport für das Switch) untagged den VLAN's zugewiesen.





Weiterhin besitze ich 3 TP-Link AP, die zwei SSID bereitstellen, eine für das Hauptnetz und eine für das Gastnetz. Somit gibt es insgesamt 3 Ports am Switch, die tagged beiden VLAN's zugewiesen sind.





Nun zu meinem Problem. Bisher vor kurzem hat alles funktioniert und ich weis nicht, was ich verstellt haben könnte. Sophos stellt weiterhin 2 DHCP-Server für Hauptnetz und Gastnetz bereit.
Das Problem ist nun, dass Geräte, die sich im Gastnetz anmelden wollen keine IP zugewiesen bekommen. Im Hauptnetz, welches analog aufgebaut ist funktioniert alles tadellos. Hier ein Auszug aus dem DHCP-Livelog von Sophos. (192.168.30.x -> Gastnetz)

2019:11:25-23:04:14 ddns dhcpd: Server starting service.
2019:11:25-23:23:09 ddns dhcpd: DHCPDISCOVER from c0:ee:fb:50:ed:16 via eth2
2019:11:25-23:23:10 ddns dhcpd: DHCPOFFER on 192.168.30.50 to c0:ee:fb:50:ed:16 (android-dab49ad0d1d1b171) via eth2
2019:11:25-23:23:11 ddns dhcpd: DHCPDISCOVER from c0:ee:fb:50:ed:16 (android-dab49ad0d1d1b171) via eth2
2019:11:25-23:23:11 ddns dhcpd: DHCPOFFER on 192.168.30.50 to c0:ee:fb:50:ed:16 (android-dab49ad0d1d1b171) via eth2
2019:11:25-23:23:15 ddns dhcpd: DHCPDISCOVER from c0:ee:fb:50:ed:16 (android-dab49ad0d1d1b171) via eth2
2019:11:25-23:23:15 ddns dhcpd: DHCPOFFER on 192.168.30.50 to c0:ee:fb:50:ed:16 (android-dab49ad0d1d1b171) via eth2

Es ist zu sehen, dass Sophos eine DHCP-Anfrage bekommt und die eigentlich auch beantwortet wird. Wieso bekommt dann das Gerät die IP nicht? Ich habe schon mehrere Smartphones und auch Laptops getestet. Mir fällt nichts mehr ein.



Hier noch die Konfiguration der DHCP-Server:

 

[t-6]

Irgendeine DHCP-Guard/Snooping-Funktion am Switch oder in den APs aktiviert? Der Log-Auszug sieht stark danach aus als ob irgendwas die DHCP-Pakete auf dem Weg verschluckt.

Was passiert wenn du einen PC testweise an einen untagged VLAN "Gast"-Port hängst?
Was passiert wenn du einem WLAN-Client mal testweise eine statische IP gibst wenn er im Gast-WLAN hängt?

Zu einem zentralen Switch (Netgear GSM 7224) gehen zwei physische Kabel für die beiden VLAN's.

Sinnvoller wären zwei Kabel mit beiden VLANs auf einem LAG zwischen Sophos & Switch. Ja, SG kann mittlerweile VLANs taggen auf einem untagged Port.

 

[Campkom]

Vielen Dank schonmal für die Antwort.

Der Log-Auszug sieht stark danach aus als ob irgendwas die DHCP-Pakete auf dem Weg verschluckt.

Das denke ich mir auch.... Habe auch nochmal bei den AP's alles durchgeschaut. Ich kann nichts finden. Auf dem Switch ist eigentlich nichts konfiguriert außer die VLAN's. Habe an den AP's alle Funktionen nochmal durchgeschaut... finde nichts.

Wenn ich einem Gerät eine feste Ip-Adresse gebe und mich mit dem Gastnetz verbinde. Keinen Internet zugriff. Weiterhin ist ein ping zu Sophos (Gateway) auch nicht möglich. Ein Tracert bringt auch nur eine Zeitüberschreitung.

Bei einem PC an einem untagged Port, bekommt dieser genauso wie ein Handy keine IP. Also liegt es anscheinend schon einmal nicht an den AP's.


Im DHCP-Log kommt folgendes:
(Dazu ist zu wissen, dass der Testlaptop normalerweise im Hauptnetz die 192.168.20.55 statisch zugewiesen bekommt. Diese Zuweisung gilt aber eigentlich auch nur für das Hauptnetz und das wars)


Aus diesem Grund verstehe ich nicht, woher überhaupt diese Offer kommt...

2019:11:25-23:57:05 ddns dhcpd: DHCPDISCOVER from 54:e1:ad:74:35:0a via eth1
2019:11:25-23:57:05 ddns dhcpd: DHCPOFFER on 192.168.20.55 to 54:e1:ad:74:35:0a via eth1
2019:11:25-23:57:15 ddns dhcpd: DHCPDISCOVER from 54:e1:ad:74:35:0a via eth1
2019:11:25-23:57:15 ddns dhcpd: DHCPOFFER on 192.168.20.55 to 54:e1:ad:74:35:0a via eth1
2019:11:25-23:57:18 ddns dhcpd: DHCPDISCOVER from 54:e1:ad:74:35:0a via eth1
2019:11:25-23:57:18 ddns dhcpd: DHCPOFFER on 192.168.20.55 to 54:e1:ad:74:35:0a via eth1
2019:11:25-23:57:25 ddns dhcpd: DHCPDISCOVER from 54:e1:ad:74:35:0a via eth1
2019:11:25-23:57:25 ddns dhcpd: DHCPOFFER on 192.168.20.55 to 54:e1:ad:74:35:0a via eth1

Kann es sein, dass Sohpos der schuldige ist? Und mit den Subnetzen etwas nicht stimmt.
Es sieht so aus, als of Sophos die IP eines falschen Subnetzes (Hauptnetz) im Gastnetz verteilen würde. Aber die Endgeräte müssten dann ja trotzdem diese IP bekommen oder?

Somit geht schlussendlich die Offer verloren, oder? Das kann Sophos selber sein oder das Switch?

 

[t-6]

Uff. Das ist wieder so eine Sache wo ich mich am liebsten selbst durch alle Menüs hangeln möchte, zumal ich die VLAN-Syntax vom Netgear-Geraffel nicht ganz durchblicke. Mehrere VLANs "untagged" auf ein und demselben Port und irgendwas mit include/exclude, aha... Soll wohl bedeuten ob das VLAN denn jetzt aber wirklich auf den Port gebracht wird oder nicht; szs. ein Sicherheitsschalter/scharfschalten.

Es sieht so aus, als of Sophos die IP eines falschen Subnetzes (Hauptnetz) im Gastnetz verteilen würde.

Seh ich nicht. Ich seh nur dass eine IP aus dem .20er Netz über eth1 verteilt wird, was offensichtlich auch dein Hauptnetz ist. Es könnte jetzt natürlich sein, dass der Netgear-Switch auf eth1 von der Sophos das VLAN30 draufschickt und dann sonst irgendwas kirriges macht.
Beim anderen Log war es eth2, also das Gastnetz.

Stumpf gefragt, kann man ja nie ausschließen: Alle Geräte mal frisch neu gestartet? Kann ja sein dass dhcpd einen Hänger hat und die DHPCREQUESTS im Log schon nicht mehr auftauchen obwohl sie ankommen. Oder das der Netgear endgültig einen Knall weg hat.

Spaßeshalber könntest du ja mal den Switch abhängen und dann ein paar mal an eth1 & eth2 checken ob du immer die IP bekommst die du bekommen solltest. Gerne auch mal mit Wireshark den Traffic mitschneiden.

Was ich da aber gerade sehe:
Port 20 ist laut der Port Config VLAN20 (mutmaßlich) untagged & Port 21 ist VLAN30 untagged.
Laut der VLAN Config hingegen ist Port 20 untagged VLAN20 und VLAN30, (wobei VLAN20 "excluded" ist. Was auch immer.).
Also ist lt. einem Menü Port 20 untagged VLAN20 und nach dem anderen Menü untagged VLAN30.
Irgendwas passt da nicht zusammen.

Mich würde ja mal spaßeshalber interessieren ob du beide VLANs auf ein und demselben Port untagged und included schalten könntest. Das dürfte nämlich eigentlich nicht gehen und sollte schon im Menü geblockt werden.

 

[xexex]

Das Problem ist nun, dass Geräte, die sich im Gastnetz anmelden wollen keine IP zugewiesen bekommen.

Wie immer hilft da nur den gesamten Verkehr zu tracen. Wireshark auf ein Notebook und dann schauen was wo ankommt. Da anscheinend aber ein DHCP DISCOVER an der Sophos ankommt und von ihr ein DHCP OFFER gesendet wird, würde ich den Fehler nicht am VLAN suchen.

Switch hat die aktuellste Firmware und ist neu gestartet? WLAN APs auch?

 

[Campkom]

Halle Vielen Dank für die Antworten.

Was ich da aber gerade sehe:
Port 20 ist laut der Port Config VLAN20 (mutmaßlich) untagged & Port 21 ist VLAN30 untagged.
Laut der VLAN Config hingegen ist Port 20 untagged VLAN20 und VLAN30, (wobei VLAN20 "excluded" ist. Was auch immer.).
Also ist lt. einem Menü Port 20 untagged VLAN20 und nach dem anderen Menü untagged VLAN30.
Irgendwas passt da nicht zusammen.

Vielen Dank dafür! Ich habe in der Port Config den Port 20 auf VLAN 30 gesetzt und siehe es funktioniert.
Aber wieso zur Hölle muss man in der VLAN- und in der Port-Config das VLAN konfigurieren?

Wie siehst es mit den den Ports 21-23 aus? Die sind ja tagged für bei VLAN? Was muss da in der Port konfig stehen? Ist die Port Config nur dafür da ein "Haupt-VLAN" für den Port zu bestimmen? Oder ist es bei tagged VLAN egal was inder Port Config stehet und bei untagged muss das jeweilige VLAN zugewiesen sein?

Port 24 ist korret --> Management

 

[t-6]

Ich vermute (!) dass in der Port Config zunächst mal das untagged VLAN des Ports bestimmt wird, also sozusagen das "Haupt"-VLAN.
Die getaggeten VLANs werden dann in der VLAN Config auf die Ports draufgetagged.

 

[Datax]

Was ich da aber gerade sehe:
Port 20 ist laut der Port Config VLAN20 (mutmaßlich) untagged & Port 21 ist VLAN30 untagged.
Laut der VLAN Config hingegen ist Port 20 untagged VLAN20 und VLAN30, (wobei VLAN20 "excluded" ist. Was auch immer.).
Also ist lt. einem Menü Port 20 untagged VLAN20 und nach dem anderen Menü untagged VLAN30.
Irgendwas passt da nicht zusammen.

Eigentlich sind die Infos in der "Port Config" anders zu verstehen.

Dort ist nicht zu sehen, dass der Port 20 ein Untagged-Port ist und dem VLAN20 zugeordnet ist.
Von Untagged bzw. Tagged ist in der "Port Config" nichts zu lesen (siehe Screenshot 6),
weil es um Tagged bzw. Untagged in der "Port Config" gar nicht geht.

In der "Port Config" konfiguriert man beim Netgear-Switch die PVID,
also die Port-VLAN-ID pro Port.
Mit der PVID sagt man dem Netgear-Switch, welchem VLAN er Pakete zuordnen soll,
die ungetagget in den Switch reinkommen. Die PVID bezieht sich also auf rein kommenden Traffic.

Und da lag letztlich auch der Fehler.

Dem Port 20, der zum Gastnetzwerk (VLAN 30) gehört, war die PVID 20 zugewiesen.
Ungetaggete Pakete, die über den Port 20 in den Switch rein kamen,
wurden deshalb dann durch den Netgear-Switch dem falschen VLAN zugewiesen und zwar dem VLAN 20 (Hauptnetzwerk).

Folgendes Problem entsteht dann, wodurch du am Port 20 mit einem Gerät keine IP-Adresse per DHCP beziehen konntest:
1. Dein Gerät versendet einen DHCP-Discover, der über Port 20 in den Switch rein kommt
2. Der Switch weist den rein kommenden DHCP-Traffic dem VLAN 20 zu
3. Der Switch leitet den DHCP-Traffic über das der beiden Netzwerkkabel zur Sophos-Firewall weiter,
das an dem Port angeschlossen ist, der dem VLAN 20 zugewiesen ist
4. Die Sophos-Firewall empfängt den DHCP-Discover und antwortet mit einem DHCP-Offer (bietet dem Gerät
also eine IP-Adresse an)
5. Der Switch empfängt den DHCP-Offer-Traffic der Sophos-Firewall und leitet diesen DHCP-Offer an die Ports weiter, die dem VLAN 20 zugewiesen sind. Dein Gerät konnte den DHCP-Offer dann aber nicht empfangen,
weil dieser gar nicht an seinem Port ausgegeben wurde, weil dieser (Port 20) nicht dem VLAN 20, sondern
dem VLAN 30 zugewiesen ist.

Es ist also wichtig dem Switch durch die Vergabe der richtigen PVID zu "sagen", welchem VLAN er auf einem bestimmten Port rein kommenden ungetaggten Traffic zuordnen soll. Durch diese Zuordnung wird der ungetaggte Traffic dann in das VLAN weitergereicht, das in der PVID konfiguriert wurde. Wie gesagt bezieht sich das auf aus Sicht des Switches eingehenden Traffic.

Kurz erklärt:
Wird auf Port X Traffic empfangen, für welchen die PVID 10 eingestellt ist,
so leitet der Switch diesen Traffic an alle Ports weiter, die dem VLAN 10 zugewiesen sind.

Noch ein Hinweis:
Mit "Exclude" und "Include" konfiguriert man bei einem bestimmten Port,
ob dieser zu einem bestimmten VLAN gehört (=Include) oder ob er nicht (=Exclude)
zu dem betreffenden VLAN gehört.

Pro VLAN-ID gibt es eine Konfigurationsseite (beziehe mich explizit auf die Screenshots des Netgear-Switches des TE), auf der man für jeden einzelnen Port konfiguriert ,ob dieser zu dem betreffenden VLAN gehört (=Include) oder ob dieser nicht zu diesem VLAN gehört (=Exclude).

Man kann deine VLAN-Konfiguration pro VLAN also so verstehen:
Das VLAN 20 inkludiert die Ports 1 - 19 sowie 21 - 23 (diese Ports gehören zu VLAN 20)
und exkludiert die Ports 20 sowie 24 (gehören nicht zu VLAN 20).
Das VLAN 30 inkludiert die Ports 20 - 23 (diese Ports gehören zu VLAN 30) und
exkludiert die Ports 1 - 19 sowie Port 24 (gehören nicht zu VLAN 30).

 

[Campkom]

Wow. Vielen Dank für die ausführliche Erklärung. Hat mir sehr weitergeholfen.

 

[t-6]

Jup, danke für die Erläuterungen. Jetzt klingelt es auch wieder bei mir... Gottseidank macht Aruba/ProCurve AutoPVID ab Werk, sonst wären mir bei einigen Installationen noch mehr graue Haare gewachsen.