Messages

Hallo,

ich sehe das wie folgt:

Es gibt zwei WAN-Netze.
Ob das "Transfer" heißt, ist in dieser Betrachtung unerheblich, da alles im Internet eine Sammlung von Transfernetzen ist.

Die L2-Information ist ebenso zu vernachlässigen, wenn die VLAN-IDs dann zueinander passend konfiguriert sind.

Jeweils das gegenüberliegende Interface gilt es zu pingen.
Funktioniert das?

Danach Mulit-WAN und destination NAT und source NAT.

Oder?

Morris

Hallo,

ist das Problem noch offen?

1. Ich würde mit einem WAN-Interface statisch. anfangen.
2. Dann das eingehende und das ausgehende NAT
3. Danach mit nur dem 2. WAN-Interface den gleichen Test
4. Im Anschluß gewuchtetes Multi-WAN

(Zwei L3-Interfaces im selben Netz ist in jedem Fall falsch, da kein eindeutiges Routing möglich ist. Wichtig ist zudem, asyncrones Routing zu vermeiden.)

Morris

Hello,

my IPSec-VPN (OPNsense 23.7.9) works fine,
i can ping the remote network.

My question: How can i see the kernel routing entry for the remote VPN networks?
route show <remote network>
and
netstat -rn
will show the default route instead the route through the VPN IPSec.

Perhaps this is a policy based route on strongswan?

Thanks.

Morris

Hallo,

OPNsense als BSD-Betriebssystem ist natürlich in der Lage, alle Performance zu gewähren.
Demzufolge gehen auch 10 Bit/s Anschlüsse.

Sofern keine weiteren Softwaremodule eingesetzt werden, sollten gut bis sehr gute Server die Performance liefern.
(Was ich mit gut bis sehr gute Hardware meine, kann ich nicht sagen, da ich mich mit Serverhardware nicht auskenne.)

Eine Trennung von VLANs an einer Firewall macht Sinn und ist sogar notwendig, eigentlich alternativlos.

Mein konkreter Vorschlag ist, einen Server mit den Ports zu beschaffen und im ersten proof of concept die Performance zu ermitteln. Das Ergebnis wird eine Auslastung von 20-30% sein. Damit kann man sich produktiv wagen.
Notfalls kann man über 2 CARP/VRRP-Gruppen eine Lastverteilung vornehmen, was ich jedoch nur im Notfall und nicht im planbaren Fall umsetzen würde.

OPNsesne als virtuelle Maschine ist klar:
https://www.iternas.com/post/installation-von-opnsense-in-einer-virtuellen-maschine


Sollte das Problem noch ernsthaft in Diskussion sein, so würde ich unsere Eingesetzen FWs mal auf Performance und Auslastung prüfen und dir dann Rückmeldung geben.


Viele Grüße


Morris Görke

Fehlversuche:
Wenn du per tcpdump auf den Interfaces mitloggs, dann sollte es nur von einem Interface carp/vrrp Packet (Type 112) geben.
Senden beide Interfaces CARP-Pakete, so sehen sich die CARP-Member nicht, warum auch immer. Mit einer direkten Verkabelung kann der Switch ausgeschlossen werden.

Ebenso sollte Preemtion geprüft werden, es muß derart eingestellt sein, dass der geplante Master auch immer wieder sich zum Master priorisiert.

Spanning Tree hat doch nichts mit LWL oder Kupfer zu tun?

Portfast bedeutet, dass SpanningTree nicht abwartet, sondern die (Access-)Ports direkt ins Forwarding bringt. Dies sollte hier kein Problem sein, da früher oder später die Frames dann doch weitergeleitet werden.
Nein, SpanningTree hat nichts mit Kupfer oder LWL zu tun.

Die Frage ist, ob IGMP Snooping sich in die Mutlicast Pakete einmischt. Um das Auszuschließen, wäre eine testweise direkte Verkabelung statt über einen Switch hilfreich.