IPSEC VPN Traffic being allowed and blocked by the same rule

Started by densh, June 06, 2025, 03:16:10 PM

Previous topic - Next topic
Hello all,

I am very new using OPNsense, so please keep this in mind.

Currently I am facing an issue which is driving me mad.

Scenario:
- Route based (VTI) IPSEC tunnel
- LAN: 172.30.0.0/24
- Remote Nets which should be reached through the tunnel: 80.250.131.0/24 and 80.250.136.0/22

So far so good. I have set up the tunnel, which is working.
I have a Virtual Tunnel Interface like this:

Local address: 172.30.255.4 (OPNSense running on Azure, this is the Untrusted NIC with public IP)
Remote address: 1.2.3.4 (obfuscated)
Tunnel local address: 10.112.1.1
Tunnel remote address: 10.112.1.2

I have also setup routes accordingly.
So far all of this is working. Traffic is being sent through the tunnel.

Now for the catch:  Remote wants me to use SNAT, so my connections through the tunnel should originate from 172.19.221.0/24

To do this, I have set up One-to-One NAT like this:
- Interface: IPSEC10
- Type: BINAT
- External Network: 172.19.221.0/24
- Source: 172.30.0.0/24
- Destination: Remote Nets mentioned above

With this setup, I get super weird behaviour. The traffic gets blocked and allowed by the same firewall rule at the same time. I have attached screenshots.

Currently I have no clue what is going on and how to fix this, hopefully someone can help me. Like I mentioned, I am very new to OPNSense. I am happy to provide logs etc, but I may need some guidance on how or where exactly to export them if needed. :)

Same problem. No clue.

Without NAT the packet passes normally. With NAT the packet is blocked.

I wonder if what we are having trouble with is related. I used to use OpenVPN but lately with the changes and terrible docs, we gave up and went to IPSEC. Set it up fairly quickly and easily and poof it worked. Minutes later it stopped. NO changes were made. As best as I can tell it is an underlying OS issue. Permission to access the WAN port is getting denied, AFTER it was working. Sometimes a reboot of both FW's solves it but rarely. I think there is much more to this though. I just am not good enough to spend the time documenting all the things we are seeing.