AnswerBun.com

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

Server Fault Asked by dorian on October 28, 2020

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!

2 Answers

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.

Correct answer by ecdsa on October 28, 2020

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 .

Answered by Shfer on October 28, 2020

Add your own answers!

Related Questions

How to choose best EC2 instance for the system

3  Asked on January 1, 2021 by user14108508

   

Equivalent of Firebase with PostGreSQL?

0  Asked on December 31, 2020 by dimitri-l

   

Sticky TCP sessions with IOT sensors

0  Asked on December 31, 2020 by quade

   

Failed to using powershell to get cookies

1  Asked on December 30, 2020 by pansal

     

Heroku.yml is not getting bash script

0  Asked on December 29, 2020 by shahrear-bin-amin

   

D-Link DGS-1210-28 factory reset

0  Asked on December 27, 2020 by andrey-salnikov

       

Ask a Question

Get help from others!

© 2022 AnswerBun.com. All rights reserved. Sites we Love: PCI Database, MenuIva, UKBizDB, Menu Kuliner, Sharing RPP, SolveDir