Show Posts
1
Virtual private networks / Unexpected Behavior with IPSec and PF's route-to
« on: September 16, 2022, 10:36:47 pm »
Given a typical (and established) IPSec-tunnel with
Phase 1: my-public-ip <-> remote-public-ip
Phase 2: my-internal-net <-> remote-internal-net
There are (simplified) these PF rules:
nat on my-puplic-interface from my-internal-net -> my-public-ip
pass in quick on my-internal-interface route-to (my-public-interface my-public-ip) from any to any
And of course there are two IPSec SPD-entries:
outgoing: my-internal-net > remote-interal-net ESP my-public-ip -> remote-public-ip
incoming: remote-internal-net > my-internal-net ESP remote-public-ip -> my-public-ip
What now happens, when I send a packet from my-internal-ip (which is an IP inside my-internal-net) to remote-internal-ip (an IP inside the remote-internal-net), is the remote side receives an ESP-packet which contains a packet from my-public-ip to remote-internal-ip.
That was a little bit unexpected to me, because there is no entry in the SP database which would match a packet from my-public-ip to remote-internal-ip.
So here's what I assume is happening:
When my packet enters the router it will somehow be tagged, that it has to enter the ESP-tunnel, because my packet matches the outgoing SPD-entry. Then PF goes into action, moves the packet to my-public-interface (because of route-to) and rewrites the source address, because of the nat rule. Then the packet is put into the ESP-tunnel, because it was tagged to enter ESP, and without checking the SPD again.
Is this the intended behavior? Or should the system check the packet against SPD again after rewriting?
Phase 1: my-public-ip <-> remote-public-ip
Phase 2: my-internal-net <-> remote-internal-net
There are (simplified) these PF rules:
nat on my-puplic-interface from my-internal-net -> my-public-ip
pass in quick on my-internal-interface route-to (my-public-interface my-public-ip) from any to any
And of course there are two IPSec SPD-entries:
outgoing: my-internal-net > remote-interal-net ESP my-public-ip -> remote-public-ip
incoming: remote-internal-net > my-internal-net ESP remote-public-ip -> my-public-ip
What now happens, when I send a packet from my-internal-ip (which is an IP inside my-internal-net) to remote-internal-ip (an IP inside the remote-internal-net), is the remote side receives an ESP-packet which contains a packet from my-public-ip to remote-internal-ip.
That was a little bit unexpected to me, because there is no entry in the SP database which would match a packet from my-public-ip to remote-internal-ip.
So here's what I assume is happening:
When my packet enters the router it will somehow be tagged, that it has to enter the ESP-tunnel, because my packet matches the outgoing SPD-entry. Then PF goes into action, moves the packet to my-public-interface (because of route-to) and rewrites the source address, because of the nat rule. Then the packet is put into the ESP-tunnel, because it was tagged to enter ESP, and without checking the SPD again.
Is this the intended behavior? Or should the system check the packet against SPD again after rewriting?