Messages

DROP would be better I think...

But NULL Route seems to be the new trend :
- https://forum.opnsense.org/index.php?topic=52244.msg269362#msg269362
- https://forum.opnsense.org/index.php?topic=50678.msg259031#msg259031

The problem with null routing is that it breaks policy based site-to-site VPNs, just tried it to see if anything had changed, but no.

Edit: it would also be nice to be able to use it in order to blackhole traffic to those VPNs when the tunnel is down.

Thanks for replying, indeed the management traffic from outside was matched on a interface group, I had missed that note.

I am experiencing some strange issues with management traffic (https and ssh) over a multi-WAN configuration: TCP SYN goes to one of the interfaces whose address I'm trying to connect to and return traffic exits from the other interface with higher gateway priority hence chosen as default, I thought that this wasn't supposed to happen with reply-to.

There aren't any PBRs or static routes that can influence this choice. I have another opnsense instance elsewhere configured almost identically that is not exhibiting this behaviour.

Any hints at where to look?

I lost a good few hours chasing a weird issue with CARP advertisement packets that weren't going to the peer from the interfaces they were supposed to go, all thanks to an overly broad PBR firewall rule towards one of the WAN gateways, so I'd say yes, you can PBR self traffic.

Disabled by default, with a scary note about storage consumption. Maybe with an option to keep the last n snapshots.

It would be useful the ability to trigger a snapshot creation upon launching the upgrade procedure.

I have to admit I'm not so diligent at remembering to do it every time, my fault, it always went well so far, but having an additional safety net would be beneficial.

Hey cknight725, thanks for the detailed guide.
The docs about VTI IPSEC mention to explicitly associate the reqid of the VTI to the Phase 2 children[1][2], is it necessary in your experience?

I'm getting the same error trying to renew the GUI self-signed cert.
The release notes for 26.7 mentioned the upgrade of openssl to 3.5 and possible issues, maybe related to this and the other thread about exporting OpenVPN profiles?

It's a vulnerability that defeats the purpose of a VPN.

Where you used that mtu value? I am capable to get also 180 Mbps, but I'd prefer to have a slower connection bit more stable.

I set the MTU on the WG clients, which in my case are all mobile, on OPNsense I left the default value.

I've not encountered any issues with general browsing, file transfers, SSH, Zoom/Meet/Teams calls.

Floating rules are processed before interface rules, it's expected behaviour: https://docs.opnsense.org/manual/firewall.html#processing-order

They didn't change with 26.7, but it's different between legacy and "new" rules.

I'm not an expert, but I've used 1380 for the past few years and I can easily fill my 4G connection bandwidth (100 Mbps).