Home / server / Questions / 635012
Accepted
dorian
Asked: 2014-10-11 01:45:36 +0800 CST

Why are only 3 ip xfrm policies needed for a IPsec tunnel?

  • 772

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!

ip

3 Answers

  1. Best Answer

    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.

    • 9

  2. 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.

    • 3

  3. 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 .

    • 1