Messages

Sollte recht einfach sein.

• OpenVPN Client einrichten
• Interface assignen
• Gateway auf dem OpenVPN IF anlegen, falls es nicht schon automatiusch erstellt wurde
• In der Firewall Regel auf dem LAN Interface der Sense dann als Gateway das OpenVPN Gateway auswählen
• Unter Umständen noch passende Outbound NAT Regeln anlegen

Somit hat die Sense (hoffentlich) weiterhin ihre Default Route über die Fritzbox, aber der Traffic aus deinem LAN wird ins VPN gestupst.

Is that BGP peer connected to your WAN interface?

If yes, try ticking the box on "Disable force gateway" under advanced firewall options.

Looks like this is the piece of code responsible for receiving that information:
https://github.com/opnsense/core/blob/fb041467bf17155b1736b42c8e65a769f984d0b1/src/etc/inc/interfaces.lib.inc#L352-L357

It seems to parse the output of "ifconfig -m -v [interface]" and assumes that there are only these two lines (active and flapping porst). Can you try that command on the CLI and see if there's something else? Could be a misinterpretation.

Hey comm,

so i tried to put in some effort recently to make the FRR plugin more of a first-class citizen. First thing i did was (try to) get rid of the dependency on lodash on the diagnostics pages. It's not that hard to do, all the components are basically there anyway.
The thing is, it takes time, a lot of it. This may be in part because i don't do that much coding, especially frontend stuff. But still, i spent a whole day just reworking the BGP page.
I did put in quite a bit of time and effort to attempt to make a generic, extensible Diagnostics template that can be re-used for the other pages, which i would now hope are a breeze to implement. And i also learned a lot about the nifty internals of Bootgrid.

But still, i had to introduce some fiddly JS code to convert the API output into something Bootgrid can understand. Then some other stuff that all in all is not that much - but everytime i spend an evening or a few hours working on these pages i ask myself "Wouldn't it be better to just present FRR's textual output to the user and not think about it anymore"?
It would for sure be a lot less code. Less code, less bugs, more time to spend working on other improvements. I see no big impact on usability from an admin's perspective, at least personally i don't mind reading text vs having the same information prettified in HTML.

Then again, i'm not sure if this is in line with the vision of OPNsense as a whole, and i do believe that routing protocol support is going to become increasingly important for more users in the future. So i'd like to open this thread for a discussion around the plugin and where to go with it. Specifically the diagnostics section.


On another note, and somewhat related, is the topic of the API implementation. Right now it passes through whatever FRR produces which, on the one hand, is a bit annoying when you deal with Bootgrid for example. On the other hand, it can potentially make people with existing tooling very happy because they can just continue using whatever scripts they have for FRR already. Plus whatever code snippets may be out there on stackoverflow or Github will also just work.
So my Q is, is it better to move the complexity of restructuring FRR's JSON output into the Backend and try to make the API output more uniform? Or is that best left in the frontend? Again i can see arguments for both sides...

/discuss


(edit: if you'd like to see my WIP to understand what i'm talking about, here's the branch on my fork: https://github.com/marcquark/plugins/tree/diagnostics-overhaul)

I don't know what Minecraft requires specifically but i do know that Mario Kart is P2P and thus requires UPnP in order to dynamically open up ports from the outside in. There's a plugin for that called os-upnp. It should be pretty self-explanatory.

As far as i can tell this one will only work if your WAN interface is directly connected to your ISP i.e. holds the actual public IP address(es). If you have double-NAT or other shenanigans, or CG-NAT from your ISP, you might be out of luck. If it worked before with your Fritzbox though, you should be able to get it to work with OPNsense aswell.

Hab bei mir mal durchgeschaut: Ich kann meine automatisch generierten Gateways gar nicht deaktivieren... Auch interessant...

EDIT: Bei mir sind die Regeln mit "Reply-To: default" angelegt, funzt aber alles...

Bei S2S funktioniert das nach meiner Erfahrung auch, bei Roadwarrior allerdings nicht. Die Gateways kann man deaktivieren wenn man auf Edit geht und dann den Haken setzt

Hattest du das Interface assigned?
Falls ja, deaktivier' mal das automatisch erzeugte Gateway. Sonst erzeugt OPNsense dir im Default deine Regeln mit reply-to und der Traffic verschwindet in einem magischen Blackhole, siehe auch https://docs.opnsense.org/troubleshooting/openvpn.html

Gut und hier noch die Screenshots :-D

https://github.com/opnsense/plugins/blob/master/net/frr/src/etc/inc/plugins.inc.d/frr.inc
November 2018.

Ah, jetzt erinnere ich mich, die Regeln werden erstellt, wenn man über Networks arbeitet, aber nicht wenn man stattdessen die Interfaces benutzt und Networks leer lässt. Ist vermutlich Geschmackssache, auf welche Weise man OSPF aktiviert.

(Text)

Top! Dann hab ich ja mit meinem uralten CCNA Halbwissen und einer Weile überlegen am Ende eine gute Lösung für mich erarbeitet :-D

Vermutlich sollte man dann aber den Teil meiner "Empfehlung" streichen, auch die verbundenen Interfaces, die nicht am OSPF beteiligt sind, noch mal extra in den Interfaces Tab einzuklimpern. Stattdessen ist es dann absolut richtig und gut, wenn deren Subnetze jeweils als External auftauchen. Sowas hatte ich auch irgendwo schon vermutet, da diese Netze ja selbst nicht am OSPF beteiligt sind und somit "extern" und von genau einem Knoten aus erreichbar (der an dem sie halt dran hängen) und dieser ist dann ASBR. (ja ich wiederhole Quasi deine Worte aber es hilft, sowas noch mal in eigenen Worten wiederzugeben)



@TE super dass es mit der Route Map jetzt geklappt hat. Genau so in der Art mache ich es auch. Ich hänge dir mal noch zwei Screenshots an für ein 0815 default setup, das du zum internen Gebrauch locker nutzen kannst. Für einen ISP der im IGP auch mal öffentliche IPs hat taugt das natürlich nicht... ;)

Was mir auf jeden Fall im Vergleich zu einem Linux System auffällt ist, dass die Interface Config bei OpenVPN Interfaces anders aussieht. Das Interface hat keine Netzmaske, dadurch hat die Interface-Route im Kernel ein Gateway (die zweite Adresse im Subnet - warum auch immer).
Unter Linux gibt's eine ganz normale Interface Route. Auf den EdgeRoutern unter meiner Fuchtel verhalten sich die VPN Interfaces diesbezüglich komplett so wie man es erwarten würde, nämlich so wie jedes andere Interface auch. Unter FreeBSD gibt's da leider immer wieder seltsame Quirks.

Last but not least: Persönlich nehme ich immer mehr Abstand von OSPF. Es ist irgendwie immer fummelig ans Laufen zu bekommen. Und es bleibt immer das schleichende Gefühl, dass man mal irgendwo vergisst etwas explizit als "passive" zu deklarieren und/oder per Firewall zu vernageln. Dadurch besteht immer die Angst, dass irgendwann mal jemand das Routing sehr einfach kaputt machen kann, egal ob als Angriff oder durch einen Flüchtigkeitsfehler.

Das müsste ich ausschließen können. Das Plugin legt automatisch die Firewall-Regeln an, da das im UI gar nicht möglich ist, derartige Regeln für Multicast vor der Bogon / RFC-1918 Blockliste anzulegen.

Interessant... Wann wurde das etwa eingebaut? Ich hab' hier gerade nur virtuelle Instanzen mit "echten" Interfaces als Verbindung untereinander. Da funktioniert es tatsächlich ohne explizite Regel.

Als ich vor ca. einem Jahr eine etwas größere OPNsense Migration gemacht habe, mussten wir die Regeln anlegen. Da waren OpenVPN und routed IPSec S2S Verbindungen zwischen OPNsense Clustern mit CARP im Spiel. Also möglicherweise mehrere Stellen, an denen es Bugs geben könnte. Aber wir mussten explizit die allow Regeln anlegen, sonst ging es nicht (block private/block bogon war aus).

Grobe Vermutung, es hängt mit routed IPSec zusammen. Da war es ja bisher immer so, dass man keine Regeln auf die Interfaces setzen konnte, sondern die immer auf enc0 mussten, vielleicht fehlt das im Plugin?
Geht das eigentlich mit FreeBSD 13? Wäre extrem angenehm. Mit >2 Tunneln hat man sonst nämlich schnell eine sehr große und unübersichtliche Tabelle auf dem "IPSec" Interface.

Die Probleme kenne ich. Ohne tief in der Materie zu sein vermute ich hier irgendwelche Quirks mit den OpenVPN Interfaces, die von FRR anscheinend anders behandelt werden. Könnte zusätzlich noch einen Unterschied geben zwischen Linux und Free-/HardenedBSD, das habe ich nicht überprüft.

Mein "Standard" Setup für OSPF, welches bisher bei OPNsense, EdgeRoutern und der anderen Sense immer funktioniert hat, ist folgendes:

• Im General Tab alle Interfaces, an denen kein benachbarter Router hängt, als Passive auswählen
• Route Redistribution Connected Routes aktivieren
• Unter Interfaces alle Interfaces, deren Netze verteilt werden sollen, eintragen und dort auch die Area setzen

Den Networks Tab lasse ich einfach leer.  Die Routen zu den OpenVPN Interfaces tauchen dann als external im OSPF auf. Zwar auch noch nicht ganz so geil, da die mMn nicht external sein sollten, aber das Routing klappt, das ist ja die Hauptsache.
Für das Problem mit den WAN Adressen baue ich immer eine Route Map als doppelten Boden, die nur lokale Adressen erlaubt und den Rest denied. Diese setze ich als Redistribution Map. Auf diese Art ist man auch gegen ein "Whoopsie" abgesichert.

Es scheint auch zu funktionieren, nur die Passive Interfaces auszuwählen, aber im Interfaces Tab nicht noch mal alles durchzuklicken (bis auf die OpenVPN Interfaces die müssen da glaube ich hin). Dann stehen allerdings alle Routen als "external" in der Tabelle. Das sieht für mich irgendwie immer unschön aus, deswegen klicke ich die noch mal zusätzlich in den Interfaces Tab. Aber ich hab' zu wenig Plan von OSPF und auch keine Lust mich mehr damit auseinanderzusetzen (s.u.). Praktische Auswirkungen sind wahrscheinlich eher gering.


Last but not least: Persönlich nehme ich immer mehr Abstand von OSPF. Es ist irgendwie immer fummelig ans Laufen zu bekommen. Und es bleibt immer das schleichende Gefühl, dass man mal irgendwo vergisst etwas explizit als "passive" zu deklarieren und/oder per Firewall zu vernageln. Dadurch besteht immer die Angst, dass irgendwann mal jemand das Routing sehr einfach kaputt machen kann, egal ob als Angriff oder durch einen Flüchtigkeitsfehler.

BGP ist was das angeht charmanter, und mittlerweile mein präferiertes Protokoll auch für internes Routing. Die Beziehung zwischen den Peers wird explizit hergestellt. Die Nutzung von TCP ist etwas firewallfreundlicher. Jede Site kriegt eine AS Nummer zwischen 64512 und 65535, Route redistribution an und los geht's. Das versehentliche einkippen von WAN Adressen ins interne Routing lässt sich hier ebenfalls über einfache Prefix Lists vermeiden. Sogar etwas besser, da man sowohl Inbound als auch Outbound filtern kann. D.h. auch wenn am anderen Ende mal jemand unqualifiziert an der Router Config friemelt, fällt nicht direkt das ganze Netzwerk um.

Die Standardtimer im BGP sind allerdings sehr träge. Mittlerweile kann man die pro Peer explizit setzen (das hat mimugmail eingebaut) oder einfach in den "General" Settings die Defaults auf "Datacenter" stellen. Das findest du unter Advanced Settings, habe ich vor einiger Zeit mal eingebaut. Klappt tadellos. Dazu noch die "Graceful Restart" Option nutzen. Sonst sorgt ein Daemon Restart dafür, dass Routen kurz verschwinden und dann wieder auftauchen - das kann je nach Anwendungsfall egal sein, aber du willst es in täglichen Operations eigentlich vermeiden, insbesondere wenn deine verteilte Anwendung es noch nicht so mit der Fehlertoleranz hat und ständig Fehler wirft, wenn mal ein paar TCP Verbindungen abreißen ;-)

what's the benefit of using a TCP stream via nginx as opposed to just NATing the port?

first that comes to mind: tls termination (can use strict tls setting on frontend and relaxed on backend), load balance, sni routing, logging, proxy protocol support

Isn't that all functionality you get when you actually proxy the application protocol though? I get the benefits of that, but my point is why would one want to forward raw TCP connections using nginx rather than NAT?

TLS termination and SNI routing are good points, although i'm personally a fan of keeping things simple - i'd just slap a valid TLS cert on the application server(s) - but yeah those i get. The other features all depend on the application protocol don't they?

So circling back to the use case in this thread - except for offloading TLS for performance reasons, there isn't much benefit compared to NATing, or am i missing something else? I realize this is the nginx sub and i don't want to argue about right or wrong. I'm just trying to figure out what possible benefits of using nginx to forward TCP connections i'm not yet fully understanding that might be beneficial for my own use cases. I currently never do it, nginx is my tool of choice for publishing web applications though.

Sorry for derailing the thread

You can build the docs on Linux, just as an FYI. Fair point though, a downloadable documentation would be pretty neat.

Unbound ist im Default ein Resolver, er wird also die im System eingetragenen oder per DHCP auf WAN gelernten DNS Server ignorieren, und stattdessen selbst im Internet auflösen.

Die Timeouts klingen nach einem Problem, entweder durch langsame/instabile Leitung oder vielleicht eine Dualstack Geschichte (IPv6 timed aus und dann kommt erst der Fallback auf v4)?

Alternativ kannst du auch mal versuchen, das Häkchen bei "DNS Query Forwarding" zu setzen - mit allen Implikationen die das hat. Du traust dann dem eingetragenen / gelernten Resolver.

what's the benefit of using a TCP stream via nginx as opposed to just NATing the port? i can't help but think it's just additional complexity to achieve the exact same outcome.