[Swan] Incorrect XFRM policy with dynamic client IPs

[Brady Johnson]

Hello,

I have a Libreswan server and client and get different XFRM policies on the
client when the client's IP is statically set versus when it is dynamically
set from the server with rightaddresspool. This is with VTI route-based
encryption.

# ipsec version
Linux Libreswan 4.5 (XFRM) on 4.18.0-372.40.1.el8_6.x86_64

(client/server configs below for static and dynamic client IPs)

When the client IP is statically set, I get the following xfrm policy on
the client side. In this case everything works as expected. That is, static
host routes directed at the VTI port cause traffic to be put on the tunnel.

$ sudo ip xfrm policy
src 0.0.0.0/0 dst 172.16.2.0/24
        dir out priority 2097102 ptype main
        mark 0x5/0xffffffff
        tmpl src 172.16.1.10 dst 192.168.43.55
        proto esp reqid 16401 mode tunnel
src 172.16.2.0/24 dst 0.0.0.0/0
        dir fwd priority 2097102 ptype main
        mark 0x5/0xffffffff
        tmpl src 192.168.43.55 dst 172.16.1.10
        proto esp reqid 16401 mode tunnel
src 172.16.2.0/24 dst 0.0.0.0/0
        dir in priority 2097102 ptype main
        mark 0x5/0xffffffff
        tmpl src 192.168.43.55 dst 172.16.1.10
        proto esp reqid 16401 mode tunnel

But when the client IP is dynamically set from a server addresspool, I get
the following xfrm policy on the client side:

$ sudo ip xfrm policy
src 172.16.111.10/32 dst 172.16.2.0/24
        dir out priority 2080718 ptype main
        mark 0x5/0xffffffff
        tmpl src 172.16.1.10 dst 192.168.43.55
        proto esp reqid 16401 mode tunnel
src 172.16.2.0/24 dst 172.16.111.10/32
        dir fwd priority 2080718 ptype main
        mark 0x5/0xffffffff
        tmpl src 192.168.43.55 dst 172.16.1.10
        proto esp reqid 16401 mode tunnel
src 172.16.2.0/24 dst 172.16.111.10/32
        dir in priority 2080718 ptype main
        mark 0x5/0xffffffff
        tmpl src 192.168.43.55 dst 172.16.1.10
        proto esp reqid 16401 mode tunnel

Why do the policies get created differently? This is a problem for us,
since not all packets are put on the tunnel, even though there is a static
host route sending them to the VTI port. Is this a bug in this version or
is there a way to configure Libreswan to not do this? I tried manually
deleting the incorrect XFRM policies and creating them with '0.0.0.0/' as
seen above, but that did not work.


Server config with address pool:
-------------------------------------------

conn vpnserver.dl110-05.xyz.com
    # right is remote(client), left is local(server)
    left=192.168.43.55
    leftid="O=XYZ,CN=vpnserver.dl110-05.xyz.com"
    leftsubnet=172.16.2.55/24
    leftrsasigkey=%cert
    leftcert=vpnserver.dl110-05.xyz.com
    leftsendcert=always

    # Clients
    right=%any
    rightrsasigkey=%cert
    rightid=%fromcert
    rightca=%same
    rightsubnet=0.0.0.0/0
    rightaddresspool="172.16.111.10-172.16.111.99"

    # recommended dpd/liveness to cleanup vanished clients
    dpddelay=5
    dpdtimeout=30
    dpdaction=clear

    auto=add
    rekey=no
    ikelifetime=86400s
    salifetime=3600s
    ikev2=insist
    phase2=esp
    fragmentation=yes
    ike=aes256-sha1
    phase2alg=aes256-sha1

Client config with dynamic IP:
---------------------------------------

conn vpnclient.dl110-00.xyz.com
    right=192.168.43.55
    rightid="O=XYZ,CN=vpnserver.dl110-05.xyz.com"
    rightsubnet=172.16.2.55/24
    rightrsasigkey=%cert

    left=172.16.1.10
    leftrsasigkey=%cert
    leftid="O=XYZ,CN=vpnclient.dl110-00.xyz.com"
    leftcert=vpnclient.dl110-00.xyz.com
    leftupdown="/bin/ipsec_tunnel_tool_updown.xfrm.sh"
    leftsubnet=0.0.0.0/0
    leftmodecfgclient=yes

    mark=5/0xffffffff
    vti-interface=vti01
    vti-routing=yes
    vti-shared=no

    dpddelay=5
    dpdtimeout=30
    dpdaction=restart

    rekey=yes
    auto=start
    ikelifetime=86400s
    salifetime=3600s
    phase2=esp
    fragmentation=yes
    ike=aes256-sha1
    phase2alg=aes256-sha1


Server config with static client IP:
--------------------------------------------

conn vpnserver.dl110-05.xyz.com
    left=192.168.43.55
    leftid="O=XYZ,CN=vpnserver.dl110-05.xyz.com"
    leftsubnet=172.16.2.55/24
    leftrsasigkey=%cert
    leftcert=vpnserver.dl110-05.xyz.com
    leftsendcert=always

    # Clients
    right=%any
    rightrsasigkey=%cert
    rightid=%fromcert
    rightca=%same
    rightsubnet=0.0.0.0/0

    dpddelay=5
    dpdtimeout=30
    dpdaction=clear

    auto=add
    rekey=no
    ikelifetime=86400s
    salifetime=3600s
    ikev2=insist
    phase2=esp
    fragmentation=yes
    ike=aes256-sha1
    phase2alg=aes256-sha1


Client config with static IP:
---------------------------------------

conn vpnclient.dl110-00.xyz.com
    right=192.168.43.55
    rightid="O=XYZ,CN=vpnserver.dl110-05.xyz.com"
    rightsubnet=172.16.2.55/24
    rightrsasigkey=%cert

    left=172.16.1.10
    leftrsasigkey=%cert
    leftid="O=XYZ,CN=vpnclient.dl110-00.xyz.com"
    leftcert=vpnclient.dl110-00.xyz.com
    leftupdown="/bin/ipsec_tunnel_tool_updown.xfrm.sh"
    leftsourceip=172.16.111.10
    leftsubnet=0.0.0.0/0
    leftvti=172.16.111.10/24

    mark=5/0xffffffff
    vti-interface=vti01
    vti-routing=yes
    vti-shared=no
    # The rest of the config is the same as the dynamic IP config


Regards,

*Brady Johnson*
Principal Software Engineer
Telco Solutions & Enablement
brady.johnson at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20230214/9138decd/attachment.htm>