On Sun, Nov 16, 2025 at 10:50:48PM +0100, Fran??ois RONVAUX wrote: > > David Gwynne > > I do not know sec.
fair enough, it's relatively new. have a look at the sec man page and https://marc.info/?l=openbsd-tech&m=168844868110327&w=2. an ikev2 equivalent to the ipsec.conf in that last post is like this: h_self="130.102.96.46" h_s2s1="52.65.9.248" h_s2s1_key="one" h_s2s2="54.153.175.223" h_s2s2_key="two" ikev2 "s2s1" active \ from any to any \ local $h_self peer $h_s2s1 \ psk $h_s2s1_key \ iface sec0 ikev2 "s2s2" active \ from any to any \ local $h_self peer $h_s2s2 \ psk $h_s2s2_key \ iface sec1 > Wireguard is available as a package but I'am not sure it is included in the > install image media. yeah, you can use wg(4) in the base system without installing ports. i do this all over the place. and example hostname.wg0 i have in my own version of your vpn vps: wgkey random+key+made+with+openssl+rand+/base64+32 wgport 1111 inet 169.254.169.254 255.255.255.255 wgpeer public+key+from+ifconfig+wg+on+the+peer+++= \ wgpsk random+psk+made+with+openssl+rand+again++++= \ wgaip 0.0.0.0/0 \ wgpka 25 !route -qn add 192.168.0.0/24 169.254.169.254 > 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. yes, i understand. in my experience there's a lot of edge cases with a traditional ipsec setup, route based vpns have been a lot more robust and comprehensible. > 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. it is frustrating that we can't see what the problem with your current setup is. > > > 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. > > > > > > > > > > > > > > >
