Messages

I use huge, high-DPI monitor. OPNsense's defaults of only showing 7 or so entries per page in various places don't work for me. I habitually change these to 20 pretty much every time I click on anything. Is there any way to alter these defaults?

Hi Zbig!
Hi myself!

Got it working finally by adding a static route to ::/1 through my WireGuard interface on OPNsense. Turns out policy-based routing ("reply-to" option) doesn't really work well for IPv6, either by design or due to a bug. Might also be that I hit some corner case by not having any IPv6 addresses assigned to any on the interfaces on my OPNsense instance other than on the WG tunnel.

Oh well, at least I was forced to learn some IPv6 networking basics and ended up with a /56 routed range for fun and profit.

BTW, did I mention I also had to add another iptables rule to the v4 portion of my tunnelling solution to  perform MSS clamping so it doesn't try to shove 1480 byte-sized packets into a WireGuard tunnel with its MTU set to 1420? I sure did, I sure did...

Update:
Got rid of the dodgy IPv6 NATting on the gateway server. Ordered an IPv6 /56 range from its provider instead, subnetted and routed it to my OPNsense in what I now hope to be a proper IPv6-native way. So now my OPNsense WireGuard peer has its own IPv6 GUA, no more funny packet forwarding rules.

Despite all that, in a cruel lack of plot twist, nothing has ultimately changed: the service that listens on OPNsense's WG port only accepts incoming connections that originate from within its own subnet. I can see my firewall allow rule getting triggered in both cases but the incoming connections still only get SYNACK'd if they come from the same network WG peer is. What gives?

[OPNsense box]

Hello, I'll try to sum up what I'm trying to achieve:

OPNsense box

• A service running there needs to receive (and respond to) incoming connections arriving via a WireGuard tunnel. Original source (public) addresses of the connecting clients need to be preserved.
• WireGuard instance (configured using the official plugin) connects to the "gateway server" (see below).
• Gateway configured in OPNsense and pointing at "gateway server's" WireGuard peer address
• Floating firewall rule bound to the WG interface applying policy-based routing by means of having its "reply-to" option set to aforementioned WG gateway

Gateway server

• An iptables/nftables rule that forwards incoming connections arriving at its public address to OPNsense WireGuard peer address.
  For IPv4: iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.11.0.2

Clients on the internet
Hitting up gateway server's public IP address and get served the OPNsense hosted content

It all works great for IPv4: clients are connecting, the service running on OPNsense is seeing connecting clients' original IP addresses despite the connections getting tunnelled over WG. Happy times.

Not much luck with replicating the same functionality over IPv6, though. I basically tried to replicate everything I've done in parallel but using IPv6, just sharing WireGuard instances with IPv4.

What is working:

• IPv6 pings between OPNsense box's and the gateway server's WG addresses
• Server process binding on IPv6 socket, properly responding when being hit from the gateway using OPNsense's WG v6 peer address
• Client's SYN packets arriving at OPNsense's IPv6 WG peer address when they try to connect to gateway's server's public IPv6 address

Where it fails:
Although the clients' tunnelled incoming connection requests seem to arrive at OPNsense:

Code Select Expand

12:43:02.036721 IP6 2600:reda::cted:xxxx:xxxx:4c94.35388 > fd16:eb69:819d::2.8080: Flags [S], seq 2816276090, win 64800, options [mss 1440,sackOK,TS val 4265021634 ecr 0,nop,wscale 7], length 0
0x0000:  6001 241e 0028 0633 2600 3c17 0000 0000  `.$..(.3&.<.....
0x0010:  f03c 95ff feeb 4c94 fd16 eb69 819d 0000  .<....L....i....
0x0020:  0000 0000 0000 0002 8a3c 1f90 a7dc f67a  .........<.....z
0x0030:  0000 0000 a002 fd20 55e1 0000 0204 05a0  ........U.......
0x0040:  0402 080a fe37 10c2 0000 0000 0103 0307  .....7..........

they never get SYN ACK'ed on any of OPNsense interfaces, seemingly. As if it wouldn't know what to do with them.

Both WireGuard peers have their AllowedIPs set to 0.0.0.0/0, ::/0. Like I said, I tried to replicate my working IPv4 setup as closely as possible with differences only where needed. As the iptables build I have on the gateway server doesn't seem to support IPv6 DNAT, I used the following nft rule to try to achieve DNAT66 functionality:

Code Select Expand

table ip6 nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
ip6 daddr 2a01:reda::cted:xxxx:xxxx:e72c tcp dport 443 dnat to fd16:eb69:819d::2
}
}
Any help greatly appreciated.
Cheers

Passive-aggressive much? I already said that I've tried to search for it and failed. Apparently you're better at it but there's no reason to be an asshole about it. Anyway, thanks... I guess...?

Hello everyone

I know for a fact that this very topic was being discussed in the past but, for the life of me, I wasn't able to find it again.

So, I'm using OPNsense under hypervisor (moving from vSphere to Proxmox right now) and the quirk that gives me headaches is the fact that when I add or remove virtual network interface(s) on hypervisor level, FreeBSD (and thus OPNsense's) IF names (like opt<number>) get reassigned and the whole configuration basically gets FUBAR'd until sorted out manually, while the GF screams "What's happened to the Internet?" from another room while doing so.

I seem to recall there was some optional tool that allowed one to bind IF name to its MAC address, solving this mess once and for all. Could anyone point me to this, pretty please?

Regards,
Zbig

Hello

I have a case where a couple of clients from my network have to get assigned some non-default DNS servers but I don't want to setup a separate (V)LAN for them. Figured that would be a perfect use case for DHCP server's "Additional Pools" given how it allows me to carve out a separate pool from the network and configure pretty much everything the "main" pool allows. As there doesn't seem to be a separate "DHCP Static Mappings" section for additional pools, I reckoned I'll just make a regular ("top-level") DHCP mapping, assign an IP from my additional pool there, leave the "DNS servers" fields empty and this way it would fetch proper DNS IP's from the additional pool's configuration. This turned out not to be the case: the clients in question got assigned the default, system-wide DNS address.

Am I doing something wrong here? If the "main/additional" DHCP pool configurations are not being resolved hierarchically the way I was expecting them to and the additional pools don't offer their own DHCP reservation UI, what is the practical use case for having them in the first place?

Cheers,
Zbig

Also (or alternatively), leave the Interfaces / [if_name] / MAC address fields empty in OPNsense and use the vSphere's features to bind static MACs to IFs if needed. If you use both, the two of them clash when FreeBSD decides to shuffle IF names around.

Seems to be browser related. More discussion at https://www.reddit.com/r/opnsense/comments/umhx04/opnsense_2217_released/

The update seems to have gone through just fine when initiated from CLI.

It was the same for me, only instead of rebooting immediately, I've navigated away from the stuck update log to find an error report waiting to be sent to developers. There was some error message regarding Phalcon mentioned. I have sent the report and restored my VM from the snapshot. Now when I want to retry the update, it fails to fetch it - it seems they have temporarily shut down the update servers or something. Sorry to say, but I'm not sure you have ended up with properly updated instance, after all...

I use a dual-WAN setup where I have a main cable broadband interface that's backed up by a failover mobile broadband interface and I use default gateway switching for the failover/switch-back. I use several port forward and firewall rules for incoming traffic that are currently assigned to the main WAN interface only. Is there any elegant way of making them apply to both primary and the secondary WAN that is short of manually duplicating them? Would the use of floating firewall rules and assigning port forwards to both WAN networks do the trick?

Yeah, it is kind of an issue. My instance runs on VMware and it took me some time to realize what was going on that the mere act of adding a new network interface to the VM was shuffling all my interface assignments around. The fact that I had (needlessly) assigned a spoofed MAC on one of the interfaces at OPNsense level and after the mixup the OS was suddenly trying to configure the same MAC on two different IFs, just added to the confusion.

Got this sorted out by adding screen.font=10x18 to my tunables. For the list of available font sizes: ls /boot/fonts

Used information from https://forums.freebsd.org/threads/changing-tty-resolution.79529/

@karlson2k: there's some other good info there, like efi_max_resolution that might work in your case.

I have done it using aliases. Defined an alias of type "MAC Address" under "Firewall / Aliases" and referred to it in my firewall rule as a source. Not sure how it works exactly under the hood. I believe it just resolves the MAC to IP when the time to reload aliases comes and uses that IP in the packet filter from now on so it might not be accurate/secure enough in some cases?