IPSEC: one-way, packet enter tunnel but does not exit

Started by bazbaz, September 19, 2023, 11:55:46 AM

Previous topic - Next topic
Hi,
I have ans IPSEC tunnel from OpnSense to an other device (a Fortigate). The tunnel is:

- configured with the new "connections" tab
- IKE v2, tunnel mode
- site to site, using public IP addresses as endpoints, no NAT (but I've still forced NAT-T to test)
- VTI

As settings I defined:
- local authentication, as PSK using an Id defined in "pre-shared keys"
- remote authentication, as psk withoot any Id
- as child: 0.0.0.0/0 both local and remote, policies NOT flagged
- a virtual tunnel interface with 10.77.36.53 as local tunnel address, 10.77.36.54 as remote tunnel address
- policies on firewall to allow traffic (but this is not the problem)

Tunnel is up on both sides, both phase 1 and 2 it seems.

Now, if I send traffic from the FG to the OPN, packets arrive to OPN, replies are generated, they enter the tunnel but I cannot retrieve them on the FG side.

For example, if FG send a ping to 10.77.36.53, using packed capture on the OPN I can see ping request arriving, and ping reply entering the tunnel. On the FG side, using packet capture, I can see ping request entering the tunnel, and no response coming back.
Same, if I try from OPN to ping 10.77.36.54 I can see packet entering the tunnel interface, but nothing on the FG side.

VPN01F011
ipsec7 2023-09-19
11:51:11.754529 length 88: 10.77.36.53 > 10.77.36.54: ICMP echo reply, id 26368, seq 0, length 64
VPN01F011
ipsec7 2023-09-19
11:51:12.765165 length 88: 10.77.36.53 > 10.77.36.54: ICMP echo reply, id 26368, seq 1, length 64
VPN01F011
ipsec7 2023-09-19
11:51:13.775077 length 88: 10.77.36.53 > 10.77.36.54: ICMP echo reply, id 26368, seq 2, length 64
IPsec
enc0 2023-09-19
11:51:11.754453 confidential): SPI 0xc5ed95c3: 10.77.36.54 > 10.77.36.53: ICMP echo request, id 26368, seq 0, length 64
IPsec
enc0 2023-09-19
11:51:12.765129 confidential): SPI 0xc5ed95c3: 10.77.36.54 > 10.77.36.53: ICMP echo request, id 26368, seq 1, length 64
IPsec
enc0 2023-09-19
11:51:13.775038 confidential): SPI 0xc5ed95c3: 10.77.36.54 > 10.77.36.53: ICMP echo request, id 26368, seq 2, length 64




any idea?
thanks

so am I the only that cannot run a simple IPSEC using the new connections settings?
With old "tunnel settings legacy" all is ok.

I tried using a different remote endpoint but I've the same problem. So really I cannot understand how this new great connection settings work. I've read every doc available, and I've a lot of experience with IPSEC on other devices, but really this is an hell from where I cannot exit.

Someone can help me to setup this kind of tunnel?


no: full "real" IPv4 addresses directly binded to both IPSEC endpoints