Messages

Wie Lewald schon schreibt, einfach die dir zugewiesene öffentliche IPv4 Adresse vom Provider aufs WAN Interface legen und das Gateway anlegen. Für IPv6 analog. Wenn du in deinen LAN Netzen nun auch noch IPv6 nutzen willst, dann musst du dir wie erwähnt aus deiner Range die /64er Netze rausschneiden und auch statisch konfigurieren, dann sollte es bereits wuppen.

Vielleicht eine Idee als Workaround: Kannst du dir eine Banaction definieren, die die IP in eine Textdatei schreibt? Die könntest du in der GUI als Quelle für einen Alias konfigurieren, und diesen auf dem WAN Interface blocken. Bleibt zu erörtern, wie oft dieser Alias aktualisiert und angewendet wird :)

Kannst du dein bestehendes Setup mal kurz grafisch skizzieren? Wenn ich dich richtig verstehe, ist bisher deine Fritzbox in einer Broadcast Domain bzw. in einem Subnet mit dem LAN Interface deiner OPNsense?

Falls ja, brauchst du zukünftig ein neues Interface auf der OPNsense (das WAN interface halt). Dort konfigurierst du die Adressen wie von deinem Provider vergeben und legst die Gateways an. Für IPv6 an der Stelle die Adressen im Transfernetz nehmen. Aus deinem /56 Präfix schneidest du dir dann für deine internen Netze (Guest und LAN so wie ich es verstanden habe) einfach jeweils /64er Netze raus und hängst sie auf die Interfaces

Vielleicht kannst du auch mal ein paar Screenshots von der bisherigen Config einfach zeigen, und wie gesagt eine Skizze der Topologie würde helfen. Im Prinzip kannst du alles was lokale IP Adressen hat hier auch un"zensiert" posten - private Adressen interessieren eh keinen...

VTI is known to have MTU issues in FreeBSD, there is a bug somewhere around. I'd consider route based only if really necessary

could u elaborate or do u have any more details? i can't really confirm that statement. sure, one can't just slam it to 1500 and expect things to work without taking IPSec overhead into account. but other than that, i haven't had any issues so far given that MTUs are calculated correctly and confirmed to work. MSS can also become tricky with TLS or SSH because the set the DF bit in Layer3. But again, accounting for encapsulation and doing the math (or simply leaving sufficient headroom) usually does the trick.
i'd be very interested to read about potential bugs so i can avoid them before they bite me though

Now you are confusing me ..  :o
If I remember correctly, when you add a routed IPsec tunnel there should already be a gateway created for you?

i just double-checked this on two testing VMs. interfaces are automatically created and assigned, but gateways are not. can be created though. so looks like everything is fine, i just mixed up pfs and opns in my head...

another Q: do you have experience in messing with / optimizing MTU and MSS values on VTI interfaces? looks like it's at least possible to set and save them in the GUI. MTU seems to be applied correctly, not sure yet about MSS. would be glad to get some input

also i can now confirm that any VTI interface will lose its IP address when changing and applying config. have to restart the IPSec service to get the tunnel working again.

Du könntest ja einfach die MAC Adressen der Nachbarn auf deinem Switch whitelisten und den Rest blockieren. Damit erübrigt sich dann auch die Filterung nach einzelnen IP Adressen in IPv4, welche total einfach zu umgehen ist, wie hier ja bereits erörtert wurde.
Dann wäre auch IPv6 kein Problem :-)

Ähhh, also MAC-spoofing gibt es ja nun auch schon ein paar Tage, wo soll da der Vorteil sein?

Kein Nachteil ggü. dem Ansatz, es an den IP Adressen festzumachen. Nur dass man halt das Ziel "nur die Nachbarn niemand sonst" damit halbwegs umgesetzt bekommt. Wer schlau genug ist, die MAC Adresse zu spoofen, der würde auch seine IPv4 Adresse spoofen.
Vorteil: Funktioniert auch für IPv6 weil unabhängig von IP Adressen. Sicherheitslevel ist im Wesentlichen gleich: Reicht aus, um unerwünschten Usern eine Gewisse Hürde in den Weg zu legen, aber ist keine wirkliche "Sicherheit".

Klingt nach einem Problem, das ich auch hatte. Sind deine Firewallregeln serverseitig zufällig auf einem Assigned Interface, statt auf der OpenVPN Gruppe? Falls ja, probier' mal die automatisch generierten Gateways zu deaktivieren, siehe auch https://docs.opnsense.org/troubleshooting/openvpn.html

Interessanter Ansatz, aber leider in meinem Fall so nicht machbar. Dein Vorschlag setzt, so wie ich das sehe, an den entsprechenden Stellen auch VLAN-fähige Switche voraus. Die sind aber nur bei mir vorhanden. Alternative wäre evtl., soweit möglich die Software auf einigen Routern durch OpenWRT zu ersetzen. Letztendlich wird mir der Aufwand dafür dann allerdings zu hoch, nur um IPv6 nutzen zu können. Das einfachste wäre, die anschlossenen Nachbarn würden die WLAN-Kennwörter nicht rausrücken und die Leute einfach im Freifunk belassen. Also werde ich wohl vorerst IPv4-only bleiben, denn das ist bei meinem Setup ne einfache Lösung.

Verstehe ich dich richtig, dein Switch hat ein bisschen was in der Birne, und da hängen in einem separaten VLAN deine Nachbarn dran. Diese haben APs und eigenes WLAN, und zusätzlich Freifunk. Du willst, dass die Nachbarn gerne über deine Sense rausgehen können, alle anderen (Gäste der Nachbarn etc.) sollen aber bitte Freifunk nutzen?
Du könntest ja einfach die MAC Adressen der Nachbarn auf deinem Switch whitelisten und den Rest blockieren. Damit erübrigt sich dann auch die Filterung nach einzelnen IP Adressen in IPv4, welche total einfach zu umgehen ist, wie hier ja bereits erörtert wurde.
Dann wäre auch IPv6 kein Problem :-)

Deiner Lösung mit den Gruppen

ich glaube die gruppen waren hier nicht die lösung sondern das problem, wenn ich es richtig verstanden habe. beide WANs waren in einer gruppe, und dort die firewall regeln gesetzt. bei gruppen wird aber kein reply-to erzeugt, somit wurde die default route für antworttraffic auch bei paketen verwendet, die auf WAN2 rein kamen.

setzt man die regeln direkt auf die interfaces, wird das reply-to mit angehangen, und pf leitet den antworttraffic übers richtige interface wieder raus.

i would also greatly appreciate a bit of a dumbed-down version of how to develop core and plugins.  the docs mention cloning into /root and using "make mount", is that still a viable option?

i'm looking for a way to quickly create changes in a branch derived from master and test them in a VM. once everything is okay, i'd like to push the branch to my forked repo and open a PR. i've so far done the following:

cloned tools into /usr/tools
cd tools
make update

that seems to have pulled master for all repos. i'm assuming i can just change origin to my fork and create my branch there.
but then how do i quickly build and deploy my changes? do i "make upgrade" once and then just repeat that for every change? will the build system automatically just rebuild (and reinstall?) the changed parts or does it go through a full rebuild every time?
also sometimes i'll have to deploy the changes to more than one VM. is that where "make upload" comes into play? what's the easiest way to upload to a 2nd, identical test installation on the same subnet (aka: SSH would be available without much hassle)

/edit: pardon my ignorance, it seems i found my answer in parts already: https://forum.opnsense.org/index.php?topic=18879.0
how would i go about plugins though?

/edit2: for anybody stumbling across this: you can simply cd into the respective plugin dir (e.g. cd /usr/plugins/net/frr) and then "make upgrade"

hm i probably just confused pfsense and opnsense handling in my head. in the former, interfaces have to be assigned and enabled manually... thx for the clarification!

regarding gateways: it should be possible to manually create a gateway on a VTI interface though, right? if i want to route WAN traffic from a specific server on site B through the WAN of site A, i'm going to need a gateway to select in the firewall rule on site B for policy routing...

one thing i noticed today though is that somehow the IP(v4) address on one of my VTI interfaces disappeared. i'm currently not certain whether this happened out of nowhere, or after i messed with interface settings and assignments in the GUI. so take that information as a note-to-self for now, i'll see if it happens again on any of my lab boxes and report back.

started seeing this yesterday too, ran fine for weeks before that. is it worth testing this on stock FreeBSD/HBSD at this point, possibly on multiple versions?

upgraded my lab boxes to 20.7.5 a couple of days ago, now i noticed i can't change the settings on any of my VTI interface. i.e. i cannot add or delete a description, cannot change the enabled state. then i tried unassigning the interface but that doesn't work either. i also can't make any changes to related gateways that i had created.

while i don't recall testing this specifically, i do remember playing around with VTI interfaces quite a bit on 20.7.4 before and never ran into such an issue. does anybody else observe this behaviour? could it be caused by a failed migration? i currently don't have the time to create a clean test setup to check that