WAN verliert IP Adresse - Netgate 7100

johndo

Hallo zusammen,

ich betreibe eine Netgate 7100 an einem VDSL Anschluss. Davor hängt ein Draytek Vigor als VDSL Modem. Bei dem Betreiber wird eine IPv4 Adresse mittels DHCP vergeben, es gibt sozusagen keine Einwahldaten oder ähnliches.

Nun passiert es ab und zu mal das die Internetverbindung ausfällt. Ich kann das nun soweit nachvollziehen das es mit dem WAN Interface von der Netgate zu tun hat. Heißt die VDSL Leitung ist am Modem sauber terminiert und ist stabil. Auf der Netgate sehe ich aber das keine IP Adresse auf dem WAN Interface zugewiesen ist.

Der technische Support vom Provider sagte mir das Sie keine IP Adressen auf die Endgeräte pushen sondern die Endgeräte sich die IPs per DHCP selbst anfordern. Das kann ich auch nachvollziehen. Sofern die Internetverbindung nicht mehr funktioniert muss ich auf die Netgate gehen und das WAN Interface deaktivieren und wieder aktivieren, danach funktoiniert wieder alles.

Nun zu meiner eigentlichen Frage, kann ich irgendwo auf der Netgate konfigurieren wenn die WAN IP weg ist das einfach ein paar DHCP request gestellt werden bis die IP wieder da ist?

JeGr

@johndo said in WAN verliert IP Adresse - Netgate 7100:

Der technische Support vom Provider sagte mir das Sie keine IP Adressen auf die Endgeräte pushen sondern die Endgeräte sich die IPs per DHCP selbst anfordern. Das kann ich auch nachvollziehen. Sofern die Internetverbindung nicht mehr funktioniert muss ich auf die Netgate gehen und das WAN Interface deaktivieren und wieder aktivieren, danach funktoiniert wieder alles.

Das kann durchaus sein, wenn der ISP das wieder "halbgar" macht. Pushen müssen sie auch gar nicht, aber hin und wieder Antwort auf einen Request geben.
Die Frage ist dann eher: siehst du was im Log (DHCP) auf dem WAN, wenn das passiert? Denn wenn die IP verschwindet müsste das WAN entweder vorher nen DHCP RENEW geschickt haben (oder zumindest quasi eine Lease Erneuerung) oder das Lease ist ausgelaufen und sie hat keine Antwort auf einen Request bekommen. Ansonsten wäre das SEHR komisch. Den Aufbau, dass die pfSense per DHCP hinter einem anderen Gerät rennt, haben wir schon mehrfach gesehen und da gibt es eigentlich auch keinen Unfug was DHCP angeht. Wenn einfach die IP verschwindet muss da schon was schief gehen, da wäre es dann wichtig zu wissen, in welcher Ecke man suchen muss.

Alternativ könnte es sein, dass da noch jemand anderes in dem Segment vom ISP DHCP "dazwischen quakt", aber auch das müsste im Log ja ersichtlich sein.

Option 3 könnte auch sein, dass aus irgendeinem Grund das GW wegfällt und das GW Monitoring das Interface dann runter nimmt und beim Hochfahren der DHCP kein sauberes renew macht. Quick fix wäre dann wenn es eh kein zweites WAN gibt, das GW Monitoring auf dem einzigen GW abzuschalten damit das nicht dazwischen geht.

Der Draytek davor sagt sonst aber DSL ist da? Ist der auf Bridge geschaltet oder hüpft der vllt. irgendwie dazwischen?

Cheers

johndo

@JeGr

Hi,

ich schaue mir heute Abend das Log mal an.

Wo würde ich das GW Monitoring abschalten können?

Ja, auf dem Drytek ist die Leitung terminiert und es gibt keine Fehler etc..

JeGr

@johndo said in WAN verliert IP Adresse - Netgate 7100:

Wo würde ich das GW Monitoring abschalten können?

Unter System/Routing beim WAN GW editieren und dort den Haken bei GW Monitoring rausnehmen. Nicht nur die Action, sondern das ganze Monitoring mal abschalten. Dann sagt er einfach "ist immer up" und fährt es nicht runter.

@johndo said in WAN verliert IP Adresse - Netgate 7100:

Ja, auf dem Drytek ist die Leitung terminiert und es gibt keine Fehler etc..

Heißt da liegt dann nur das DSL Signal auf oder macht der auch die DSL Einwahl?

Cheers

johndo

@JeGr

Ich habe es nun so eingestellt, ist das so korrekt?

Bildschirmfoto 2025-09-18 um 19.39.25.png

johndo

@JeGr

Am Modem liegt nur der VDSL Anschluss an, es gibt keine Einwahl auf dem Modem.
Die Firewall hängt dann mit dem WAN per Netzwerkkabel an dem Modem. Die WAN Schnittstelle der Firewall steht auf DHCP.

Wo genau im Log müsste ich schauen um den WAN Fehler mal nachzuvollziehen?

viragomann

@johndo
Ich würde mir erwarten, dass im System Log Einträge dazu zu finden sind, wenn pfSense die WAN IP verliert.
Und dann wäre auch interessant, was im DHCP Log steht (Client Einträge).

Schau auch ins Log des Vigor auf Hinweise nach Verbindungsabrisse.
Ich könnte mir verstellen, dass die DSL Verbindung abreißt und damit das Problem auslöst.

johndo

@viragomann

Folgendes sehe ich im Systemlog zu der Uhrzeit wo die Verbindung weg war:

Sep 17 12:01:01 	php-fpm 	3490 	/rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed IP addresses. Reloading endpoints that may use WAN_DHCP.
Sep 17 12:01:01 	php-fpm 	3490 	/rc.openvpn: Gateway, none 'available' for inet, use the first one configured. 'WAN_DHCP'
Sep 17 12:01:00 	check_reload_status 	475 	Reloading filter
Sep 17 12:01:00 	check_reload_status 	475 	Restarting OpenVPN tunnels/interfaces
Sep 17 12:01:00 	check_reload_status 	475 	Restarting IPsec tunnels
Sep 17 12:01:00 	check_reload_status 	475 	updating dyndns WAN_DHCP
Sep 17 12:01:00 	rc.gateway_alarm 	87475 	>>> Gateway alarm: WAN_DHCP (Addr:x.x.x.x Alarm:1 RTT:16.740ms RTTsd:10.598ms Loss:22%)

Auf dem Modem sehe ich keine Fehler zu diesem Zeitpunkt.

Im DHCP Log sehe ich das hier:

Sep 17 02:02:59 	dhclient 	84139 	bound to x.x.x.x -- renewal in 89613 seconds.
Sep 17 02:02:59 	dhclient 	9953 	Creating resolv.conf
Sep 17 02:02:59 	dhclient 	8647 	RENEW
Sep 17 02:02:59 	dhclient 	84139 	DHCPACK from 10.211.0.254
Sep 17 02:02:58 	dhclient 	84139 	DHCPREQUEST on lagg0.7 to 10.211.0.254 port 67

Was ich daran sehr komisch finde ist die Adresse 10.211.0.254 dieses Netz ist mir ubekannt und gehört nicht zu meinen internen Netzen. Interessant ist das dieses auf VLAN7 läuft also kommt das vom Provider?

viragomann

@johndo
Das System Log zeigt jedenfalls einen Gateway-Alarm.
Soweit ich diese kenne, hängt das mit dem Monitoring zusammen. War das also vor Deaktivieren des Gateway-Monitorings?

Das DHCP Log zeigt für mich einen normalen DHCP Request mit Antwort vom Server und eine Zuweisung der erhaltenen IP.
Daher frage ich mich, ob das Log Schnipsel überhaupt was mit dem Ausfall zu tun hat. Es ist auch eine andere Log-Zeit als der Gateway-Ausfall.

Ja, die 10.211.0.254 müsste der DHCP Server des Providers sein. Der kann in seinem eigenen Netz auch eine private Adresse nutzen.

JeGr

Dass DHCP o.ä. über private IPs vom ISP kommt ist kein Wunder, das ist häufig der Fall.

dein lagg0.7 (vlan7 auf lagg0) muss dann wahrscheinlich dein WAN sein auf dem du DHCP aktiv hast? Oder wie ist sonst dein WAN konfiguriert?

Der ISP macht also um 2h ggf. ein Renew oder eine Zwangstrennung oder gabs nen Grund warum genau da das WAN ne neue IP bekommen hatte?
Der DHclient hat zumindest >24h als Lease Time bekommen und hätte daher erst am nächsten Tag um kurz nach 2h morgens wieder ein Renew gemacht. Der ISP hat aber anscheinend dann vorher schon die Adresse entzogen oder die pfSense hat sie verloren. Die Frage ist da eher, was VOR dem Gateway Alarm kam. Der kam ja dann wohl so kurz nach 12 und dann ging nix mehr. Daraufhin wurden dann auch alle WAN-abhängigen Sachen neu gestartet, aber die Frage ist, was genau vor 12:01:00/01 passiert ist, denn da kam der GW Alarm. Und da würde ich dann auch in den DHCP Logs schauen ob um 12h irgendwas passiert ist. Dass das so GENAU 10h sind, stinkt nämlich ein wenig. Das könnte dann sein, dass nach 10h irgendwas beim ISP expired wenn das nicht erneuert wird und die pfSense macht halt nichts bevor die Lease Time rum ist - warum sollte sie auch, sie hat ja die IP. Wenn der ISP aber irgendwelchen Dummfug veranstaltet und dann immer mal wieder auf irgendwas wartet um die IP "up" zu lassen (ja erzählen können die viel, dass sie NUR DHCP machen würden...), dann klapperts dann trotzdem.

Wir hatten das bei seltsamen ISPs schon mit CARP/HA Adressen, die dann einfach "vergessen" wurden auf dem Interface, weil deren MAC Adresse nicht upstream geschickt wurde - da das nur beim setzen der VIP gemacht wird. Die VIP wurde dann vom ISP wegen "inactivity" einfach weggekillt. Wir haben dann ein Script gebaut, was in regelmäßigen Intervallen einen gratuitous ARP von der VIP schickt, dann war plötzlich alles gut. Und das war bei statischen IPs. Angeblich auch der ISP "nix gemacht!!!11elf". Hmm ;)

Anderer Fall könnte sein, dass du von einem anderen Device einen DHCPNACK bekommst bzw. einen Release, der aber von ner anderen IP kommt. Dagegen könnte man reinwerfen, dass der DHCP NUR von der IP oben kommen darf - sofern die immer gleich ist. Das wäre dann auch ein Thema.