Reaching an IKEv2 Client at Its Assigned Virtual IP

A gateway needs to start a connection to a laptop connected to it over IKEv2, using that client's assigned virtual address. The tunnel is up, the client reaches everything behind the gateway, and the reverse direction still fails. That asymmetry is normal: the negotiated policy describes which addresses may talk, not which side may initiate. Three things must line up before a gateway-originated request works.

The tunnel does not fix the source address

A CHILD SA covers a pair of traffic selectors, one per side, and permits traffic in both directions of that pair. It says nothing about which peer opened the IKE exchange first. A gateway that originally listened for the tunnel can still send the first application packet, provided the chosen source and destination fall inside the installed selectors. When the request leaves from the wrong interface, it simply is not eligible for the tunnel.

Routing toward the client is necessary and not sufficient. The policy has to admit the source you actually used.

Read the installed policy, not the config file

Start from the active association and its selectors, because dynamic assignment changes what is installed on the kernel.

ipsec statusall
ip xfrm policy

The status output names the connection, the assigned virtual address and the selectors currently in force for that peer. The policy dump shows the same selectors as kernel state, which is what packet selection actually consults. Compare the gateway-side selector against the source your application will use, since a mismatch explains the failure immediately. Read the client's current address rather than one from a previous session, because a reassigned VIP invalidates the old policy.

The client must listen where the packet arrives

Even a perfect policy reaches a closed port when the service binds only to loopback. The listener has to be on the assigned address or on a wildcard local address.

ss -ltnp 'sport = :9090'
iptables -S INPUT

The socket listing shows whether the port is bound to the virtual address, and the firewall rules show whether new connections are accepted from the protected source. A rule written for established connections does not admit a connection that the gateway initiates. Keep the service's own authentication, since arriving through the tunnel only establishes which network the packet came from. A client behind its own NAT still needs no inbound port forward, because these requests travel inside the existing tunnel.

Test the new direction on its own

A working client-to-server request never exercises this path. Generate the request from the gateway and observe both ends.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

The route lookup answers which source and interface the gateway would use, which is the value the policy must admit. The capture should show the request leaving inside ESP rather than as plain TCP on the public interface. On the client, capture the decrypted traffic to confirm arrival and whether the service answered. If the request disappears with no ESP on the wire, suspect the source address before the client's firewall.

Repeat the test after a rekey or a reconnect, because the VIP can change. A path that works only until the next session is not a working path.