Categories

  • 376 Topics
    1k Posts
    fractal_boyF
    @dgeist there is a bug on TNSR that prevents to learn neighbor mac while you have map enabled on the interface. The workaround is to configure static neighbor entry.
  • 122k Topics
    782k Posts
    chpalmerC
    @giuliafw70 Thanks! I only use "Packet Loss" now and it seems to bring it in around 13 seconds which isn't the end of the world.. I figured though if I had an "and" option that I could dial down to tighter numbers for packet loss and during an actual outage the latency would increase at the same time triggering a bit sooner.. but I see your point. During evening hours we tend to go up in latency to my first gateway to over 30ms. (its normally somewhere from 8ms to 12ms.) I do not want that by itself triggering an outage so would have to at least double that to stay away from false triggering. Ill keep trying to tighten it up a bit more.
  • 21k Topics
    130k Posts
    G
    For a Pi-hole on the same LAN, the missing piece is often not a pfSense static route. The LAN is directly connected, so pfSense already knows both 10.0.0.0/24 and 172.16.70.0/24. I would check two things: the WireGuard client AllowedIPs includes 10.0.0.0/24 if you are split tunneling, and the Pi-hole either uses pfSense as its default gateway or has a route back to 172.16.70.0/24. If the Pi-hole's gateway is something else, replies can go the wrong way even though the pfSense rule is wide open.
  • 43k Topics
    268k Posts
    JeGrJ
    @tpf said in Wireguard S2S MultiWAN als Endpoint: Tunnel clonen mit anderer Endpoint-IP oder gibts ne Möglichkeit wie bei OpenVPN mit einem zweiten remote-Eintrag? Eine Möglichkeit - sollte das in WG gefixt sein - wäre, die A Seite mit nem DynDNS auszustatten und diesen über eine Failover Gatewaygruppe zu bespaßen. Sobald A auf A2 geht, wird dyndns neu gepusht da FailoverGW als Watch-Interface und pusht den neuen Eintrag, B sollte das dann lernen durch Neuauflösen des DNS. Da gabs aber meine ich Probleme, dass WG das nur einmal beim Starten mal einliest aber später nicht mehr so häufig, da ist mir nicht bekannt aktuell, ob das gefixt wurde. Ansonsten würde ich Wireguard da weglassen. Da Seite B eh mit "dynamischen" Anschlüssen "gesegnet" ist, bringt Wireguard mit seiner -Schummelei nicht wirklich einen Vorteil, da die A Seite die IP nicht kennt, also eh B immer aufbauen muss. Und wenn beide Seiten pfSense mit DCO Support sind, ist auch Geschwindigkeit überhaupt kein Thema mehr wo wireguard großartig voraus ist. Wireguard ist gerade in solchen MultiWAN Szenarien leider ein extrem undankbares Stück. Mein Take wäre: OpenVPN auf Seite B als Client konfiguriert auf einer Gateway Failovergruppe (damit B dynamisch auf B1/B2 schwenken kann). Wenn gewünscht kann die Failovergruppe sogar invertiert genutzt werden, also bspw. "Normalzustand" für Traffic B1 -> B2 Failover. Wenn B2 aber nicht signifikant kleiner ist als B1 kann man einfach ne zweite Gruppe anlegen mit B2->B1 und packt das VPN darauf. Fällt was aus, greift die entsprechende FO Gruppe (entweder Default B1 auf B2 oder VPN von 2 auf 1). Sehr angenehm um die Leitungen parallel zu nutzen. Dann packt man in der Config einfach zwei "remote" Statements rein und priorisiert da die Leitung, die man auf A Seite lieber haben möchte und kann da dann ebenfalls bspw. invers zum normalen Betrieb agieren, damit bspw. der Tunnel nach Möglichkeit so läuft, dass er auf der "leeren Leitung" läuft, auf der grad nicht gesurft wird. Mit OVPN und FO Gruppen super zu machen :) und dank einstellbarem Timeout und Keepalive Timer kann der Failover auch schnell greifen. Oder man könnte auch wenn man will zwei Tunnel mit A1/B1 und A2/B2 parallel bauen, nur mit Transfernetz dazwischen und die Route dynamisch hin und her switchen lassen, das ist aber IMHO für den Zweck ein wenig overdosed ;) Cheers \jens
  • Information about hardware available from Netgate

    3k Topics
    21k Posts
    S
    @stephenw10 said in 7100 : spoof MAC ?: Nice. Good result! It's an honor to hear this from you, thanks ;-)
  • Information about hardware available from Netgate

    44 Topics
    211 Posts
    AriKellyA
    It looks like unified web management could be coming soon. It would be great if it means easier control and management of all web services in one place. Let's see if any companies announce more details about it!
  • Feel free to talk about anything and everything here

    4k Topics
    19k Posts
    stephenw10S
    You're right it shouldn't. I tested all the skins myself and all have parts that don't display correctly. Using dark reader solved almost everything and was trivial so I went with that.
Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.