UDP auf WAN, klappt nur mit [ x ]Disable reply-to on WAN rules

[linuxmail]

Hi,

wir haben PFSense Hosts zu  OpnSense (19.1.7) umgebaut, damit wir das gleiche Konstrukt haben (aber mit 19.1), wie in unserem anderen RZ. 
Leider sind wir auf das Phänomen gestoßen, dass UDP nicht klappt.  Unser Interface "DMZ(WAN)" hat alle passenden Regeln und es findet sich auch kein Block in der Log. Durch Zufall haben wir die Funktion  [ x ]Disable reply-to on WAN rules akiviert und siehe da, plötzlich ging auch UDP.
In unserem RZ B, ist diese Funktioniert nicht aktiv, der Rest ist aber sonst identisch. Wir haben auch kein Multiwan etc. sondern das WAN Interface ist bei uns das DMZ.

Die ersten Probleme mit UDP kamen auf, als ich SNMP auf der OpnSense eingerichtet habe und es einfach nicht klappen wollte. Es hat sich gezeigt, auf der OpnSense funktionierte mein SNMPwalk, aber vom Monitoring Host nicht (dieser geht auf das DMZ(WAN) Interface).
Wird die Firewall deaktiviert (pfctl -d) klappt alles. Setzen wir die eingangs erwähnte Option ... klappt es ebenfalls.

Wir sind daher ein wenig ratlos ... wo das Problem liegt. Ich sollte nicht unerwähnt lassen, dass wir die Aliase von unserem anderen RZ mittels XML Änderung importiert haben, ebenso wie die Firewallregeln.
Meine UDP Probleme (bezogen auf SNMP) hatte ich aber noch vor den Imports.

cu denny

[micneu]

ich bin immer der meinung, wenn ich eine neue firewall aufsetze, nutze ich es auch gleich meine FW-Regeln mal zu prüfen ob die noch so sinn machen oder nicht, also mal neu von vorne aufsetzen.
ich kann nicht sagen wie ihr euer problem löst, aber es währe eine chance einfach mal von null anzufangen.

[franco]

PfSense hat hier einen Custom Kernel Patch. Wir haben ihn nicht aus verschiedenen Gründen.

Das Problem ist hier dass für angeschlossene WAN-Netzwerke Reply-To bei beiden standardmässig an ist, aber durch den Custom-Patch in PfSense Reply-To im lokalen WAN ausgehebelt wird. Bei uns passiert das nicht, d.h. Reply-To wird weiter an den Gateway geschickt. Und dann passiert es... ist der Gateway mürrisch, dann gibt er das Paket nicht zurück ans interne Netz sondern verwirft es oder leitet es ins Internet. ;)

Muss dazu gesagt werden, dass es auch Gateways gibt die das ohne Probleme mitmachen mit dem internen Weiterreichen.


Grüsse
Franco

[linuxmail]

hi,

ich bin immer der meinung, wenn ich eine neue firewall aufsetze, nutze ich es auch gleich meine FW-Regeln mal zu prüfen ob die noch so sinn machen oder nicht, also mal neu von vorne aufsetzen.

das müssen wir ohnehin immer alle 6 Monate. Aber da die Rechenzentren spiegelverkehrt sind, ist es so einfacher.

cu denny

[linuxmail]

hi,

@franco

hat sich das irgendwie zwischen 19.1 und 19.4 geändert ? Im spiegelgleichen RZ stellen wir dieses Phänomen nicht fest. Die Gateway Adresse liegt auf einem CARP Interface und hat eine  Fortigate 100D als Ziel IP.

Des weiteren verstehe ich auch nicht, wenn das auch bereits im gleichen Netzwerk passiert (Monitoring - > OpnSense Host). Da käme noch gar kein Gateway zum Einsatz.

cu denny

[franco]

Hi,

Nein.


Grüsse
Franco

[mimugmail]

Das hört sich für mich alles nach Upstream Gateway im Interface gesetzt an ... wenn du ein Gateway eingetragen hast mit Haken default, raus damit.

[linuxmail]

hi,

@mimugmail

wir schauen mal nach, ob dem so ist. Allerdings würde ich auch hier Probleme mit TCP erwarten, sei es wegen Latenz, oder weil Pakete verloren gehen.

Nachtrag:

eben geschaut. Alle interfaces haben "Auto-detect" eingetragen.


cu denny