PFSense: Problem bei der Übertragung einer XML-Datei an den Fiskus

ecartman316
Goto Top
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.

Content-Key: 3191359931

Url: https://administrator.de/contentid/3191359931

Ausgedruckt am: 15.08.2022 um 17:08 Uhr

Mitglied: Njord90
Njord90 27.06.2022 um 16:02:45 Uhr
Goto Top
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.
Mitglied: ECartman316
ECartman316 27.06.2022 um 16:06:59 Uhr
Goto Top
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.
Mitglied: Njord90
Njord90 27.06.2022 um 16:10:20 Uhr
Goto Top
Dann würde ich definitiv mit Wireshark den Traffic verfolgen.

Denke mal solche Sachen wie doppelte IP-Adresse hast du schon kontrolliert?
Mitglied: ECartman316
ECartman316 27.06.2022 um 16:12:51 Uhr
Goto Top
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.
Mitglied: StefanKittel
StefanKittel 27.06.2022 um 16:45:11 Uhr
Goto Top
Vieleicht kann die Kasse schlicht keine der aktuelle Verschlüsselungen und es liegt gar nicht an Deinem Anschluss.
Mitglied: ukulele-7
ukulele-7 27.06.2022 um 16:45:51 Uhr
Goto Top
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?
Mitglied: ECartman316
ECartman316 27.06.2022 um 17:06:54 Uhr
Goto Top
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.
Mitglied: ChriBo
ChriBo 27.06.2022 um 17:10:06 Uhr
Goto Top
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
Mitglied: colinardo
colinardo 27.06.2022 aktualisiert um 17:21:10 Uhr
Goto Top
Servus.
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
Mitglied: mossox
mossox 27.06.2022 aktualisiert um 17:15:13 Uhr
Goto Top
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.
Mitglied: magicteddy
magicteddy 27.06.2022 um 17:15:57 Uhr
Goto Top
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.
Mitglied: aqui
aqui 27.06.2022 aktualisiert um 18:51:25 Uhr
Goto Top
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!
Mitglied: ECartman316
ECartman316 07.07.2022 um 08:23:19 Uhr
Goto Top
Hallo, habe den Paket Capture durchgeführt.

Wie kann ich den Inhalt der entsprechenden .cap - Datei hier im Forum am Besten veröffentlichen?
Mitglied: aqui
aqui 07.07.2022 aktualisiert um 08:28:08 Uhr
Goto Top
In Wireshark laden und Screenshots. Oder DU kannst doch auch schlicht und einfach beschreiben was der Capture dir für Erkenntnisse gebracht hat!
Mitglied: ECartman316
ECartman316 07.07.2022 aktualisiert um 08:39:41 Uhr
Goto Top
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
Mitglied: ECartman316
ECartman316 07.07.2022 um 08:50:47 Uhr
Goto Top
wireshark seite 1
wireshark seite 2
Mitglied: aqui
Lösung aqui 07.07.2022 aktualisiert um 09:15:53 Uhr
Goto Top
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... face-sad
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)
Mitglied: ECartman316
ECartman316 07.07.2022 um 09:25:12 Uhr
Goto Top
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.
Mitglied: aqui
aqui 07.07.2022 aktualisiert um 09:29:47 Uhr
Goto Top
Bitte wenn zitieren dann richtig mit "> " am Zeilenanfang und NICHT in Fettschrift! face-sad
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.
Mitglied: ECartman316
ECartman316 07.07.2022 um 09:39:45 Uhr
Goto Top
Zitat von @aqui:

Bitte wenn zitieren dann richtig mit "> " am Zeilenanfang und NICHT in Fettschrift! face-sad
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...
Mitglied: aqui
aqui 07.07.2022 aktualisiert um 09:42:11 Uhr
Goto Top
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)
Mitglied: ECartman316
ECartman316 07.07.2022 um 09:58:59 Uhr
Goto Top
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.
Mitglied: ECartman316
ECartman316 07.07.2022 um 10:16:18 Uhr
Goto Top
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.
Mitglied: ECartman316
ECartman316 07.07.2022 um 10:52:09 Uhr
Goto Top
>Kapitel: IP Do-Not-Fragment compatibility

Danke für den Tipp. Ich hab die Option aktiviert, die Übertragung geht aber trotzdem nicht durch.
Mitglied: aqui
Lösung aqui 07.07.2022 aktualisiert um 11:36:34 Uhr
Goto Top
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)
Wenn es Letzteres ist solltest du einmal testweise die MTU setzen auf dem WAN Port auf einen Wert von 1488.
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??
Mitglied: ECartman316
ECartman316 07.07.2022 um 11:43:32 Uhr
Goto Top
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??
  • Router Kaskade mit einem Router und doppeltem NAT/Firewalling davor?
  • Mit einem NUR Modem (PPPoE Passthrough, Internet terminiert direkt auf der FW)
Wenn es Letzteres ist solltest du einmal testweise die MTU setzen auf dem WAN Port auf einen Wert von 1488.
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!!!
Mitglied: aqui
aqui 07.07.2022 um 17:16:09 Uhr
Goto Top
Glückwunsch!! 👏 👍

Case closed. face-wink