"
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
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages1
#2
Virtual private networks / Re: VPN IPSec - strange routing problem
May 19, 2021, 02:17:17 PM
It's in production use, several other tunnels are here, reboot is not an option simple to try.
#3
Virtual private networks / Re: VPN IPSec - strange routing problem
May 19, 2021, 12:02:54 PM
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 :-\
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 :-\
#4
Virtual private networks / Re: VPN IPSec - strange routing problem
May 19, 2021, 11:44:33 AM
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.
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.
#5
Virtual private networks / VPN IPSec - strange routing problem
May 18, 2021, 06:34:49 PM
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
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
Pages1
