> David Gwynne I do not know sec. Wireguard is available as a package but I'am not sure it is included in the install image media. When I say I would prefer to stick to base tools, it is because the tools are well integrated together (config files, command line, etc.) and I found docs on Internet showing it should work in client/server mode. If it is still not working after exhausting all ideas, I will try with Wireguard...
> is ip forwarding enabled everywhere? Yes, forwarding IPv4 and IPv6 (even if I do not currently use IPv6 connections) is enable on gateway and VPN. Le dim. 16 nov. 2025 à 04:08, David Gwynne <[email protected]> a écrit : > On Sat, Nov 15, 2025 at 03:56:12PM +0100, Fran??ois RONVAUX wrote: > > 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. > > but sec and wg are part of the base system... > > > I do not understand why it work perfectly in virtual environment and not > > IRL. > > It is very frustrating ! > > is ip forwarding enabled everywhere? i dont understand how traffic would > be able to leave ipsec processing and go out to the internet from the > vpn vps, but ipsec is weird. > > > > > > > > > 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. > > > > > > > > > > >
