VPN IPSec - strange routing problem

[PeterTk]

Hello,

I'm trying to establish a VPN IPSec tunnel between OPNsense firewall (version 21.1) and FreeBSD 13.0 server (acting as a router) with strongSwan daemon installed and configured.
I created a simple configuration with PSK authentication, but two VPN peers don't communicate correctly on IKE phase 1.

Sniffing the traffic, I can clearly see the reason of the failure. Being in the same private network (172.17.14.0/24), the peers should communicate directly. FreeBSD server sends IKE traffic directly to the OPNsense firewall (and this traffic is received by the IKE daemon of OPNsense). But the answers, sent by the firewall, are not sent directly to the server, but they are sent to the default gateway who drops them. All another traffic between the two hosts is passing correctly, without using of the default gateway. But the IKE traffic is forced somewhere to go to the default gateway, and not directly to the server. The routing table is correct on the firewall, the ARP resolution works fine.

So, it seems that the IKE daemon of OPNsense ignores the system's routing table and always sends the IKE traffic to the default gateway, ignoring the fact that it must communicate locally. Could someone explain me the reason of such strange behavior, and help me to establish the tunnel, please?

Peter

[wurmloch]

Maybe if you check the box „disable reply-to“ under advanced option of each single firewall roule would correct this wrong behaviour.

I think this option is only useful in multi-wan setups. Give it a try.
Regards

[PeterTk]

Thanks a lot, wurmloch!
Checking 'disable reply-to' in 'Advanced option' of 'Rules' AND changing WAN interface default router to 'auto' solved my problem.

BTW, this is REALLY confusing!!
I saw the forum thread https://forum.opnsense.org/index.php?topic=15900.0 and I'm agree - this behavior is definitely NOT RFC compliant. And the bug https://github.com/opnsense/core/issues/3952 was closed.

I don't understand why OPNsense developers are so closed face of this situation.

[PeterTk]

Hrr... Non...
The problem is back, after some minutes of correct traffic the OPNsense is sending the IKE/NAT-T traffic again to the router.
Playing with rules does not change anything.
So, the tunnel is broken again 

[wurmloch]

Did you try a reboot? Sometimes this helped while playing with IPsec.

[PeterTk]

It's in production use, several other tunnels are here, reboot is not an option simple to try.

[PeterTk]

I could get up the tunnel, creating manual rules for IKE and NAT-T traffic on WLAN interface, with 'disable reply-to' option checked https://github.com/opnsense/core/issues/3952#issuecomment-844156624

[wurmloch]

FYI: I try to use of routed VPN wherever possible:
https://forum.opnsense.org/index.php?topic=22217.msg105700#msg105700