Full NAT and IPSec

[biricon]

Hello,

i test right now the following situation and dont find a solution on OpnSens:

Server 10.0.0.2 <--> [OPS_LAN 10.0.0.1] <---> [OS_VLAN_INTERFACE_Transfer_IP 10.1.1.1/32] <--> IPSEC <--> [192.0.0.1/24]

IPSec has the LANs 192.168.0.1 and 10.1.1.1/32

Now i like to make a port forwarding or 1:1 NAT for bring the Port 80 from Server 10.0.0.2 thru the Tunnel.

- IPSec works
- Routing and Ping to 10.1.1.1 works from 192.0.0.1

Traceroute from 10.0.0.2 will everytime go thru internet and not to the tunnel.
i test outbound NAT and Portforwarding
1:1 NAT

But no success.

Did anyone have a idea how i can do this?

[bimbar]

I think you need to add this in ipsec advanced settings -> manual spd entries .

[biricon]

you mean the passthrough networks?

but if i put in the internal 10.0.0.1/24 this does not make any diffrent. the traffic to the 192.0.0.1 will go out via normaly internet route and the masqurading does not work.

[biricon]

Now it works with the spd entry on the legacy IPsec and the new one.

But i have one strange problem. After the Tunnel starts it works - after 10-15min i can not reach from insert the other side of the tunnel. After a restart of the Tunnel from the other side, it works again for 10-15min.

On the other side i have Sophos SG/XGS, Edgerouter, Unifi Gateways and Fortinet. On every Tunnel its the same.

- But my transfer IP is pingable from the other Tunnel side
- From insert the LAN the traffic does not come to the tunnel - the traceroute ends on the opnsense.

On diffrent LANs from the same tunnel, the time is not the same, when this situation starts.

[shadesh]

First of all. 192.0.0.0/24 is not a RFC1918 (e.g. its a public ip range), so somewhere its "correct" routed to public internet. Before you can test the NAT you need to solve the routing issue. Is the Opnsense the only default gateway used on the 10.0.0.2 side? Do you see a routing table entry on the opnsense for both networks going into the tunnel? Are there two SA created for it under the ipsec section?

[biricon]

We find out, that the legacy and the new IPSec interface uses the same reqest IDs and so we have a conflict. In this case the request IDs will be falling out of the routing, if a secound tunnel come up with the same ID.