Hello, > is pf dropping the packets? are you logging all blocks in pf so you can > see them in /var/log/pflog?
I added this line to catch every thing : block log all Nothing is blocked related to the VPN traffic I try to get working. I noticed in the iked.conf on the VPN that the IP address of the client was wrong. I fix it and now a route is added when the tunnel is created : Destination Gateway Iface client_IP VPN_gateway VPN_NIC But the reply packets are still ot forwarded back to the client. In the route, I tried to change the address VPN_gateway by 127.0.0.1 with the same result. > i would also try moving from vanilla ipsec to sec(4) (or wg(4)). i find > routing is a lot more understandable and observable than ipsec using the > SPD to steal packets. I would really prefer to stick to the default OpenBSD tools. I do not understand why it work perfectly in virtual environment and not IRL. It is very frustrating ! Le mer. 12 nov. 2025 à 00:39, David Gwynne <[email protected]> a écrit : > is pf dropping the packets? are you logging all blocks in pf so you can > see them in /var/log/pflog? > > i would also try moving from vanilla ipsec to sec(4) (or wg(4)). i find > routing is a lot more understandable and observable than ipsec using the > SPD to steal packets. > > dlg > > On 11/11/2025 21:00, François RONVAUX wrote: > > 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. > > > >
