Messages

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

hi,

ich klinke mich mal hier ein, da es danach aussieht, als wenn das Problem exakt dem entspricht, was wir hier haben: https://forum.opnsense.org/index.php?topic=8915.0

Ich versuche jetzt die Onboard Netzwerkkarte durch USB zu ersetzen (keine freien Slots/Ports mehr) und dann schauen wir, ob das Problem besteht. Ich vermute es wird funktionieren.

hi,

wir haben ein Problem mit Carp, welches wir nicht gelöst bekommen. Wir haben die aktuellste Version von OpnSense und IPMI Firmware. Als Mainboard haben wir je ein Supermicro X11SSH-F, welches über zwei reguläre 10Gb/s Netzwerkports und einem Shared IPMI/LAN mit 1Gb/s verfügt. Die zwei 10Gb haben VLAN aktiv und funktionieren ausgesprochen gut und hatten da nie ein Problem. Bei dem IPMI/LAN dagegen funktioniert CARP überhaupt nicht. Beim Schwenk verbleibt der Status je im Init.

Was ich im dmesg für z.B ix0 (10Gb/s)

Code Select Expand


....
ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> port 0xe020-0xe03f mem 0xdfc80000-0xdfcfffff,0xdfd04000-0xdfd07fff irq 17 at device 0.0 on pci2
ix0: Using MSIX interrupts with 9 vectors
ix0: Ethernet address: 90:e2:ba:db:48:78
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
ix0: netmap queues/slots: TX 8/2048, RX 8/2048
ix0: link state changed to UP
ix0: promiscuous mode enabled
carp: 50@ix0: INIT -> BACKUP (initialization complete)
carp: 55@ix0: INIT -> BACKUP (initialization complete)
carp: 50@ix0: BACKUP -> MASTER (master timed out)
carp: 55@ix0: BACKUP -> MASTER (master timed out)
...


Und nun für ix2 (1Gb/s shared)

Code Select Expand


ix2: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> mem 0xdf800000-0xdf9fffff,0xdfa04000-0xdfa07fff irq 16 at device 0.0 on pci5
ix2: Using MSIX interrupts with 9 vectors
ix2: Ethernet address: 0c:c4:7a:cb:ac:78
ix2: PCI Express Bus: Speed 8.0GT/s Width x4
ix2: netmap queues/slots: TX 8/2048, RX 8/2048
ix2: promiscuous mode enabled
carp: 40@ix2: INIT -> BACKUP (initialization complete)
ix2: link state changed to UP
ifa_maintain_loopback_route: deletion failed for interface ix2: 3
ifa_maintain_loopback_route: deletion failed for interface ix2: 3
ifa_maintain_loopback_route: deletion failed for interface ix2: 3
carp: 40@ix2: BACKUP -> INIT (hardware interface up)



Auf dem Interface IX2 sind auf jedem Rechner je eine IP Adresse für das Management zugeordnet worden. Auf dem gleichen physischen Port hängt aber ebenfalls das IPMI was auch eine IP Adresse aus dem gleichen Bereich bekommen hat. Wir haben schon probiert dem IPMI ein VLAN (1) mitzugeben und es auf dem Switch mit "tagged" konfiguriert. Es hat aber nicht geholfen.

Wenn man nun beide mit einander vergleicht, kann man sehen, dass..:

Code Select Expand


ix0: link state changed to UP
ix0: promiscuous mode enabled


Code Select Expand


ix2: promiscuous mode enabled
carp: 40@ix2: INIT -> BACKUP (initialization complete)
ix2: link state changed to UP


sich die Zeilen unterscheiden. Bei Ix0 kommt zuerst Link Up und dann "promiscuous mode enabled", bei ix2 jedoch zuerst "promiscuous mode enabled" und dann "link state changed to UP". Wir wissen nicht, ob dieses Detail wichtig ist, aber das ganze sorgt halt leider dafür, dass Carp für dieses Interface nicht funktioniert. Das einzige was dann zügig hilft ist es, Carp auf z.B. dem Backup kurz zu deaktivieren und dann wieder zu aktivieren. Innerhalb von 1-2 Sekunden ist Carp dann wieder im Master-Backup.

Wir haben auch bereits zig Howtos und Parameters durchprobiert, die im Zusammenhang mit Carp stehen, aber nichts hat geholfen. Wir tippen daher aktuell auf einen Bug in OpnSense, da in unserem anderen Rechenzentrum wir das Identische Konstrukt haben, mit der Ausnahme, dass dort PfSense statt OpnSense läuft.

Hat da jemand ähnliche Probleme ?