13

I have a site-to-site IPsec tunnel up and running between a strongswan (v5.2.0) instance (site A) and a RouterOS router (site B). Everything works fine, the hosts in the two private subnets setup for site A (10.10.0.0/16) and B (10.50.0.0/16) can communicate with each other just fine.

What I don't understand though is the following output of ip xfrm policy on site A's router (public IPs obfuscated). Theses policies were created by strongswan, I did not manually install or modfify them:

ip xfrm policy 
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir fwd priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir in priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.10.0.0/16 dst 10.50.0.0/16 
    dir out priority 2947 ptype main 
    tmpl src <PUBLIC_IP_A> dst <PUBLIC_IP_B>
        proto esp reqid 1 mode tunnel

There's a policy each for input and output, but only one for forwarding (from site B to site A). But I can still successfully ping, for instance, 10.50.4.11 from 10.10.0.89:

ping -R 10.50.4.11
PING 10.50.4.11 (10.50.4.11): 56 data bytes
64 bytes from 10.50.4.11: icmp_seq=0 ttl=62 time=10.872 ms
RR:     10.10.0.89
    10.50.0.1
    10.50.4.11
    10.50.4.11
    10.50.4.11
    10.10.0.2
    10.10.0.89

The interesting part about this route trace is that site A's router (10.10.0.2) only shows up on the route back from the ping target, while site B's router (10.50.0.1) is only listed for the outgoing route.

This seems to confirm that there is actually no forward policy needed on site A's router to forward 10.10.0.0/16 to 10.50.0.0/16 over the IPsec tunnel, but I do not understand why.

Thanks for any explanations!

3 Answers 3

11

The fwd policies are not automatically generated by the kernel but instead get installed by the keying daemon (strongSwan in this case).

They are required to allow traffic to get forwarded to and from hosts behind the VPN gateway in tunnel mode.

For an inbound packet that is addresses to an IP that's not installed on the gateway itself a fwd policy is searched after decryption. For local traffic a matching in policy is looked up. If none is found the packet is dropped.

For outbound traffic that was not generated on the VPN gateway itself a fwd policy is searched. If the packet was not encrypted it is no failure if no matching fwd policy is found. And if traffic is forwarded between two tunnels the inbound fwd policy installed with one will act as outbound fwd policy for the other and vice-versa. Afterwards, an out policy is looked up to decide whether to tunnel the packet. That's why a fwd policy in the outbound direction is often not required.

However, if there is e.g. a drop/block fwd policy with low priority that matches everything (e.g. to avoid cleartext traffic from passing the gateway if there are no tunnels established) a fwd policy in the outbound direction is explicitly required as the block policy will otherwise drop all unencrypted traffic. That's why strongSwan started installing fwd policies in both directions with 5.5.0.


A previous version of this answer stated that the single (inbound) fwd policy is symmetrical (i.e. that src and dst work in either direction). That's not true, but as explained above in many situations this doesn't matter.

4
  • I see, very interesting. However why are packets routed through the fwd policy when src and dest addresses do not match? In the example above, the outgoing packet from my ping has source 10.10.0.89, yet it is being processed by the fwd policy having 10.50.0.0/16 as src selector... [e]: You actually answered that by saying src and dst work in both ways. But then I think it's not completely analogous to how the FORWARD chain works in iptables.
    – dorian
    Oct 10, 2014 at 12:48
  • No not in regards to this particular detail. I tried to clarify that sentence.
    – ecdsa
    Oct 10, 2014 at 13:16
  • Thank you, I think I understand now. Do you know of any reference where such details of the Linux IPsec implementation are specified?
    – dorian
    Oct 10, 2014 at 13:51
  • 1
    @dorian: Sadly, the only reference on Linux IPsec is the kernel's source. May 29, 2017 at 12:11
5

From this article by Andrej Stender:

security policy syntax meaning
“output policy” dir out SP works as a selector on outgoing packets to select which are to be encrypted+encapsulated and which not
“input policy” dir in SP works as a selector on incoming packets which already have been decrypted+decapsulated and have a destination IP local on the system
“forward policy” dir fwd SP works as a selector on incoming packets which already have been decrypted+decapsulated and have a destination IP which is not local, thereby packets which are to be forwarded (routed)

So:

  • out is used on outgoing traffic (both local and forwarded) that we want to encrypt+encapsulate with IPsec.
  • in and fwd are used on incoming IPsec traffic and are applied to packets encapsulated within IPsec:
    • in is applied to inner packets whose destination IP is this computer
    • fwd is applied to inner packets which should be forwarded further

EDIT: I conducted my own local experiments with ip xfrm on Linux 5.9.1 and results matched Andrej's table.

1

This seems to confirm that there is actually no forward policy needed on site A's router to forward 10.10.0.0/16 to 10.50.0.0/16 over the IPsec tunnel, but I do not understand why.

That is because A wants to receive from B only IPsec traffic.

IPsec traffic from A to B has A's IP address as a destination IP address - so it is handled by dir in policy on A.
After encapsulated IP packets are extracted from IPsec, they are handed over to kernel to get standard linux processing of an incoming IP packet - no xfrm policy dir fwd is required here.

Policy src 10.10.0.0/16 dst 10.50.0.0/16 dir fwd ... on A could be added if you need to also receive non-IPsec traffic from B .

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .