PFsense - WAN NIC endto error: 64

Hallo Zusammen,

ich habe mir mittels PFsense einen Router mit zwei NICs gebaut. die WAN NIC hat im Test häufig den obigen Fehler ausgegeben und das Gateway ist dann auch nicht zu erreichen. Die WAN Nic kann ich allerdings pingen. Ziehe ich gefühlt 10x das LAN Kabel raus, funktioniert das irgendwann mal. Liegt das an der Karte?

Gruß,
Roadmax

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 641997

Url: https://administrator.de/forum/pfsense-wan-nic-endto-error-64-641997.html

Ausgedruckt am: 02.01.2025 um 22:01 Uhr

7 Kommentare

Neuester Kommentar

Hast du das Gateway Monitoring aktiv auf dem Default Gateway ?? Ist leider immer per Default aktiviert.
Das solltest du in jedem Falle deaktivieren (System --> Routing):

Damit sollte das dann eigentlich verschwinden.

Die WAN Nic kann ich allerdings pingen.

Im Default Setup ??? Das darf niemals sein, denn IGMP ist im Default inbound am WAN Port logischerweise immer blockiert.
Oder hast du da am WAN Port dein eigenes Regelwerk aktiviert ?!

Hallo,

Zitat von @Roadmax:
ich habe mir mittels PFsense einen Router mit zwei NICs gebaut. die WAN NIC hat im Test häufig den obigen Fehler ausgegeben und das Gateway ist dann auch nicht zu erreichen. Die WAN Nic kann ich allerdings pingen. Ziehe ich gefühlt 10x das LAN Kabel raus, funktioniert das irgendwann mal. Liegt das an der Karte?

Da deine nicjhtgenannte Hardware besunders die NIC vom Hersteller YIPS erst 2099 gebaut wird, wird dein OS diese erst ab 2100 unterstützen. Jetzige Fehlermeldungen sind in der Zukunft aussagekräftiger / nachlesbar.

Gruß,
Peter

Zitat von @aqui:

Hast du das Gateway Monitoring aktiv auf dem Default Gateway ?? Ist leider immer per Default aktiviert.
Das solltest du in jedem Falle deaktivieren (System --> Routing):

Damit sollte das dann eigentlich verschwinden.

Jetzt ist zwar die Meldung weg aber das Problem mit der nicht erreichbarkeit des Internets bleibt.
Ping aus dem LAN auf das Gateway: Destination unreachable.

Die WAN Nic kann ich allerdings pingen.

Im Default Setup ??? Das darf niemals sein, denn IGMP ist im Default inbound am WAN Port logischerweise immer blockiert.
Oder hast du da am WAN Port dein eigenes Regelwerk aktiviert ?!

Ja im Default Setup. Ich meinte auch ein Ping aus dem LAN auf das WAN Interface und das ist erlaubt.

Es handelt sich im übrigen um Karten mit einem Realtek 8168 Chipsatz, andere habe ich nicht da.
In den Logs steht noch folgendes: arpresolve: can't allocate llinfo for xxx.xxx.xxx.xxx on re0
Un die Karte steht im Modus 1000baseT <full-duplex,master> .
Scheint doch ein Problem mit der NIC zu sein oder?

Die Graphen zu den NICsa bei einem laufendem Ping aus dem LAN auf das Gateway sieht wie folgt aus.

Noch etwas ist mir aufgefallen. Wenn die PFsense keinen Internetzugriff hat, sind Änderungen in der WEBGUI extremst langsam. Z.B. dauert das Speichern von Änderungen bis zu 3 Minuten. Hat die Box Zugriff geht das sofort.

Hier noch ein Auszug aus dem Logfile. Wenn ich beim WAN das LAN Kabel anschließe, dauert es ca. 4 Minuten bis Pakete ins Internet fließen.

Jan 18 16:38:10 check_reload_status Linkup starting re0
Jan 18 16:38:10 kernel re0: link state changed to UP
Jan 18 16:38:11 php-fpm 80996 /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx )
Jan 18 16:38:11 check_reload_status rc.newwanip starting re0
Jan 18 16:38:11 check_reload_status Reloading filter
Jan 18 16:38:12 php-fpm 80996 /rc.newwanip: rc.newwanip: Info: starting on re0.
Jan 18 16:38:12 php-fpm 80996 /rc.newwanip: rc.newwanip: on (IP address: xxx.xxx.xxx.xxx) (interface: WAN[wan]) (real interface: re0).
Jan 18 16:38:12 check_reload_status Reloading filter
Jan 18 16:42:28 check_reload_status Linkup starting re0
Jan 18 16:42:28 kernel re0: watchdog timeout
Jan 18 16:42:28 kernel re0: link state changed to DOWN
Jan 18 16:42:29 php-fpm 153 /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx )
Jan 18 16:42:29 check_reload_status Reloading filter
Jan 18 16:42:29 kernel arpresolve: can't allocate llinfo for (xxx.xxx.xxx..yyy on re0
Jan 18 16:42:30 kernel arpresolve: can't allocate llinfo for (xxx.xxx.xxx..yyy on re0
Jan 18 16:42:32 check_reload_status Linkup starting re0
Jan 18 16:42:32 kernel re0: link state changed to UP
Jan 18 16:42:33 php-fpm 347 /rc.linkup: Hotplug event detected for WAN(wan) static IP (xxx.xxx.xxx.xxx )
Jan 18 16:42:33 check_reload_status rc.newwanip starting re0
Jan 18 16:42:33 check_reload_status Reloading filter
Jan 18 16:42:34 php-fpm 347 /rc.newwanip: rc.newwanip: Info: starting on re0.
Jan 18 16:42:34 php-fpm 347 /rc.newwanip: rc.newwanip: on (IP address: xxx.xxx.xxx.xxx) (interface: WAN[wan]) (real interface: re0).
Jan 18 16:42:34 check_reload_status Reloading filter

aber das Problem mit der nicht erreichbarkeit des Internets bleibt.

Das kann seltenen Fällen passieren wenn du ein Hardware Autonegotiation Problem auf dem Port mit deinem Switch hast. Der kann dann nicht ermitteln welchen Duplex Mode und welche Port Speed er anlegen soll und ein Layer 1 Forwarding scheitert.
Das wäre aber ein rein physisches Problem dann. Damit hat der gesamte WAN Port dann keinen physischen Link auf den Switch und nichts geht.
Kann man das sicher ausschliessen ist der Rest dann so gut wie immer ein Firewall Problem mit falschen oder fehlerhaften Regeln. Oder ein IP Routing Problem mit falschen oder fehlerhaften Routen.
Viele vergessen dann auch das das Regelwerk rein nur inbound wirkt also VOM Netzwerk Draht in das Interface hinein und nicht outbound. Außerdem das generell "First match wins !" gilt. Sprich beim ersten positiven Hit im Regelwerk werden alle folgenden Regeln NICHT mehr abgearbeitet.
Das sollte man also immer auf dem Radar haben beim Betrieb einer Firewall gegenüber einem Router ! Die verhalten sich da generell unterschiedlich.