(double) NAT and IPSec Tunnel [SOLVED]

[bamypamy]

Hey, I have a problem with an IPSec Tunnel and (double) NAT.

I have a Server on the Internet 1.1.1.1 that I want to reach from a Server connected to our FW via an IPSec Tunnel.

IPSec Tunnel:
Local Network/IP: 192.168.20.1/32
Remote Network: 10.201.0.0/16

Public IP on my FW on WAN Interface: 2.2.2.2
Server IP on the Internet: 1.1.1.1

The Tunnel is up and running.
Clients from the remote Network 10.201.0.0/16 always only connect to 192.168.20.1.
So when they want to access 1.1.1.1:80 they connect to 192.168.20.1:8080

I have a port forwarding rule setup on the ipsec interface saying.
Interface: IPSec
Source IP: 10.201.0.0/16
Src Port: any
Dest IP: 192.168.20.1
Dest Port: 8080
NAT IP: 1.1.1.1
NAT Port: 80

This forwards all traffic going from 10.201.0.0/16 to 192.168.20.1:8080 to 1.1.1.1:80.
I can see in the logs that this rule is working.

I then have an Outbound NAT rule on the WAN interface
Interface: WAN
Src IP: 10.201.0.0/16
Src port: any
Dest IP: 1.1.1.1
Dest Port: 80
Nat address: 2.2.2.2

I can also see in the logs that this rule is working.
Firewall rules are also in place and are working. I do not see any blocks and when I set the connected rules to log I can see that in the logs.

I also see traffic arriving at 1.1.1.1 with the correct source 2.2.2.2.
I can also see traffic coming back from 1.1.1.1:80 to 2.2.2.2 on the WAN Interface.

That is where it stops. The traffic is not sent back into the IPSec tunnel.
As said I do not see any firewall blockings.

It seems like the NAT is not working in the backward direction.
Do I need more NAT rules or should this work due to stateful NAT?

[viragomann]

Never did something like that, to be honest, but I can imagine, the IPSec doesn't pass packets with 1.1.1.1 as source IP into the tunnel.

However, OPNsense provides a setting, which may help here.
In the phase there is a "Manual SPD entries" option. You can try to enter the remote servers IP (1.1.1.1) there.

[bamypamy]

Thanks for your answer.
I wouldn't do it like this either but that's a longer story.

I have already tried what you suggest. I added 1.1.1.1 as a Manual SPD entry but that did not help and actually this is not what should be send into the tunnel.
It should be natted back to 192.168.20.1 before it is sent into the tunnel, otherwise, the server that had sent the initial request would drop the packets since it initially requested 192.168.20.1 and not 1.1.1.1.

[bamypamy]

Ok, I don't know why but because you mentioned it I tried it again and added 1.1.1.1 as a Manual SPD entry and it seems to work now.
I need to double check because I don't have access to the other side but I did see return traffic in the tunnel.

I don't know why it did not work before but well I did so many changes it might be that I had changed something else as well after removing the SPD entry.

Thanks for the help. I will check with the customer again tomorrow and let you know.

[viragomann]

I assume, that manual SPD expects a network address. So you have to state the IP in CIDR notation (1.1.1.1/32).

[bamypamy]

I talked to the customer and it works now. Thanks a lot for the hint.

The Solution was to add the server's public ip (1.1.1.1) as a manual SPD entry on the Tunnel in CIDR notation 1.1.1.1/32.

The NAT rules are correct, as I posted them above.