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.
