Messages

[EDIT:]

hallo zusammen.

ich würde am wochenende gerne mein single-node opnsense setup auf einen ha-verbund umstellen.
ich habe zwei DEC2752.

die WAN anbindung würde ich vorerst gerne via glasfaser von der Telekom lösen.
dafür würde ich gerne die eingebaute funktion zum sync von carp<->pppoe nutzen.

nach meinem verständnis muss ich zunächst ein vlan0.7 auf dem parent-hardwareadapter zum glasfasermodem anlegen.
auf diesem vlan0.7 wird dann ein pppoe-device angelegt und konfiguriert.
das mache ich auf master & backup und verbinde beide via switch mit dem modem.

laut diesem blog muss für die funktion "Disconnect dialup interfaces" CARP auch auf dem interface laufen. dem ist hier bewusst gewählt, ich weiss nämlich nicht auf welchem (parent->vlan->pppoe)?

könnte mich hier jemand in die richtige richtung weisen, ich versuche das aktuell virtualisiert zu testen und scheitere am dialup-disconnect für die backup-node.
aktuell wählen sich beide nodes auf meinem pppoe-test-server ein und halten die verbindung.
mit CARP auf dem vlan-interface bekomme ich einen "DISABLED" status für das carp-interface, aber weiterhin eine aktive pppoe-verbindung von beiden nodes.

[EDIT:] mit einigen debug-ausgaben in /usr/local/etc/rc.syshook.d/carp/20-ppp habe ich gesehen, dass warum auch immer "disconnectppps":"0" gesetzt war. in der web-view war der haken gesetzt. nach kompletten neu-konfigurieren und einigen reboots funktioniert es jetzt so wie gewünscht.
werde den thread schließen. CARP wurde auf dem vlan0.7 interface mit dummy-adresse(n) konfiguriert.

falls jemand anderes darüber stolpert, mit einem MTU = 1360 in der wireguard-config funktioniert es mit dem Vodafone DSL des nutzers ohne probleme.
icmp-pakete -f und 1360 < size < 1400 gehen verloren, während alles > 1400 needs to fragment meldet.

ist mss-clamping auf der server-seite das richtige, um diese probleme für alle zukünftigen benutzer zu verhindern?

Ich habe ein Problem mit einem spezifischen Intranet-Subnetz (`10.9.0.0/24`), wenn ein Windows-Client über DSL (Vodafone DSL) eine Wireguard-Verbindung aufbaut. Das Problem tritt nur bei einem bestimmten Nutzer auf.

Gibt es irgendeinen anderen Nutzer, der ebenfalls einen Vodafone DSL benutzt, und bei dem es läuft?

das weiss ich leider nicht.

auf welchem interface?
lokal beim nutzer oder am vlan-trunk auf der opnsense?
warum hat dann nur ein nutzer von ca. 35 dieses problem?
und warum scheint das von ip-adressen beeinflusst.

Ich glaube, ich habe hier ein etwas kniffliges Problem.

Ich habe mehrere Road-Warrior-Clients, die über WireGuard mit meiner OPNsense verbunden sind. Die OPNsense steht hinter einem DSL-Router+Modem, auf dem die VPN-Ports weitergeleitet sind.

Ich habe ein Problem mit einem spezifischen Intranet-Subnetz (`10.9.0.0/24`), wenn ein Windows-Client über DSL (Vodafone DSL) eine Wireguard-Verbindung aufbaut. Das Problem tritt nur bei einem bestimmten Nutzer auf.

# Symptome:

* HTTP/HTTPS-Verkehr zu `10.9.0.0/24` schlägt fehl (z. B. SSL-Handshake-Fehler).
* Ping- und DNS-Anfragen zu `10.9.0.0/24` funktionieren problemlos.
* Jeglicher Verkehr zu einem anderen Subnetz (z. B. `10.12.0.0/24`) funktioniert ohne Probleme.
* Der Wechsel auf einen anderen Internetzugang (z. B. mobiler Hotspot) löst das Problem.

Beide Subnetze befinden sich auf der gleichen Switching-Hardware und nutzen denselben Link zur OPNsense, mit VLANs getrennt.

Ich habe alle grundlegenden Dinge überprüft, wie Konfigurationen, Routing, NAT, Firewall-Regeln usw.
Bei der MTU bin ich mir unsicher, da grundsätzlich Verkehr funktioniert, aber ,,komplexere" Anwendungen fehlschlagen.
Ich sehe Pakete und Anfragen, aber die Handshakes gelingen nicht.
Ich werde versuchen, einen Packet-Capture zu erstellen, sobald der Nutzer diesen Internetzugang wieder verwendet.

Hat jemand eine Idee?
Ich verstehe es nicht wirklich.
Ich glaube nicht, dass ich vom ISP Hilfe bekomme.

I think i have a bit of a doozy here.

I have a couple of road-warriors connected via Wireguard to my OPNsense. The OPNsense is behind a DSL Router+Modem with my VPN ports forwarded.

I'm experiencing an issue with a specific intranet subnet (`10.9.0.0/24`) while connected via a WireGuard VPN from a Windows client using a DSL internet connection. This only happens for one user. He is using Vodafone DSL.

# Symptoms:

* HTTP/HTTPS traffic to `10.9.0.0/24` fails (e.g. SSL handshake failure).
* Ping and DNS requests to `10.9.0.0/24`succeed.
* Any traffic to a different subnet (e.g., `10.12.0.0/24`) works without issues.
* Switching to a different internet uplink (e.g. mobile hotspot) resolves the issue.

Both subnets are on the same switching hardware and use the same link to the OPNsense, they are separated by VLANs.

I have verified all the basic stuff, like configs, routing, NAT, fw-policies, etc. I am not to sure about MTU as I get traffic to work, but the more "complex" applications seem to fail. I see packets and requests but the handshakes dont succeed. I will try to get a packet-capture as soon as the user is using this uplink again.

Any ideas?
I have no hope of getting help from the ISP.

tl;dr: auswahl zwischen gw-group oder default-gw switching für ein physisches DEC2752 HA-setup

aktuell nutzen wir eine DEC2752, um etwa 10 vlans zu routen. außerdem gibt es einige eingehende wireguard-road-warrior-verbindungen und eine site-to-site-wireguard-verbindung zu hetzner.

ich möchte das setup mit einer zweiten DEC2752 und einem HA-setup erweitern; CARP-adressen und die ganze config-sync-geschichte.
dies habe ich bereits in einer virtuellen umgebung getestet.
es ist außerdem eine neue (zweite) WAN-verbindung geplant, daher wollte ich ein multi-wan-setup evaluieren.

jetzt bin ich mir nicht sicher, ob ich eine gateway-group konfigurieren oder einfach auf default-gw switching setzen soll.
ich habe diesen thread gelesen, aber er hat mir nicht wirklich weitergeholfen.
ich denke, ich könnte damit leben, dass bestehende verbindungen auf dem fallback-link bleiben, bis sie neu aufgebaut werden.
das einzige, worüber ich mir nicht ganz sicher bin, ist die initiierte wireguard-verbindung, aber wahrscheinlich wird es nach einiger zeit eine erneute verbindung geben.
das einrichten von gw-groups mit vielen firewall-regeln scheint aufwendig, aber irgendwie ,,sauberer" zu sein.

außerdem habe ich den opnsense als ntp-server konfiguriert, auf den alle meine lan-hosts zugreifen.
ich nehme an, dass hierfür eine eigene regel erforderlich ist?
ich nehme auch an, dass ich auch anti-lockout-regeln für einige der vlans konfigurieren muss?

kann mich jemand in die richtige richtung weisen, im hinblick auf mein setup?
oder auch grundsätzlich tipps und verbesserungen zu meinem setup geben?

tl;dr: choosing between gw-group or default-gw switching for physical HA setup

currently we are using a DEC2752 to route about 10 vlans, user and production workload. also it manages a couple of incoming wireguard road-warriors and establishing a site-to-site wireguard connection to hetzner.

i would like to extend the setup with a second DEC2752 and HA setup; CARP adresses and all the config-sync stuff.
i tested this in a virtual evironment.
there is also a new (second) WAN connection planned, so i wanted to evaluate a multi-wan setup.

now i am not really sure if i want to configure a gateway-group or just want to rely on default-gw switching.
i read through this thread, but it not really helped.
i think i can live with established connections to live on the fallback-link until there will be new connections.
only thing i am not all to sure about is the initiated wireguard connection, but there probably will be a re-connection after some time.
setting up gwgroups with a lot of firewall rules seems to be a lot, but somehow "smoother".

also i configured the opnsense as a ntp server which is accessed by all my lan hosts.
i assume this needs a special rule to allow?
i also assume i need to configure special anti-lockout rules for some of the vlans?

can someone point me in the right directions, with respect to my setup?

[lacp-lagg on opnsense]

i know this is a long shot; help would be appreaciated no matter what.
im out of ideas.
we already tried everything on the azure-devops side.
i still want to restart the whole setup;

TL;DR
we're experiencing slow cloning speeds (6 mbit/s) from azure devops when using lacp-lagg on opnsense in a production environment. testing shows that bypassing opnsense or using a different (local) uplink improves speeds significantly. the issue seems specific to this setup, as public repos clone at expected speeds. replicated tests in a similar environment did not reproduce the issue. potential factors include lagg configuration, cascading nat, or something specific to azure devops.

#### problem description:

we're encountering slow cloning speeds (around 6 mbit/s) when cloning our private repository from azure devops in a production environment. this setup consists of a axge lacp-lagg on an opnsense DEC2750 appliance as the gateway for machines in a vlan-trunked subnet, connecting several proxmox-pve server with sfp+ connections, cascaded with a fritzbox 5g. this setup is far from optimal but for now we have to work with it. the problems somehow started when moving to the lacp-lagg, but might be completely unrelated. switching is done by two HP 5900AF 48XG stacked via IRF.

#### production environment testing:

-lagg trunk performance: peer-to-peer (pve-to-pve) bandwidth tests using iperf show expected speeds of around 10 gbit/s. when passing or testing the opnsense appliance directly, it drops to around 2 gbit/s single-threaded. i read that single-thread iperf tests might not be very realistic so i multi-threaded which caps at around 5gbit/s.
-build servers: cloning on both windows and linux virtual machines via the opnsense lagg setup results in the slow speeds mentioned. however, switching to a (exclusive switched) different subnet improves the speed by a factor 10. using a dedicated uplink to the fritzBox provides expected cloning speeds. interestingly, cloning a public repository (e.g., wireshark) also achieves much faster speeds from wherever in the setup. speedtests on all machines (vms, hosts, opnsense itself) reaching speeds as they should be (maximum provided by fritzBox).

#### test environment insights:

to investigate, we replicated the setup in a test environment, with a single switch and a stack, but the issue could not be consistently reproduced. uplink was also cascaded NAT. i played with tunables and all lacp setting available on switch, opnsense and pve-host. no difference at all, except for +5%~ more throughput via opnsense after some tunable settings.
-lagg bandwidth: testing with iperf shows that a single thread on the lagg trunk via opnsense reaches around 2 gbit/s, while multi-threading improves performance to about 6 gbit/s.
-routing performance: tests showed slightly better routing performance across vlans, than testing in-vlan, but bandwidth is still capped, likely due to hardware or configuration limitations. appears somehow weird to me.
-cloning was as fast as expected; no matter what vlan, machine or repo.

#### conclusion:

- i can verify the uplink "problems" of the opnsense appliance, people on the internet say a single iperf thread wont saturate a 10Gbit/s uplink; pve-hosts can do it somehow; switching seems less performant than routing (??) -> hardware?
- these uplink "problems" dont seem to directly affect cloning speed, at least it was not observed in test-env.
- somehow tuning opnsense or rather freebsd via system-tunables seems necessary on non-opnsense hardware and 10GBE as described by some people (see https://calomel.org/freebsd_network_tuning.html). -> not sure how/if necessary or to which extent on opnsense hardware.
- i cant reproduce cloning issues when cascading NAT or traversing LAGG or vlan-trunks -> some extremely weird 5G uplink issue?
- other (public-internet) repos can be cloned with reasonable bandwidth -> azure(-devops) issue, repo issue, see above?