IPsec packets not routing to tunnel in host to site configuration

[oaasvc]

Hi,

I have an issue with an IPsec tunnel in a host to network configuration (I don't control both ends). The network configuration is like so:

Code: [Select]

192.168.1.0/24--1.1.1.1[1.1.1.1]...2.2.2.2[2.2.2.2]--172.18.1.0/24
And the tunnel is:

Code: [Select]

1.1.1.1===172.18.1.0/24
OPNsense is on the 1.1.1.1 side, the other side is out of my hands. This worked just fine with previous Linux-based routers but OPNsense seems to be having some issues. As far as I can tell, it is unable to route packets back correctly when communications are intiated from the other side. i.e. If I contact a host 172.18.1.1, OPNsense nats the local address to the tunnel endpoint address (which is also the public address), recognises it is for the tunnel, routes it over the tunnel, 172.18.1.1 responds and all is fine.

However, if comms is initiated from the other end it does not work. I have a port forward set up on the IPSEC interface for port 80. 172.18.1.1 attempts to connect, the packet comes in on the tunnel, it is forwarded to the internal computer (192.168.1.1), the computer responds, OPNsense nats the local address back to the tunnel endpoint address, then, instead of routing over the tunnel it tries to send the packet over the public network. It appears as if it is ignoring the policy. I have replicated this between two OPNsense routers.

Can anyone suggest how I may be able to fix this? It seems like a similar issue to https://github.com/opnsense/core/issues/1773

Cheers,
Justin.

[oaasvc]

Some additional information which may be helpful.

The network:

Code: [Select]

  192.168.44.0/24 --- 1.1.1.1 ... 2.2.2.2 --- 192.168.200.0/24
The tunnel:

Code: [Select]

  172.18.5.1/32 === 192.168.200.0/24
The SPD:

Code: [Select]

  Source                Destination         Dir    Tunnel
      192.168.200.0/24      172.18.5.1          in     1.1.1.1 -> 2.2.2.2
      172.18.5.1            192.168.200.0/24    out    1.1.1.1 -> 2.2.2.2
What happens to a packet (roughly):

Code: [Select]

      Source                Destination         Interface   Next Hop         Note
      192.168.44.1          192.168.200.1       client      192.168.44.254   Packet leaves PC
      192.168.44.1          192.168.200.1       gw LAN      1.1.1.1          Packet hits OPNsense, doesn't match SPD, goes to default route
      1.1.1.1               192.168.200.1       gw WAN      the internet     Packet hits WAN interface, SNATs to public IP, goes out internet
What I would like to happen to a packet:

Code: [Select]

      Source                Destination         Interface   Next Hop         Note
      192.168.44.1          192.168.200.1       client      192.168.44.254   Packet leaves PC
      192.168.44.1          192.168.200.1       gw LAN      gw ipsec         Packet hits OPNsense, routed to tunnel based on destination
      172.18.5.1            192.168.200.1       gw ipsec    far tunnel       Packet SNATs to tunnel address, goes out tunnel
Forgive my lack of BSD knowledge in the above. I know routing is based on the SPD so the SNAT probably has to happen earlier. I have no idea how that happens though. I know under Linux the routing would happen based on the destination and the SNAT happens in the pre-route chain, but this doesn't seem to be BSD's way.

Any help would be greatly appreciated.