Probleme bei VPN-Netz und SICCT Kommunikation

[sebden]

Hallo Forum,

ich habe hier ein nicht zu lösendes Problem. Hier kommunizieren 2 Geräte über ein VPN-Netz miteinander via SICCT-Ports, was in einer bestimmten Konstellation bisher nicht läuft. Zuvor hier die funktionierende Konfigurationen:

Hauptgerät SICCT <-> Fritz!Box <-> IPsec <-> Fritz!Box <-> Clientgerät SICCT

Hauptgerät SICCT <-> pfSense <-> IPsec <-> Fritz!Box <-> Clientgerät SICCT

Was nicht geht ist:

Hauptgerät SICCT <-> Fritz!Box <-> IPsec <-> pfSense <-> Clientgerät SICCT

Bevor es um irgendwelche Ports geht, ich hatte bereits Regeln erstellt, die beidseitig jedweden Port sowie Protokoll erlauben zwischen den 2 SICCT Geräten. Auch beachtet wurde, das die Regeln dann jeweils am IPsec Interface (kommend) sowie am LAN Interface (gehend) gesetzt wurden. Schon zu diesem Zeitpunkt war laut Log kein einziger Block in dieser Kommunikation zu sehen.

Dennoch hatte ich auch zum Test gleichwertige floating Regeln gesetzt, mit dem gleichen erfolglosen Ergebnis.

Ich erkenne hierbei immer, dass es States vom Hauptgerät zum Clientgerät gibt, jedoch nie umgekehrt. Das Clientgerät scheint hier Anfragen zu verweigern, bis das Hauptgerät "aufgibt". Die Kommunikation läuft für mein Verständnis über SICCT Ports z.B. 4742 und aber auch irgendwie HTML-basiert mit Proxys oder Webähnlichen Seiten in den Gerätschaften. Dort kann ich aber nicht hineinblicken. Laut den Supportern der Gerätschaften erkennt das Clientgerät manipulierte Pakete, was wohl typisch sei beim Einsatz sog. Packetfilter (pf ???). Testweise hatte ich auch schon SNORT deaktiviert, welches hier installiert ist.

Vielleicht fällt jemandem spontan ein wieso 2 der Konfigurationen laufen und ausgerechnet die letzte (pfSense in der Außenstelle beim Clientgerät) nie.

Grüße aus Brandenburg!

[Gladius]

@sebden said in Probleme bei VPN-Netz und SICCT Kommunikation:

Auch beachtet wurde, das die Regeln dann jeweils am IPsec Interface (kommend) sowie am LAN Interface (gehend) gesetzt wurden.

Was soll hier (gehend) bedeuteten?

Firewall rules control what traffic is allowed to enter an interface on the firewall

[sebden]

Bedeutet dass die Regeln auf LAN so gesetzt sind, dass die Geräte auswärts kommunizieren können und zur Sicherheit auch kommend an der IPsec Schnittstelle der jeweiligen pfSense.

Hierbei wusste ich lediglich nicht ob via IPsec ohnehin alles erlaubt wird was nicht verboten wurde, oder auch hier eine any/any Regel sinnvoll wäre. Daher hatte ich jeweils mit Ziel- oder Quell-IP alles freigegeben. Protokoll: any Port: any

Spätestens an diesem Punkt hatte ich erwartet, dass die Geräte sich "pairen" können, wie es im gleichen Szenario mit 2 Fritz!Boxen derzeit geht.

[Gladius]

@sebden said in Probleme bei VPN-Netz und SICCT Kommunikation:

Bedeutet dass die Regeln auf LAN so gesetzt sind, dass die Geräte auswärts kommunizieren können

Wenn die Regeln im LAN-Interface reinkommende Pakete durchlassen, gehen diese ohne Regel/n wieder raus.

Warum sollte hier "Floating" eingesetzt werden?

[sebden]

Nur zum Testen. Dennoch auch hier kein Block in der FW und dementsprechend keinen Erfolg. Grundlegend finden sich die Geräte, beim "Pairing" lehnt das Clientgerät jedoch jedwede Kommunikation ab. Die Erklärung sei durch die pf manipulierte Pakete. Hierbei wird u.a. TLS verwendet.

[Gladius]

Wenn das Clientgerät Pakete von pfSense empfängt könnte man sie mit denen von der Fritzbox
(im funktionierenden Fall) vergleichen und die Unterschiede (Manipulation durch pfSense)
finden.

Danach ist man möglicherweise schlauer.