Topics

Hi,

tested the new Netbird integration and tried my test setup key but the service won't start at all:

[cf80a216-e515-45cc-acc1-a3cf1899ed2c] Script action failed with Command '/usr/local/bin/netbird up -m 'https://api.netbird.io:443' -k '22BCF562-xxxx-xxxx-xxxx-1CA4723CC26B'' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 78, in execute subprocess.run(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.11/subprocess.py", line 571, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '/usr/local/bin/netbird up -m 'https://api.netbird.io:443' -k '22BCF562-xxxx-xxxx-xxxx-1CA4723CC26B'' returned non-zero exit status 1.

Also the plugin doesn't log its own errors in its tab (most likely because the messages were thrown from controld and not netbird itself).

Cheers,
\jens

Moin,

da wir in der letzten Usergroup festgestellt hatten, dass es nicht jedem geläufig ist, hier nochmal als kurze Info:

https://pcengines.ch/eol.htm
Die komplette Serie an APUs ist offiziell End of Life und wird nicht mehr weiter aufgelegt. Ein letzter Rest an Chips ist noch eingekauft worden, man rechnet mit den letzten Geräten Richtung Ende des Jahres. Bis nächstes Jahr wird es also maximal noch Restposten, Rückläufer und gebrauchte Geräte geben. Die Begründung sei mal dahingestellt, aber da häufig bei kleineren Setups immer gleich mit APUs geworben wird, wollten wir das hier nochmals etwas bekannter machen, damit diejenigen die sich ggf. nach einem neuen Setup umsehen nicht in "tote Hardware" investieren und sich hinterher ärgern.

Cheers
\jens

[nie ausgeführt]

Hi,

da das Thema in den letzten Wochen gefühlt häufiger bei uns aufgeschlagen ist, wollte ich nicht bis zur nächsten Usergroup warten und das hier reinpacken, damit es ggf. auch in der Suche aufschlägt.

Es ging länger auch an mir vorbei, dass bereits Ende 2018 das Format der exportierten pf.conf geändert wurde und sich dabei das Verhalten der integrierten Interface Addresse Aliasen (bspw. WAN address) geändert hat:

https://github.com/opnsense/core/issues/2457

Warum es den Change von "wir schreiben IP in pf.conf" zu (Interface) gab, ist mir nicht geläufig, aber der Fix für das Verhalten hatte dann wohl andere Probleme. Da man es dann aber nicht wieder zurück auf IP gebaut hat, sondern auf Interface belassen, verhalten sich nun alle Platzhalter der Interface Addressen (WAN address, LAN address, etc.) so, dass damit ALLE IPs auf diesem Interface enthalten sind.

Hat man also via IP Alias und Co mehrere IPs auf einem Interface ist "XY Address" nicht mehr eindeutig! Gerade in größeren Szenarien, in denen man bspw. mehrere IPs auf einem WAN Interface hat (/29 öffentliches Netz) und man diese IPs nicht auf sein WAN geroutet bekommt, sondern selbst auf dem WAN als Aliase konfigurieren muss, kann das fatal sein. Warum? Weil der Name des Platzhalters impliziert, dass es sich um eine Adresse - die Haupt IP, die ich beim Interface konfiguriere, handelt. Und man sehr häufig diese (einzelne) IP dann mit Regeln ausstaffiert. Nutzt man dazu aber bspw. "WAN Address" als Alias und legt später zusätzliche IPs auf, werden diese automatisch! auch freigegeben.

Noch schlechter ist das Verhalten dann bei Port Forwards: definiert man hier einen internen Host als Ziel für Destination "WAN Address" und leitet auf bspw. Webserver 1 weiter und legt danach ein zweites Forwarding für eine WAN Alias IP an, die im Dropdown ja als Auswahl auftauchen, dann wird dieser Forward nie ausgeführt weil der "WAN Address" Forward auch die zusätzlichen IPs "wegfrisst".

Somit sollte man die "XY Address" Aliase nach Möglichkeit vermeiden, um Lücken im Regelset zu entgehen. Wir hatten das gerade erst sehen können, dass bspw. ein Forward von SSH auf einen internen Server via "WAN Address" dazu führte, dass plötzlich auf allen Alias IPs dieser Forward aktiv war - auch auf IPs, die explizit eigentlich nur für Mail oder VPN Nutzung gedacht waren. Man muss die Interface IP nochmals manuell extra als Alias anlegen. Sehr unschön bei Setups, bei denen die Zuweisung dann aber dynamisch passiert bspw. per PPPoE oder DHCP. Da man hier die WAN IP nicht kennt und beeinflussen kann, kann man nur hoffen, dass es ggf. eine statische IP ist, die man dann wieder in ein Alias packen kann. Ansonsten ist man bei dynamischen IPs darauf angewiesen genau nachzusehen was man tut und was damit freigegeben ist um falsche oder unnötige Freigaben zu vermeiden.

Gerade in größeren Umgebungen mit größerem öffentlichem IP Adressraum sollte man daher nur noch mit genau spezifizierten IPs oder eigenen Aliasen arbeiten. Eine Änderung auf das eigentliche/alte Verhalten scheint bislang eher nicht angestrebt zu werden. Aber da ich alleine in den letzten Monaten hier einige Fragen gelesen hatte, warum ggf. weitere 1:1/BiNAT Sachen oder Port Forwardings oder auch Regeln nicht so funktioniert hatten wie gedacht wenn mehrere IPs im Spiel sind, wollte ich das auch für die bessere Sichtbarkeit mal hier lassen. :)

Cheers
\jens

Just a quick question about the predefined aliases one can use in NAT or filter rules that are automatically populated based on the configured interface. So "WAN address", "WAN network", etc. etc.

When did the logic change to write out pf.conf rules with {(IF)} instead of the actual primary configured IP address of said interface? After a quick search in my lab VMs I found that in 21.1 and 21.7 series. But I could swear that this behavior isn't that old.

Follow up question: Is it intended, that this makes "IF address" alias automagically include all Virtual IPs (Alias IPs) configured on an Interface? I found that hard to believe but after debugging a customer installation which he updated recently from an old version, that problem popped up instantly. As he has multiple WAN IPs from a public subnet configured, "WAN address" in Port Forwards or Rules suddenly included all IPs on that interface instead of only the one configured as the main IF IP. So his rules didn't work anymore as every port forward on the "wan address" catched the traffic for the alias IPs that were configured later in the ruleset and redirected e.g. all web traffic on all ips to a single webserver instead of different backends.

So I'm curious: when did that happen and is "XY address" using all VIPs intentional? Can't seem to grasp which use case that should cover as with "XY address" (singular) you wouldn't think that it's meant for multiple IPs?

Thanks in advance,
\jens

Hi,

I checked with 21.1 as well as 21.7 but a v6 only RAS server (tunnel v6, LAN v6, bound to WAN interface with v6) seems to generate an invalid configuration. I tested that in relation to a bug report from this topic

https://forum.opnsense.org/index.php?topic=24094.msg115153#new

and fould it reporting:

Code Select Expand

2021-07-28T15:01:07 openvpn[98366] Use --help for more information.
2021-07-28T15:01:07 openvpn[98366] Options error: --client-disconnect requires --mode server
2021-07-28T15:01:07 openvpn[98366] Cipher negotiation is disabled since neither P2MP client nor server mode is enabled

up until I configured an additional dummy ipv4 tunnel network. Then the server could be configured and came up.

Also the generation routine in use for creating shared keys throws a warning and (incorrectly) writes that to the TLS auth field before the # comments of the static key.

Code Select Expand

2021-07-28 15:10:54 WARNING: Using --genkey --secret filename is DEPRECATED.  Use --genkey secret filename instead.
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
...


That also happened in 21.1-latest and 21.7.

Last thing I'm perhaps missing: as we now have access to OVPN 2.5 and cipher negotiation should be default (as far as OVPN is concerned) I can't seem to find support for more then one data-cipher on the UI or am I mistaken? As there now is chacha20 support especially for mobile devices without AES-NI support, it would be nice to configure it to use GCM/Chacha20 and let the client select one.

Cheers

https://twitter.com/troyhunt/status/1366160363062878213?s=19
bzw.
https://twitter.com/haveibeenpwned/status/1366158939604144130?s=19

TL;DR
VPN Dienste hatten einen Data Breach, 20Mio Datensätze entwendet in denen nicht nur Mails enthalten waren, sondern auch

* Login History
* Login-Land
* Geräte Art
* IMSI und Geräte Seriennummer

Genau mein Humor ;)

Aloha,

nach einem Gespräch mit meinem Studenten, der sich eine kleine Cloud zu Hause bauen möchte kam die Frage/Idee nach einer günstigen Möglichkeit, einen Server (bspw. Nextcloud) selbst zu hosten, aber ne echte Firewall vornedran zu haben. Daher hier kurz - für den Fall dass es jemand interessiert und vielleicht von Nutzen ist - ein Ideenanstoß, wie man das günstig haben kann:

Worum gehts?
-> Webserver in der Hetzner Cloud (KVM Container zu günstigem Preis #noad) mit vorgeschalteter "echter" Firewall

Warum?
-> Normalerweise bekommt man (in günstig) keine echte managebare Firewall vor seinen Webserver und muss so die potentielle Angriffsfläche auf der VM direkt versuchen zu mitigieren. Da sich einige nicht ganz so doll mit Linux, Kernel, IPtables/NFtables und Co auskennen (plus Fail2Ban und Co) ist bei "nur VPS mit Webserver" natürlich die Angriffsfläche größer. SSH muss da sein, Webserver auch, etc. etc. IPtables für Firewall, ggf. noch nen Frontend dafür (UFW, Shorewall, whatever) und dann noch fail2ban, damit man SSH ordentlich absichert. Und so weiter, und so weiter.
Wäre mit Firewall davor und ordentlichem VPN alles viel einfacher? Jau.

Wie konnte man das bisher hinbekommen?
-> Konnte man bislang natürlich alles auch schon machen, Stichwort eigener Server mieten. Dann mietet man eben die Hardware und kann darauf virtualisieren. Dann gehts aber schon in Runde 2: Virtualisierung aufbauen, KnowHow benötigt, dann ordentlich Netzwerken in der Virt Umgebung, Firewall VM vorschalten, und wieder - usw. usw. usw.
Zusätzlich ist man oft für Backup selbst verantwortlich, kann den Server nicht mal eben wechseln und ein eigener Server schlägt dann schonmal mit 20-30€ im Monat zu Buche (wenn man drauf virtualisieren können soll, also bezüglich IPs, Netzwerkkarten, etc.). Die kleinsten VPS Instanzen kosten aber gerade mal ~3 plus Backup (ein paar Cent).


Wie bekommt mans (bei Hetzner) einfacher hin?
-> Man braucht mind. 2 (ZWEI) kleine Hetzner Cloud Instanzen. Witzigerweise müssen sie durch das (etwas gewöhnungsbedürftige) Netzwerksetup von Hetzner nicht im gleichen RZ Standort sein (Nürnberg, Falkenstein oder Helsinki sind alle möglich).

• VM(1) Eine davon wird mit einem Random OS gebucht
  
• VM(2) Die andere installiert ihr mit dem System und Kram den ihr schützen wollt. Linux + Nextcloud bspw.
  
• Via Cloud Dashboard erstellt ihr ein zusätzliches Netzwerk. Beispielhaft "xconnect" mit IP Range 172.16.16.0/24 (wird bei 2 Instanzen dann auf /29 runtergerechnet, einfach ignorieren :))
  
• In diesem Netz was erscheint, könnt ihr den beiden Instanzen jetzt jeweils eine IP zuweisen (.2 und .3). Somit haben die VMs jetzt ein Interface mit ihrer Public IP4/IP6 und ein "internes". Das Interne (xconnect) muss am Einfachsten via DHCP bezogen werden, ihr bekommt dann aber definitiv die IP die ihr im Dashboard eingestellt habt. Wichtig ist DHCP deshalb, weil eure Instanzen eine /32 IP und P2P konfiguriert werden, damit jeder Traffic über die .1 des angelegten Netzes geht (Hetzner interner VirtRouter). Das ist notwendig, damit die den Traffic auch mit den anderen Instanzstandorten vernetzen können. Darum nicht wundern über das etwas "schräge" Setup :)
  
• (1) Die erste VM wird ausgeschaltet und über das Dashboard konfiguriert. Bei Networking kann man nochmal checken, ob die private IP auch drauf gemappt ist (xconnect mit der .2 sollte hier auftauchen). Dann unter ISO-Images einfach das OPNsense Image auswählen und einhängen. Danach die VM starten.
  
• (1) Nach Start von VM1 jetzt die HTML Konsole (Symbol rechts oben) aktivieren und die OPNsense via eingehängtem ISO einfach installieren. Sollte nicht schwer sein :) Nach Installation und DHCP auf WAN sowie DHCP auf LAN, solltet ihr die im Dashboard angezeigte IP4 auf dem WAN anliegen haben. Dann könnt ihr auf der HTML Konsole nach fertiger Installation und Boot euch auf die Konsole der Sense einloggen und einmal kurz "pfctl -d" abfeuern. Das sollte man natürlich nur kurzfristig machen und sich dann flotti galoppi einloggen, admin User ändern und den Zugriff auf WAN auf seine IP freischalten (via DynDNS Alias oder statischer IP). Seit 20.7 müsste das auch mit CLI dann irgendwie möglich sein, eine Regel schnell zu erstellen, so gings für mich zum Testen aber schneller :)
  
• (1) Hat man die Sense soweit im Griff dass man nur noch selbst via GUI/SSH auf die Kiste kommt (und dann den HTTPS und SSH Port noch umverlagert auf Alternativen wie 4422 und 4443 bspw.) und zudem noch SSH nur via Key erlaubt (oder key+pw), sollte man erstmal annehmbar safe sein und kann in Ruhe die Sense durchkonfigurieren.
  
• (1) Hier kann man sich jetzt wie mans kennt austoben. VPN Einrichten, Zugriff einrichten, Advanced Setup etc. für AES-NI usw.
  
• (1) HAProxy Addon installieren (und ggf. schon einrichten)
  
• (2) Auf der zweiten Kiste kann man jetzt bspw. sein Lieblings-Linux installieren und setzt sich seine Umgebung auf. Webserver, PHP, Python, etc.
  
• (2) Natürlich sollte man das angelegte interne Interface (xconnect) nicht vergessen noch einzurichten, wenn nicht schon erledigt. Das sollte als zweites Netzwerk auftauchen und die beiden VMs sollten sich da schon gegenseitig pingen können (bzw. die OPNsense nach Freigabe der Regeln)
  
• (2) ist das soweit fertig und man käme jetzt über die andere Public IP des Webservers auf den Server drauf und bekommt seinen Webserver, klemmt man die externe IP bzw. das Interface vom Hetzner-WAN ab :) (HTML Konsole via Dashboard dafür nutzen)
  
• (2) Die zweite Kiste ist jetzt nicht mehr erreichbar von außen weil ihr WAN down ist. Oh my... ;)
  
• (1/2) Mittels HAproxy auf der ersten VM (1) legen wir jetzt einfach die (2) als Backend für den HAproxy an und erstellen ein passendes Frontend. Da wir 80/443 auf der Sense freigemacht haben von der UI (und den Redirect bzw das Binding auf WAN abgeschaltet haben!) kann jetzt auch dort unser Webserver antworten, der dann einfach intern über das xconnect Netz mit (2) verbunden ist und so antworten kann.
  

Das ist jetzt natürlich nur in gröberen Zügen beschrieben, aber "you get the drift", ihr versteht wo es hingeht. Im Notfall, sollte die 2. VM down gehen, kann man mit etwas Vorbereitung und Absicherung die 2. VM auch wieder direkt ans Netz hängen, muss dann natürlich aber die DNS Einträge anpassen. Oder man nutzt gleich noch zusätzlich das Feature der Floating IP (für 1,19€ im Monat) und bucht sich eine IP die man flexibel von A nach B switchen kann im Dashboard dazu. Dann kann man sogar drangehen und sich eine zweite Firewall als Redundanz bspw. in anderer Location beschaffen wenn man Ausfallsicherheit will ;)

Natürlich kann man statt HAproxy auch einfach NATten (Port Forward) aber das kann ggf. etwas holpriger sein und braucht ggf. auf Seite (2) noch ein paar Zusatztweaks. Zudem läuft HAproxy besser und man kann noch weitere Funktionen implementieren :) Wenn es aber um exotischere Apps oder Protokolle geht, würde auch port forwarden gehen.

Alternativ kann man statt zweiter Kiste auch einen VPN Tunnel zur Sense aufbauen und dort damit dann quasi sein "LAN" bauen und routen. Auch das geht via OpenVPN und ordentliches Routing recht flexibel. Port Forwards ins LAN via VPN sind kein Problem und von den /64 an public IP6 die man bekommt, kann man sich via NPt bequem ein paar (Dutzend) ins LAN schicken, wenn man dort via fdXY:: Adressen auf OVPN Tunnel und internen Geräten die entsprechenden Kisten ansprechbar macht. Damit bekommt man dann auch recht einfach ein "deutsches/EU" IPv6 Netz über welches man interne Kisten erreichbar machen kann. Mit einem HE.net IP6 Tunnel gibt es ja manchmal leider wegen stumpf-dummer Geoblocks (und weil das übergeordnete Prefix eben he.net bzw. USA zugeordnet ist) manches Mal Probleme (bspw. Netflix via IP6 HE-net Tunnel).

Was ich leider noch nicht getestet habe: zusätzliche IPs (könnte man ggf. via Floating IPs realisieren) bzw. IP6 Prefix (leider nicht so einfach buchbar, muss ich mal nachfragen). Wenn sie bspw. ein Prefix routbar auf den VPS hauen würden, könnte man das dann auch nachgelagert ins Heimnetz routen und dort dann auf fdxy:: komplett verzichten und direkt public IP6 Space auflegen :)

Cheers
\jens

[Aktueller Link für die Meetings:]

Aktueller Link für die Meetings:
🔗 ▶▶ Link zur UserGroup (dem Pub) & Terminen -> nsfw.pub

🔗 ▶▶ Aktuelle Infos zur Änderungen der UserGroup ◀◀


Als Name bitte einfach den Forennamen nehmen, dann wirds einfacher für alle ;)

---

Grüße zusammen,

Der @micneu hatte das ja bereits einmal versucht anzukurbeln und der Grundgedanke eine UserGroup aufzustellen/zu eröffnen, bei der man sich sowohl privat als auch vllt. als einsetzende Firma einfach mal unter Gleichgesinnten austauschen, umhören und ggf. auch den ein oder anderen Tipp abbekommen kann trotzdem ein Guter und Wichtiger. Nun ist das damals hauptsächlich am Punkt "Treffen" und "Treffpunkt" gescheitert, weil man einfach zu weit verstreut in DE, CH oder AT verteilt sitzt, aber das ändert ja im Prinzip erstmal nichts daran, dass es schön wäre - außer einem Forum - sowas wie eine UserGroup aufzustellen oder überhaupt mal anzufangen.

Nachdem das die letzte Woche mehr durch Zufall in Gesprächen mit einigen Kunden von mir auch schon aufgetaucht war, habe ich mich mit meinen Chefs hingesetzt und das mal angesprochen, dass ich das gerne - aber wie auch hier im Forum hauptsächlich als Privatperson - anschieben würde und ob da nicht was zu machen wäre. Gab dann auch sofort Zustimmung, dass das ne feine Idee wäre und nachdem in Corona Zeiten ja eh immer mehr der Weg zu virtuellen und Online-Treffen/-Konferenzen hinging, kam eben der Gedanke: "Ja warum denn nicht als virtueller TechTalk/BarCamp/Meeting abhalten!" Natürlich, offensichtlich, denn dann ist Entfernung und Uhrzeit kein großer ausschlaggebender Faktor mehr. Und da wir in unserem anderen Geschäftsbereich als Hosting und Service Anbieter auch seit längerem nun eine größere Jitsi-Meet-Instanz für Kunden und Projekte hosten, ist das ganze auch ohne proprietäre Firmen/Clients/Datenkraken möglich. Unsere Jitsi Instanz ist entsprechend DSGVO abgenommen, Serverstandort ist DE/KA wen's interessiert und gespeichert und geloggt wird minimal (kurzzeitige access logs, damit man Problemen bei der Verbindung nachgehen kann - sonst wirds natürlich schwer)

LT;DR: Der langen Rede kurzer Sinn: Ich würde gerne wenn sich genug Interesse für solch eine UserGroup finden, ein erstes virtuelles Treffen ansetzen, "quasi gesponsert" (scherzhaft gemeint! :) ) auf unserem gehosteten Jitsi Cluster meines Brötchengebers. Das kann man dann gern alle 1-2 Monate zyklisch wiederholen und ggf. auch ähnlich einem BarCamp/TechTalk mit Themen/Themenvorschlägen vorab über die man klönen kann, ansonsten kann das aber auch einfach erstmal zum Kennenlernen und einfach zum Austausch und für Interessensfragen genutzt werden. Ich hätte nun fast vorschlagen, dass WebCam auch tatsächlich verpflichtend ist, aber würde das jetzt zum Start erstmal optional machen. Es hat sich aber zumindest bei uns im Einsatz gezeigt, dass es einfacher ist um zu sehen wer redet oder um den anderen besser ausreden zu lassen :) Zudem ist es einfacher für jemanden zu Gesichtern statt zu X schwarzen Kästen zu sprechen und das Sprechen und ausreden lassen klappt einfach besser ;)

Eine Option für die (spätere) Zukunft wäre möglicherweise, dass man das Ganze auch aufzeichnen könnte (so alle Teilnehmenden einverstanden wären) und (ggf. in gesichertem Bereich) zum Download danach bereitgestellt. Gerade wenn man ggf. doch mal ein oder zwei Themen behandeln mag die interessant wären aber jemand keine Zeit hatte, wäre es vllt. dann recht praktisch sowas zu haben - ist aber alles noch eine rohe Idee!
Zusätzlich wurde ich schon angesprochen, ob/dass man - nur für die Usergroup - bspw. ein Tool wie Discord (ist jetzt eher aus der Gaming Szene bekannt) o.ä. nutzen könnte, da man hier zusätzlich zu Ton/Videocalls auch Textkanäle hätte um bspw. Dinge wie das Video nur einer begrenzten/angemeldeten Gruppe verfügbar zu machen. Auch das - erstmal nur eine rohe Idee hier für später. Generell ist da nix in Stein gemeißelt  ;)

Die Optionen und was man sonst noch schönes in den Meets machen kann, wären auch sicher ein schöner Diskussionspart für das erste Treffen ;) Aber wichtiger wäre mir da eher Mal jetzt konkret zu fragen, wer/wieviele denn überhaupt Interesse an der Art Austausch hätten und ob das ganze "Hirngespinst" überhaupt mal vom Boden abhebt oder ein Rohrkrepierer bleibt :D

Also gerne euer Feedback dazu, ich kann das Thema dann auch später in noch anpinnen, aber zum Start wollte ich hier erstmal so viele wie möglich abholen!

Grüße
\jens

Vielleicht eher @franco ;) aber auch interessehalber ob es noch jemand so geht: Ich habe seit ein zwei Tagen das Problem dass ich alle paar Postings plötzlich abgemeldet bin im Forum, als würde ständig mein Cookie gelöscht oder verloren gehen. Da ich hier nix geblockt habe :) frage ich mich warum - oder ob hier mein Browser anfängt zu streiken ^^

Würde mich nur interessieren ob es noch jemand so geht, dass er ständig mal ausgeloggt ist. Auf Dauer nervt das etwas :D

Hi all,

I'm trying to setup our lab environment and for testing the various setup conditions we've also routed some public IP and IP6 prefixes to the Lab VMs.

While having multiple parallel running VMs in the Lab (various OPNsense and pfSense VMs on a separate ESXi), we have set up one OPN and one PF instance very simple:

- WAN: private IP range (10.y.y.131 pf / .141 opn), Gateway .1
- LAN: another private range (172.x.x.131 pf / .141 opn)

as of that - no problems. Our normal firewall is also involved in those subnets (10.y.y.254 and 172.x.x.254) so we can reach either the WAN or LAN site as needed.

Problems first came up with IPv6. Although all IPs (4/6) are assigned static, the PF VM is running as expected.
IP6 was configured accordingly as above and shown in this little ASCII Diagramm (hope that makes it clearer ;))


                                 WAN Uplink                               
                                10.0.250.254                             
                           2001:DB8:210f:f1cf::2/64                       
                                                                         
                                +-----------+                             
           +-----------------+--- Upstream  ---------------------+       
           |                 |  +-----------+  |                 |       
           |                 |                 |                 |       
           |                 |                 |                 |       
           | CARP: .1 & ::1  |                 |                 |       
           |                 |                 |                 |       
     ::1001| .11       ::1002| .12        ::141| .141       ::131| .131   
     +-----|-----+     +-----|-----+     +-----|-----+     +-----|-----+ 
     |Office HW 1|     |Office HW 2|     |OPNsense VM|     |pfSense VM | 
     +--|-----|--+     +--|-----|--+     +--------|--+     +--------|--+ 
  .251  |     |           |     | .252            | .141            | .131
::1001 |     |           |     |::1002           |::141            |::131
        |     |           |     |                 |                 |     
        |     |-----------|-----|-----------------|-----------------|     
        |       CARP: .254|                                               
        |             ::1 |           2001:DB8:146:222::/64               
        |                 |              172.22.222.0/24                 
        |                 |                  LAB-NET                     
        |                 |                                               
        +-----------------+                                               
                 |                                                       
                 |                                                       
       other internal VLANs                                               


So as one can see, simple and straightforward, same IP4/IP6 endings vor v4/v6 and all configured static. Clean, simple dual-stack. (the DB8 prefixes are for simplification, the networks on all ends are real public routable IP6)

BUT: With the OPNsense VM I had the first problems and trouble after adding IP6 static config and couldn't reach the upstream WAN IP - no ping6 no outgoing connection. Only after rebooting it showed up with ping OK and reachable, DNS and MTR via v6 working. OK perhaps a glitch. But the second problem still not working: We try to reach the :222::141/131 side (LAB-NET) of those VMs via another v6 only network that is homed behind our office cluster (see other internal VLANs). So to correctly do the routing we added the :146:222::1 from the office cluster as an additional gateway, configured a route for the other prefix and set it up to use the new gateway on the LAB side.

Result:
pf VM -> :146:222::1 GW is green, ping6 working, test prefix can be reached via LAN(LAB) interface.
OPN VM -> :146:222::1 GW is red, no ping working, test prefix can not be reached.

Testing further revealed quite a strange behaviour: ::1001 and ::1002 of the cluster can be reached, but the CARP VIP6 ::1 is "dead" according to the gateway check and can't be ping6'ed even via SSH. Checking the same thing on the WAN side revealed the same, but as the GW on WAN isn't a CARP IP but the upstream switch (::2) that never came up. So it seems the IP6 side of the OPNsense VM somehow has a problem in communicating with CARP VIPs on the same local network segment (no, there are no other clusters or devices speaking CARP, HSRP or VRRP there, so no conflict).

Is that a possibility and is there anything to check it with? Neither pf VMs with 2.4.3 (FreeBSD 11.1) nor 2.4.4 (11.2) show that behavior and as long as this isn't fixed the whole testing lab for v6 cases is dead.

Happily supplying additional info to debug that :)

Greets
Jens

Hi,

few quick questions as we saw that at a customer installation: Is it possible with FRR package and BGP setup to

1) Set/Override the default gateway
2) "inject" additional static routes in addition to the ones learned from the BGP peer

as I was shown, the default route seems to be added to the system but even if nowhere else a default route is configured (neither on WAN nor anywhere else, the only GW entry is on LAN and set to be non-default), there's still a default kernel route from "anywhere" inserted in the routing table that stops the learned route from working.

Also it seems there's no place to add static routes in addition to the ones learned via BGP. One can with vytsh on console but that isn't saved and gone after a reboot.

Thanks!

[Diese Diagramme einfach kopieren und in einen "code" Block in euren Beitrag einfügen und anpassen]

Aus der Kategorie: Hätte ich mal den Mund gehalten... :D

Nachdem ich jetzt auch hier ein wenig euren Aufenthalt im Forum moderieren und hoffentlich angenehm(er) gestalten darf, wollte ich gleich mal eines der Postings von meinem anderen Mod-Alter-Ego hier mit reinwerfen:

Da vieles einfacher erklärt werden kann wenn man es aufzeichnet, habe ich hier mal ein paar häufige Einsatzszenarien von OPNsense in ASCII Diagrammen nachgezeichnet, damit man diese bei Bedarf kopieren und anpassen kann. Damit wird es vielen einfacher gemacht zu verstehen, was ihr ausdrücken wollt und wo sich welche Probleme auftun.

Diese Diagramme einfach kopieren und in einen "code" Block in euren Beitrag einfügen und anpassen

Code Select Expand


      WAN / Internet
            :
            : DialUp-/PPPoE-/Cable-/whatever-Provider
            :
      .-----+-----.
      |  Gateway  |  (or Router, CableModem, whatever)
      '-----+-----'
            |
        WAN | IP or Protocol
            |
      .-----+------.   private DMZ   .------------.
      |  OPNsense  +-----------------+ DMZ-Server |
      '-----+------'   172.16.16.1   '------------'
            |
        LAN | 10.0.0.1/24
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------... (Clients/Servers)


Ein einfaches "Dreibein" - Firewall mit 3 Interfaces für WAN, DMZ und LAN. Kann leicht in 2 Interfaces geändert werden.

Code Select Expand


      WAN / Internet
            :
            : DialUp-/PPPoE-/Cable-/whatever-Provider
            :
      .-----+-----.
      |  Gateway  |  (or Router, CableModem, whatever)
      '-----+-----'
            | 10.0.0.1/24
        WAN |
            |
      .-----:-------.
      |  OPN:sense  +-------.
      |  (Br:dge)  |       |
      '-----:-------'       |
            |              | 10.0.0.253/24
        LAN |         MGMT | management interface
            |              |
      .-----+------.       |
      | LAN-Switch +-------'
      '-----+------'
            |
    ...-----+------... (Clients/Servers)

Die Variante "Filtering-Bridge". pfSense im Bridge Modus (LAN/WAN) mit einem dritten Interface, welches (in diesem Fall als inbound) Management Interface genutzt wird. Kann leicht auch für Outofbound Management oder nur 2 Interfaces angepasst werden.

Code Select Expand


                WAN                      WAN
                 :                        :
                 : CableProvider          : DSL-Provider
                 :                        :
             .---+---.                 .--+--.
         WAN | Cable |     Modems      | DSL | WAN2
             '---+---'                 '--+--'
                 |                        |
        Ethernet |                        | PPPoE
                 |                        |
            .----+----.              .----+----.
            | Router1 |    Router    | Router2 |
            '----+----'              '----+----'
192.168.101.1/24 |                        | 192.168.102.1/24
                 |      .----------.      |
                 +------| OPNsense |------+
     192.168.101.254/24 '----+-----' 192.168.102.254/24
                             |
                         LAN | 10.0.0.1/24
                             |
                       .-----+------.
                       | LAN-Switch |
                       '-----+------'
                             |
                     ...-----+-----...
                     (Clients/Servers)

Oft angefragt: MultiWAN. Hier mit 2 WANs und exemplarisch einem DSL- und einem Kabel-Anschluß. Kann beliebig angepasst werden.

Code Select Expand


                WAN                      WAN2
                 :                        :
                 : redundant WAN connect  :
                 :                        :
             .---+---.      VRRP      .---+---.
         WAN | Cisco +----------------+ Cisco | WAN2
             '---+---'   1.2.3.4/29   '---+---'
     1.2.3.5/29  |                        |  1.2.3.6/29
                 |                        |
     1.2.3.2/29  |     VIP: 1.2.3.1/29    |  1.2.3.3/29
            .----+-----.             .----+-----.
            | OPNsense +-------------+ OPNsense |
            '----+-----'     CARP    '----+-----'
                 |                        |
  10.0.0.251/24  |      10.0.0.1/24       |  10.0.0.252/24
                 |      .---------.       |
                 +------| Switch  |-------+
                        '---------'
                             |
                     ...-----+-----...
                     (Clients/Servers)


Eine etwas versiertere Einsatzmöglichkeit: Typische Anbindung in Rechenzentren mit mehreren redundanten WAN Zuleitungen. Exemplarisch setzt der Provider hier Ciscos VRRP ein, pfSense nutzt CARP fürs Sync und Failover. Alle IPs der Redundanzanbindung inkl. CARP-VirtualIPs eingezeichnet.

Einfach den kompletten Text in "code" oder "tt" (TeleType) Blöcke einfügen, dann sieht es auch optisch richtig aus (dank der anderen Schrift).

Ich hoffe das macht manchem Post das Leben etwas leichter :)

Grüße
Jens

Hi there,

as a new devel series is starting I just wanted to ask about ways to make OPNsense less dependent on the UI part. Don't take me wrong, I like the *senses for their UI, but for doing tasks over and over again multiple time, clicking simply sucks ;)
A CLI part would make the whole thing less UI dependent for quick things like adding a route, adding a VIP/IP or VLAN in a way that is saved in the configuration (and visible in the audit log). An API would mean less implementation overhead for either GUI or CLI (or even remote controls, deployment systems etc.) to reimplement and perhaps to loose the heavy-UI part completely (PHP and you custom scripts! I'm pointing at you! ;))

So I thought I'd throw it in here to ask if there's something on the horizon or planned or even thought about as that is one feature I usually get asked quite often when it comes to *sense support/tech and as we manage quite a bigger installation ourselves, it would mean big improvements in workflow :)

Greets