27
PFSense: Problem bei der Übertragung einer XML-Datei an den Fiskus
Hallo.
Ich bin für das Netzwerk eines kleinen Gastbetriebes (Hotel+Restaurant) in Südtirol zuständig.
Im Einsatz ist eine PFSense Firewall (2.6, Community Edition).
Hier in Italien ist es jetzt schon seit ein paar Jahren gesetzlich vorgeschrieben, dass sämtliche Registrierkassen eine XML-Datei mit Tagesinkasso-Informationen über Internet täglich an den Fiskus verschicken. Die Kassen verrichten dies automatisch, der Vorgang kann aber auch manuell angeschubst werden.
Wir haben drei Registrierkassen von der Firma RCH. Bei 2 der 3 Kassen verläuft die Übertragung der XML-Datei problemlos. Nur bei einer Kasse (selbe Marke, anderes Modell) klappt die Übertragung einfach nicht. "Error E94: No connection."
Die Kasse unterstützt kein DHCP, benötigt also eine fixe IP-Adresse. Die Kasse lässt sich im Netzwerk problemlos anpingen.
Folgende Maßnahmen habe ich bereits ausprobiert:
- die Firewall für diese Kasse testweise komplett geöffnet
- Netzwerkkabel ausgetauscht, die Kasse direkt an den Router angeschlossen
In unserem Netzwerk tummeln sich duzende von Netzwerkgeräten und funktionieren ohne Probleme.
Der Servicetechniker ist mit seinem Latein auch am Ende. Er hat mir auch schon ein nagelneues Erstatzgerät vorbeigebracht, auch dieses kann von unserem Netzwerk aus die Meldung nicht durchführen. Im Netzwerk des Firmentechnikers funktioniert die Übertragung jedoch problemlos.
Für Hilfe uns Lösungsvorschläge bin ich sehr dankbar.
Ich bin für das Netzwerk eines kleinen Gastbetriebes (Hotel+Restaurant) in Südtirol zuständig.
Im Einsatz ist eine PFSense Firewall (2.6, Community Edition).
Hier in Italien ist es jetzt schon seit ein paar Jahren gesetzlich vorgeschrieben, dass sämtliche Registrierkassen eine XML-Datei mit Tagesinkasso-Informationen über Internet täglich an den Fiskus verschicken. Die Kassen verrichten dies automatisch, der Vorgang kann aber auch manuell angeschubst werden.
Wir haben drei Registrierkassen von der Firma RCH. Bei 2 der 3 Kassen verläuft die Übertragung der XML-Datei problemlos. Nur bei einer Kasse (selbe Marke, anderes Modell) klappt die Übertragung einfach nicht. "Error E94: No connection."
Die Kasse unterstützt kein DHCP, benötigt also eine fixe IP-Adresse. Die Kasse lässt sich im Netzwerk problemlos anpingen.
Folgende Maßnahmen habe ich bereits ausprobiert:
- die Firewall für diese Kasse testweise komplett geöffnet
- Netzwerkkabel ausgetauscht, die Kasse direkt an den Router angeschlossen
In unserem Netzwerk tummeln sich duzende von Netzwerkgeräten und funktionieren ohne Probleme.
Der Servicetechniker ist mit seinem Latein auch am Ende. Er hat mir auch schon ein nagelneues Erstatzgerät vorbeigebracht, auch dieses kann von unserem Netzwerk aus die Meldung nicht durchführen. Im Netzwerk des Firmentechnikers funktioniert die Übertragung jedoch problemlos.
Für Hilfe uns Lösungsvorschläge bin ich sehr dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3191359931
Url: https://administrator.de/contentid/3191359931
Ausgedruckt am: 24.11.2024 um 21:11 Uhr
27 Kommentare
Neuester Kommentar
Servus,
hast du mal die Kasse 3 ans Netzwerkkabel der Kassen 1 o. 2 geklemmt und geschaut ob die dann Ihre XML raushaut? Wenn ja würde ich den Fehler auf einer falschen Portkonfiguration vermuten.
Falls nicht wäre der einfachste Weg mit Wireshark den Traffic der Kasse 3 zu verfolgen dann siehst du wo es irgendwann klemmt.
hast du mal die Kasse 3 ans Netzwerkkabel der Kassen 1 o. 2 geklemmt und geschaut ob die dann Ihre XML raushaut? Wenn ja würde ich den Fehler auf einer falschen Portkonfiguration vermuten.
Falls nicht wäre der einfachste Weg mit Wireshark den Traffic der Kasse 3 zu verfolgen dann siehst du wo es irgendwann klemmt.
hast du mal die Kasse 3 ans Netzwerkkabel der Kassen 1 o. 2 geklemmt und geschaut ob die dann Ihre XML raushaut? Wenn ja würde ich den Fehler auf einer falschen Portkonfiguration vermuten.
Ja das habe ich bereits versuch, leider ohne Erfolgt.
Ja das habe ich bereits versuch, leider ohne Erfolgt.
Dann würde ich definitiv mit Wireshark den Traffic verfolgen.
Denke mal solche Sachen wie doppelte IP-Adresse hast du schon kontrolliert?
Denke mal solche Sachen wie doppelte IP-Adresse hast du schon kontrolliert?
Denke mal solche Sachen wie doppelte IP-Adresse hast du schon kontrolliert?
Ja das kann ich definitiv ausschließen.
Dann würde ich definitiv mit Wireshark den Traffic verfolgen.
Dann werd ich mich da mal dran machen.
Ja das kann ich definitiv ausschließen.
Dann würde ich definitiv mit Wireshark den Traffic verfolgen.
Dann werd ich mich da mal dran machen.
Vieleicht kann die Kasse schlicht keine der aktuelle Verschlüsselungen und es liegt gar nicht an Deinem Anschluss.
Die Kasse baut also die Verbindung eigenständig nach Außen auf?
Ich habe hier einen VPN Router eines Anbieters. Der nimmt z.B. keinen Traffic an der aus einem Subnetz kommt, der muss mit seiner internen IP zwingend in dem Netz stehen aus dem der Traffic ins VPN geroutet werden soll. Machen die Pakete einen Hop mehr läuft das ins Leere, hat mir vermutlich meine ersten grauen Haare beschert.
Wird deine Kasse direkt ins Internet geroutet oder liegen da mehrere Stationen dazwischen?
Ich habe hier einen VPN Router eines Anbieters. Der nimmt z.B. keinen Traffic an der aus einem Subnetz kommt, der muss mit seiner internen IP zwingend in dem Netz stehen aus dem der Traffic ins VPN geroutet werden soll. Machen die Pakete einen Hop mehr läuft das ins Leere, hat mir vermutlich meine ersten grauen Haare beschert.
Wird deine Kasse direkt ins Internet geroutet oder liegen da mehrere Stationen dazwischen?
Vieleicht kann die Kasse schlicht keine der aktuelle Verschlüsselungen und es liegt gar nicht an Deinem Anschluss.
Im Netzwerk der Wartungsfirma verbindet sich die Kasse problemos mit dem Server vom Fiskus.
Die Kasse baut also die Verbindung eigenständig nach Außen auf?
Ja.
Wird deine Kasse direkt ins Internet geroutet oder liegen da mehrere Stationen dazwischen?
Zwischen Kasse und Internet befindet sich nur der Router mit PFSense.
Im Netzwerk der Wartungsfirma verbindet sich die Kasse problemos mit dem Server vom Fiskus.
Die Kasse baut also die Verbindung eigenständig nach Außen auf?
Ja.
Wird deine Kasse direkt ins Internet geroutet oder liegen da mehrere Stationen dazwischen?
Zwischen Kasse und Internet befindet sich nur der Router mit PFSense.
Hi,
bevor du mit dem Kabelhai anfängst:
1. Erstelle ein Alias "Kassen", weise die IPs von allen 3 Kassen diesem Alias zu.
2. Erstelle eine Regel: erlaube alles von dem Alias Kassen nach Alles, Log.
Dann sende mal mit einer funktionierenden Kasse und dann mit der nicht funktionierenden Kasse.
Kontrolliere und vergleiche die Logs, da solltest du ggf. schon den Fehler erkennen.
3. wenn gelöst: Passe die Any to any Regel an
Gruß
CH
bevor du mit dem Kabelhai anfängst:
1. Erstelle ein Alias "Kassen", weise die IPs von allen 3 Kassen diesem Alias zu.
2. Erstelle eine Regel: erlaube alles von dem Alias Kassen nach Alles, Log.
Dann sende mal mit einer funktionierenden Kasse und dann mit der nicht funktionierenden Kasse.
Kontrolliere und vergleiche die Logs, da solltest du ggf. schon den Fehler erkennen.
3. wenn gelöst: Passe die Any to any Regel an
Gruß
CH
Servus.
Wie schon gesagt wurde ein tcpdump/wireshark-trace am Port der Kasse bringt in der Regel sofort Klarheit.
Grüße Uwe
Die Kasse unterstützt kein DHCP, benötigt also eine fixe IP-Adresse. Die Kasse lässt sich im Netzwerk problemlos anpingen.
Nur aus dem selben Subnetz oder auch aus anderen an der pfSense? Dann auch Gateway-Adresse und DNS-Server Einträge in der Kasse auf Korrektheit überprüft? pfSense schon mal durchgestartet?Wie schon gesagt wurde ein tcpdump/wireshark-trace am Port der Kasse bringt in der Regel sofort Klarheit.
Denke mal solche Sachen wie doppelte IP-Adresse hast du schon kontrolliert?
Und auch auf doppelte MAC Adressen nicht vergessen, zwar selten aber kann vorkommen ...Grüße Uwe
Wir hatten ein ähnliches Problem mit der Sense.
VM ließ sich anpingen, hatte aber keine Verbindung nach außen.
Der Fehler lag an doppelt vergebenen IPs bzw. Aliasen.
Ein Lease wurde nicht gelöscht und dann wurde zufällig dieselbe IP manuell nochmal vergeben.
Kontrolliere das mal + lösche alle Leases (auch die statischen Mappings!) und lösche die ARP-Table.
Setze dann auch die States mal zurück.
VM ließ sich anpingen, hatte aber keine Verbindung nach außen.
Der Fehler lag an doppelt vergebenen IPs bzw. Aliasen.
Ein Lease wurde nicht gelöscht und dann wurde zufällig dieselbe IP manuell nochmal vergeben.
Kontrolliere das mal + lösche alle Leases (auch die statischen Mappings!) und lösche die ARP-Table.
Setze dann auch die States mal zurück.
Moin,
schau doch mal bei der pfSense unter Diagnostics --> Packet Capture
Vergleich doch mal was da bei der pfSense von den jeweiligen Kassen so ankommt. Vielleicht siehst Du dort ja schon einen Unterschied...
Das Capture File kannst Du runterladen und mit Wireshark auswerten.
schau doch mal bei der pfSense unter Diagnostics --> Packet Capture
Vergleich doch mal was da bei der pfSense von den jeweiligen Kassen so ankommt. Vielleicht siehst Du dort ja schon einen Unterschied...
Das Capture File kannst Du runterladen und mit Wireshark auswerten.
Die wichtigsten Checks sind oben schon genannt worden. Wirklich wichtig ist die Überprüfung der statischen IP der Kasse ! Diese darf nicht im DHCP-Server Pool des lokalen LAN Netzes liegen ansonsten kann es zu einer IP Address Dopplung und damit den beschriebenen Symptomen kommen.
Also immer Kassen IP außerhalb des DHCP Address Pools legen!!
Gateway IP und vor allem DNS IP sollten bei der Kasse logischerweise statisch auch auf die pfSense IP gelegt werden.
Ein Capture über die interne Paket Capture Funktion der pfSense (Menü: "Diagnostics") wäre wichtig und hilfreich mit Filter auf die Kassen IP um einmal deren gesamten Traffic mitlesen zu können beim Verbindungsaufbau.
Alternativ einmal einen Test PC mit der gleichen statischen IP wie die Kasse anschliessen und von dem versuchen das Ziel zu pingen bzw. zu erreichen. Kasse VOR diesem Test dann natürlich abziehen! (doppelte IP!)
Ggf. über die Capture Funktion beide Endgeräte einmal vergleichen.
Der Paket Capture sollte, wie oben schon mehrfach gesagt, den Fehler sofort aufzeigen!
Also immer Kassen IP außerhalb des DHCP Address Pools legen!!
Gateway IP und vor allem DNS IP sollten bei der Kasse logischerweise statisch auch auf die pfSense IP gelegt werden.
Ein Capture über die interne Paket Capture Funktion der pfSense (Menü: "Diagnostics") wäre wichtig und hilfreich mit Filter auf die Kassen IP um einmal deren gesamten Traffic mitlesen zu können beim Verbindungsaufbau.
Alternativ einmal einen Test PC mit der gleichen statischen IP wie die Kasse anschliessen und von dem versuchen das Ziel zu pingen bzw. zu erreichen. Kasse VOR diesem Test dann natürlich abziehen! (doppelte IP!)
Ggf. über die Capture Funktion beide Endgeräte einmal vergleichen.
Der Paket Capture sollte, wie oben schon mehrfach gesagt, den Fehler sofort aufzeigen!
Hallo, habe den Paket Capture durchgeführt.
Wie kann ich den Inhalt der entsprechenden .cap - Datei hier im Forum am Besten veröffentlichen?
Wie kann ich den Inhalt der entsprechenden .cap - Datei hier im Forum am Besten veröffentlichen?
In Wireshark laden und Screenshots. Oder DU kannst doch auch schlicht und einfach beschreiben was der Capture dir für Erkenntnisse gebracht hat!
Hier ein Auszug:
10.0.0.1 = PFSense Router / 10.1.5.30 = Kasse
88 41.137952 10.0.0.1 10.1.5.30 ICMP 610 Destination unreachable (Fragmentation needed)
89 41.424906 217.175.50.83 10.1.5.30 TCP 129 [TCP Spurious Retransmission] 443 → 34739 [ACK] Seq=1964 Ack=565 Win=65535 Len=75
90 41.425074 10.1.5.30 217.175.50.83 TCP 60 [TCP Dup ACK 77#1] 34739 → 443 [ACK] Seq=4161 Ack=2039 Win=8192 Len=0
91 41.946149 10.1.5.30 217.175.50.83 TCP 1514 [TCP Retransmission] 34739 → 443 [PSH, ACK] Seq=565 Ack=2039 Win=8192 Len=1460
92 41.946398 10.0.0.1 10.1.5.30 ICMP 610 Destination unreachable (Fragmentation needed)
93 43.563605 10.1.5.30 217.175.50.83 TCP 1514 [TCP Retransmission] 34739 → 443 [PSH, ACK] Seq=565 Ack=2039 Win=8192 Len=1460
94 43.563979 10.0.0.1 10.1.5.30 ICMP 610 Destination unreachable (Fragmentation needed)
95 46.660239 10.1.5.30 217.175.50.83 TCP 60 34739 → 443 [FIN, ACK] Seq=4161 Ack=2039 Win=8192 Len=0
10.0.0.1 = PFSense Router / 10.1.5.30 = Kasse
88 41.137952 10.0.0.1 10.1.5.30 ICMP 610 Destination unreachable (Fragmentation needed)
89 41.424906 217.175.50.83 10.1.5.30 TCP 129 [TCP Spurious Retransmission] 443 → 34739 [ACK] Seq=1964 Ack=565 Win=65535 Len=75
90 41.425074 10.1.5.30 217.175.50.83 TCP 60 [TCP Dup ACK 77#1] 34739 → 443 [ACK] Seq=4161 Ack=2039 Win=8192 Len=0
91 41.946149 10.1.5.30 217.175.50.83 TCP 1514 [TCP Retransmission] 34739 → 443 [PSH, ACK] Seq=565 Ack=2039 Win=8192 Len=1460
92 41.946398 10.0.0.1 10.1.5.30 ICMP 610 Destination unreachable (Fragmentation needed)
93 43.563605 10.1.5.30 217.175.50.83 TCP 1514 [TCP Retransmission] 34739 → 443 [PSH, ACK] Seq=565 Ack=2039 Win=8192 Len=1460
94 43.563979 10.0.0.1 10.1.5.30 ICMP 610 Destination unreachable (Fragmentation needed)
95 46.660239 10.1.5.30 217.175.50.83 TCP 60 34739 → 443 [FIN, ACK] Seq=4161 Ack=2039 Win=8192 Len=0
Das Elend siehst du ja auch selber, oder ?
DNS zu agenziaentrate.gov.it und auch der dann folgende Verbindungsaufbau mit TLS Schlüsselaustausch dahin klappt fehlerlos.
Das Ziel hat eine kleinere MTU und erfordert Fragementierung mit einem ICMP Typ 3 oder 4 was die Firewall aber ablehnt. Dadurch kommt es zu Retransmissions und einem Session Abbruch.
Du filterst also in den Firewall Regeln vermutlich irgendwo wichtige ICMP Frames oder hast Scrubbing etc. aktiviert was das verursacht.
Hier kann man jetzt nur im freien Fall raten weil dein FW Regelwerk und dein Setup unbekannt sind...
Was auch noch auffällig ist:
Wie kommt es zu dieser "komischen" IP Adressierung?? Kein normaler Mensch fährt mit einem 8er Prefix in der Segmentierung so das es eigentlich niemals zu einer Kommunikation 10.0.0.1 mit 10.1.5.30 kommen kann?
In einem "normalen" Design nutzt man üblicherweise einen 24er Prefix in der Adressierung mit 255.255.255.0. Wie kommt es also bei dir zu diesen merkürdigen Adressen?
Nutzt du allen Ernstes eine /8er Maske in dem Netz?
Die Grundproblematik ist aber das die Fragmentierung fehlschlägt, was vermutlich am falschen Regelwerk oder dem Grundsetup liegt. (Geraten)
DNS zu agenziaentrate.gov.it und auch der dann folgende Verbindungsaufbau mit TLS Schlüsselaustausch dahin klappt fehlerlos.
Das Ziel hat eine kleinere MTU und erfordert Fragementierung mit einem ICMP Typ 3 oder 4 was die Firewall aber ablehnt. Dadurch kommt es zu Retransmissions und einem Session Abbruch.
Du filterst also in den Firewall Regeln vermutlich irgendwo wichtige ICMP Frames oder hast Scrubbing etc. aktiviert was das verursacht.
Hier kann man jetzt nur im freien Fall raten weil dein FW Regelwerk und dein Setup unbekannt sind...
Was auch noch auffällig ist:
Wie kommt es zu dieser "komischen" IP Adressierung?? Kein normaler Mensch fährt mit einem 8er Prefix in der Segmentierung so das es eigentlich niemals zu einer Kommunikation 10.0.0.1 mit 10.1.5.30 kommen kann?
In einem "normalen" Design nutzt man üblicherweise einen 24er Prefix in der Adressierung mit 255.255.255.0. Wie kommt es also bei dir zu diesen merkürdigen Adressen?
Nutzt du allen Ernstes eine /8er Maske in dem Netz?
Die Grundproblematik ist aber das die Fragmentierung fehlschlägt, was vermutlich am falschen Regelwerk oder dem Grundsetup liegt. (Geraten)
Wie kommt es zu dieser "komischen" IP Adressierung?? Kein normaler Mensch fährt mit einem 8er Prefix in der Segmentierung so das es eigentlich niemals zu einer Kommunikation 10.0.0.1 mit 10.1.5.30 kommen kann?
In einem "normalen" Design nutzt man üblicherweise einen 24er Prefix in der Adressierung mit 255.255.255.0. Wie kommt es also bei dir zu diesen merkürdigen Adressen? Nutzt du allen Ernstes eine /8er Maske in dem Netz?
Ja ich nutze ein /8er Maske. Es handelt sich über ein umfangreiches Netzwerk, welches sich über mehrere Gebäude erstreckt und sonst eigenglich 1a funktioniert.
Ich habe jetzt mal in PFSense unter SystemAdvancedFirewall & NAT die Option "Disables the PF scrubbing option which can sometimes interfere with NFS traffic." Mal schauen obs jetzt klappt.
In einem "normalen" Design nutzt man üblicherweise einen 24er Prefix in der Adressierung mit 255.255.255.0. Wie kommt es also bei dir zu diesen merkürdigen Adressen? Nutzt du allen Ernstes eine /8er Maske in dem Netz?
Ja ich nutze ein /8er Maske. Es handelt sich über ein umfangreiches Netzwerk, welches sich über mehrere Gebäude erstreckt und sonst eigenglich 1a funktioniert.
Ich habe jetzt mal in PFSense unter SystemAdvancedFirewall & NAT die Option "Disables the PF scrubbing option which can sometimes interfere with NFS traffic." Mal schauen obs jetzt klappt.
Bitte wenn zitieren dann richtig mit "> " am Zeilenanfang und NICHT in Fettschrift!
Ja ich nutze ein /8er Maske.
Eine recht kranke IP Adressierung. Kein Netzwerker macht so einen Unsinn. Das Wort Segmentierung und VLANs ist sicher ein Fremdwort für dich in dem Zusammenhang, oder?! Aber egal...ohne Worte.Zitat von @aqui:
Bitte wenn zitieren dann richtig mit "> " am Zeilenanfang und NICHT in Fettschrift!
Bitte wenn zitieren dann richtig mit "> " am Zeilenanfang und NICHT in Fettschrift!
Ja ich nutze ein /8er Maske.
Eine recht kranke IP Adressierung. Kein Netzwerker macht so einen Unsinn. Das Wort Segmentierung und VLANs ist sicher ein Fremdwort für dich in dem Zusammenhang, oder?! Aber egal...ohne Worte.Nein das ist kein Fremdwort und wir verwenden auch separateVLANs für beispielsweise Multicast IP-TV. Unser Netzwerk funktioniert sonst auch sehr gut, deswegen sehe ich auch keinen Grund das zu ändern. Ich kann dein Bashing nicht nachvollziehen...
Na ja eine /8er Maske ist ja IP designtechnischer Unsinn. Das solltest du als gestandener Netzwerk Profi aber auch wissen und hat nichts mit Bashing zu tun. Aber egal...
Hier findest du noch weitere Infos zu deinem Fragmentierungsproblem:
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat. ...
(Kapitel: IP Do-Not-Fragment compatibility)
Hier findest du noch weitere Infos zu deinem Fragmentierungsproblem:
https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat. ...
(Kapitel: IP Do-Not-Fragment compatibility)
Ich habe jetzt mal in PFSense unter SystemAdvancedFirewall & NAT die Option "Disables the PF scrubbing option which can sometimes interfere with NFS traffic." Mal schauen obs jetzt klappt.
Das hat jetzt leider keine Besserung gebracht.
Ich habe jetzt testweise die Option in PFSense "Disable all packet filtering. Note: This converts pfSense into a routing only platform! Note: This will also turn off NAT! To only disable NAT, and not firewall rules, visit the Outbound NAT page." aktiviert.
Die Übertragung geht jedoch immer noch nicht durch.
Die Übertragung geht jedoch immer noch nicht durch.
Kapitel: IP Do-Not-Fragment compatibility
Danke für den Tipp. Ich hab die Option aktiviert, die Übertragung geht aber trotzdem nicht durch.
Dann wars das nicht und du kannst beide Settings wieder so einstellen wie sie waren.
Sinnvoll ist ggf. mal einen MTU Check zu machen
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
Wie betreibst du die pfSense am WAN Port??
Sollte das nicht reichen zusätzlich auf dem LAN Interface (wo die Kasse dran ist) den MSS Wert auf 1448.
Hast du zusätzlich dein FW Regelwerk gecheckt das du keine ICMP Type 3 und 4 Pakete filterst??
Sinnvoll ist ggf. mal einen MTU Check zu machen
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
Wie betreibst du die pfSense am WAN Port??
- Router Kaskade mit einem Router und doppeltem NAT/Firewalling davor?
- Mit einem NUR Modem (PPPoE Passthrough, Internet terminiert direkt auf der FW)
Sollte das nicht reichen zusätzlich auf dem LAN Interface (wo die Kasse dran ist) den MSS Wert auf 1448.
Hast du zusätzlich dein FW Regelwerk gecheckt das du keine ICMP Type 3 und 4 Pakete filterst??
Zitat von @aqui:
Dann wars das nicht und du kannst beide Settings wieder so einstellen wie sie waren.
Sinnvoll ist ggf. mal einen MTU Check zu machen
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
Wie betreibst du die pfSense am WAN Port??
Sollte das nicht reichen zusätzlich auf dem LAN Interface (wo die Kasse dran ist) den MSS Wert auf 1448.
Hast du zusätzlich dein FW Regelwerk gecheckt das du keine ICMP Type 3 und 4 Pakete filterst??
Dann wars das nicht und du kannst beide Settings wieder so einstellen wie sie waren.
Sinnvoll ist ggf. mal einen MTU Check zu machen
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
Wie betreibst du die pfSense am WAN Port??
- Router Kaskade mit einem Router und doppeltem NAT/Firewalling davor?
- Mit einem NUR Modem (PPPoE Passthrough, Internet terminiert direkt auf der FW)
Sollte das nicht reichen zusätzlich auf dem LAN Interface (wo die Kasse dran ist) den MSS Wert auf 1448.
Hast du zusätzlich dein FW Regelwerk gecheckt das du keine ICMP Type 3 und 4 Pakete filterst??
Ein riesiges Dankeschön aqui, MTU beim WAN auf 1488 und MSS beim LAN auf 1448 haben das Problem gelöst! Super!!!
Glückwunsch!! 👏 👍
Case closed.
Case closed.
