Messages

Sounds like A-Symmetric Routing issues and the "Default DENY / State violation Rule" is always right in my experience :)

Hi nero355. As the proxmox I'm talking about has 2 interfaces, it could be possible that packets returns from a different interface than the one packets arrived, so it could be possible that it's a case of asymmetric routing.

Thank you for pointing this out.

EDIT:
I've found this, based on nero355s statement: https://forum.proxmox.com/threads/tcp-streams-drop-between-proxmox-vlans-routed-via-virtual-pfsense.134496

Hi FlyveHest, which service is the one needing sloppy states?

I had the same problem using spice proxy from Proxmox.

If I connect to a VM console from a different VLAN through the router, the connection drops after some seconds. The problem is solved using sloppy states, but only for the intended spice proxy port. I made a rule to pass traffic for that port using sloppy states and another to pass the rest of the traffic as normal.

The security check is frightening !!! it's better not to ask for it

Hi, the use case you are needing is called "Road Warrior". Check the official docs first: https://docs.opnsense.org/manual/how-tos/wireguard-client.html#wireguard-road-warrior-setup

If you have already configured a working tunnel the step required to route all traffic through this is setting the AllowedIPs=0.0.0.0/0 at the client configuration. This way, the client will use the tunnel as the default route for all traffic.

The firewall rule you need to pass the hole traffic, LAN and WAN, is the simplest one because you want to allow traffic to "any" destination. With this one rule you can accomplish that:

Interface: [your wireguard interface]
Action: pass
Direction: in
Protocol: any
Version: IPv4
Source: [the wireguard network]
Source port: any
Destination: any
Destination port: any

The client configuration should look like this:

[Interface]
PrivateKey = [your client private key]
Address = [your peer IP address]/32
DNS = [you may use your server tunnel address here and Unbound will resolve addresses]
MTU = 1420

[Peer]
PublicKey = [your VPN server public key]
Endpoint = [your VPN server public IP o URL]:51820
AllowedIPs = 0.0.0.0/0,::/0   <---note that you can redirect IPv4 and IPv6 traffic

@Xaver, if you are using an updated OPNSense version, you can migrate Outbound NAT to Source NAT. Once migrated there is a new option in the Source NAT rule called "endpoint independent". You can try enabling that. Is the "full cone nat"

It seems to me that this option is not present in the old Outbound NAT rule menu but if it is, you don't need to migrate to the new system.

2) The guy has spent the last 15 years as a generic IT guy in marketing organizations.

This is the key: "Marketing"

May be related to Monit package update to 6.0.0... https://mmonit.com/monit/changes/

Unbelievable... doesn't make any sense.

Coincidentally this video was published today https://youtu.be/a3RI4DjFBzw

Awesome. It can't be better... wow!!

We all know how much time it takes for a project like this to get mature... if it started recently and suddenly it has all the features, I would say that it is likely completely AI coded.
Having said that, I also think that AI in good and responsible hands is "the tool" for coding but it will take time for this FW to reach a mature state as OPNSense has reached already.

Hi MiRei, the two patches that solves the Security Headers modal dialog are:

opnsense-patch -c plugins 1726d9e
opnsense-patch -c plugins 9ee2cd4

The patch that you applied is the one that solved the first problem found on Nginx plugin in version 26.7.0 that crashed when you accessed to the configuration menu.
If you applied opnsense-patch 14710e7 after updating to 26.7.1_1 then you broke Nginx again because that patch was already applied in 26.7.1_1 version.
Because of the way patches work, they are disabled if applied a second time, so applying 14710e7 over 26.7.1_1 is a regression.

Now, to recover your system to 26.7.1_1 version, you have to apply opnsense-patch 14710e7 again. An then, if you want to test the upcoming Security Header UI patch you can apply the other two patches I mentioned above, 1726d9e and 9ee2cd4.

I don't think that this is a specific problem to .lan domain. Don't rename it.
Just uncheck the option "Harden Below NXDOMAIN" and test it for some time to see if it works as you need.

It's in Services: Unbound DNS: Advanced. The fifth option.

Hi Timeraider, I've reported this issue on github https://github.com/opnsense/core/issues/10546.
Another issue reported earlier that can be related is https://github.com/opnsense/core/issues/10535. This has been already addressed but Franco reopened it because there is a chance that it is also related to this problem.