So, I tried to add a route to the client as mention above. It does not work : the reply from Internet is still not forwarded back to the client.
Le lun. 10 nov. 2025 à 22:53, François RONVAUX <[email protected]> a écrit : > > are you using sec(4) between the gateway and VPN server, or just normal > > IPsec security associations? > > mmm, I think I do not use sec. > Here is the iked.conf on the gateway : > > GAT="gateway.fqdn" > GAT_IP="gateway_public_ip_address" > > VPN="vpn.fqdn" > VPN_IP="vpn_public_ip_address" > > CLIENT="private_ip_address" > > ikev2 'vpn_client' active esp \ > proto tcp \ > from $CLIENT to any \ > local $GAT_IP peer $VPN_IP \ > srcid $GAT dstid $VPN > > > > > you can't see the reply packets if you tcpdump on enc(4)? > > Correct. > tcpdump on enc0 only shows the traffic from the client to Internet, not > the reply. > When running inside the VMs, the traffic in both ways is seen on enc0. > > > > do you have a route on the vpn server for the clients address? > > you can use `route get $clientaddr` or `netstat -nr` to see. > > The IP address of the client does not appear on `netstat -nr`. > > > > without sec(4), you'll need a route to the client on the VPN server > > pointing anywhere (even a blackhole route via lo0 is fine) so the > > outgoing packets can be intercepted by IPsec and then pushed to the > > gateway. > > I will try this on the VPN : > `route add -inet client_ip 127.0.0.1` > > > > Le lun. 10 nov. 2025 à 21:55, David Gwynne <[email protected]> a écrit : > >> On Mon, Nov 10, 2025 at 02:30:11PM +0100, Fran??ois RONVAUX wrote: >> > Hello, >> > >> > >> > I set up a VPN with client-server mode. >> > I used three virtual machines (client / gateway / VPN) on the same >> physical >> > host to design the config files pf.conf and iked.conf. >> > In the VMs, everything works as expected with this simple architecture : >> > >> > Client--(clear)--Gateway--(encrypted traffic)--VPN--(clear)--Internet >> > >> > But when I push the config files on the physical hosts gateway and VPN >> > (with just changing interface names, host FQDN and IP addresses) I get a >> > very strange behavior : the traffic is one way only ! >> > >> > After checking what happens (with tcpdump / pfctl and ipsecctl), this is >> > what I see : >> > - the tunnel is created by IKED between gateway and VPN, >> > - the traffic from client is encrypted by the the gateway and sent in >> the >> > tunnel, >> > - the traffic is received and decrypted by VPN, >> > - VPN send the traffic to Internet (with NAT), >> > - VPN receives the answer from Internet, >> > - the answer is not forwared back to client. >> > >> > Any clue on the source of this problem ? >> >> are you using sec(4) between the gateway and VPN server, or just normal >> IPsec security associations? >> >> my guess is the VPN server doesn't have a route to the client, but ipsec >> SAs complicate this. >> >> you can't see the reply packets if you tcpdump on enc(4)? do you have >> a route on the vpn server for the clients address? you can use `route >> get $clientaddr` or `netstat -nr` to see. >> >> without sec(4), you'll need a route to the client on the VPN server >> pointing anywhere (even a blackhole route via lo0 is fine) so the >> outgoing packets can be intercepted by IPsec and then pushed to the >> gateway. >> >> with sec(4), you'd just add a route to the client via the gateways IP >> inside the sec(4) interface. >> >
