[Swan] feature request - route based (vti) vpn - ip address on tunnel interfaces

Mon Sep 5 17:10:58 UTC 2016

Dear,

  I didnt know much on which list to ask that, but i believe that's a more dev situation then users. Its also a double post from swan-dev list. I do not know if someone else has the same issue we have here, but here it goes:

 I would like to request a new feature. Let me explain our scenario and what we trying to do libreswan:

  We have on our Datacenter, a Palo Alto device that does handle as our VPN Server (IPsec) to multiple sites, and we use dynamic routing protocols (BGP and OSPF) -- currently BGP on the VPN side. We can make it properly work w/ other Palo Alto and Cisco devices.

   The following links describes what we need to configure on devices: https://live.paloaltonetworks.com/twzvq79624/attachments/twzvq79624/documentation_tkb/525/1/How_to_Configure-Dynamic_Routing_over_IPSec_against_Cisco-vc.pdf

   We have many sites that we are using Linux, and we choose Libreswan to be our VPN IPsec software. We first started using policy based VPN but we quickly found a problem: Dynamic Routing Protocols did not work as expected. The real trick is that routing protocols demand IP on tunnel interfaces to work properly and exchange adversites and routing protocol information. I was glad i found VTI support on the beta release, that really solves the issue, as i have a tunnel interface to route thru.

   I quickly found the problem. We need to have configured IP on the tunnel interface, and libreswan did not the manage that to do it properly. We could get the tunnel UP with properly local/remote ip address, but the interface did not have IP address (which is required to by routing protocols).

  What we need to do is configure one ip address, like 192.168.168.1/30 on site A (palo alto) and 192.168.168.2/30 on site B, and the local and remote tunnel which are the real ip address that we use to connect (that works good). To solve the issue i had to manually set the ip address by myself: # ip addr add 192.168.168.2/30 dev <vti-interface>

   Here are my configs:

   # conn.conf
    conn tjpa-vpn
        authby=secret
        auto=start
        left=10.87.133.6
        leftid=10.87.133.6
        right=10.87.1.1
        rightid=10.87.1.1
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        phase2=esp
        phase2alg=aes256-sha1;modp1536
        mark = 87/0xffffff
        vti-interface=vti-pdp
        vti-routing=no

# ip tunnel show
ip_vti0: ip/ip  remote any  local any  ttl inherit  nopmtudisc key 0
vti-pdp: ip/ip  remote 10.87.1.1  local 10.87.133.6  ttl inherit  key 87

# ifconfig vti-pdp
vti-pdp: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1480
        inet 192.168.168.2  netmask 255.255.255.252  destination 192.168.168.2
        tunnel   txqueuelen 0  (IPIP Tunnel)
        RX packets 13  bytes 970 (970.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 1528 (1.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ip route show
default via 192.168.168.1 dev vti-pdp  proto zebra
10.21.0.0/16 via 10.21.133.1 dev eth0  proto static  metric 100
10.21.133.0/24 dev eth0  proto kernel  scope link  src 10.21.133.3  metric 100
10.87.0.0/16 via 10.87.133.10 dev eth2  proto static  metric 100
10.87.133.0/24 dev eth2  proto kernel  scope link  src 10.87.133.6  metric 100
10.139.0.0/16 dev eth1  proto kernel  scope link  src 10.139.0.20  metric 100
172.18.0.0/21 via 192.168.168.1 dev vti-pdp  proto zebra
192.168.168.0/30 dev vti-pdp  proto kernel  scope link  src 192.168.168.2

So its fully working as i would like. I had to do a nasty workaround with systemd to get it working:

I had to add to ipsec.service ->

ExecStartPost=/opt/set-tunnel-ip.sh

# cat /opt/set-tunnel-ip.sh
#!/bin/bash
sleep 5
ip addr add 192.168.168.2/30 dev vti-pdp

 Observation: If we do not "wait" to set up ip address, it fails because the interface is not created yet.

I think i already explained my scenario (hope thats enough details, even though long). As looking into the code and scripts i found _updown.netkey script and looked into addvtiiface() function on the following codes:

if [ ! -d "/proc/sys/net/ipv4/conf/${VTI_IFACE}" ]; then
                # echo "creating vti interface"
                vtipeer="${PLUTO_PEER}"
                if [ "${PLUTO_CONN_KIND}" = CK_INSTANCE -o "${VTI_SHARED}" = "yes" ]; then
                    vtipeer="0.0.0.0"
                fi
                ip tunnel add ${VTI_IFACE} mode vti local ${PLUTO_ME} \
                    remote ${vtipeer} okey ${CONNMARK_OUT%/*} \
                    ikey ${CONNMARK_IN%/*}
                sysctl -w net.ipv4.conf.${VTI_IFACE}.disable_policy=1
                sysctl -w net.ipv4.conf.${VTI_IFACE}.rp_filter=0
                sysctl -w net.ipv4.conf.${VTI_IFACE}.forwarding=1
                ip link set ${VTI_IFACE} up

    Modify here would fix everything. We just need to set the following command after the interface is up (or add another function).

     if [ -n "${VTI_IP}" ]; then
      ip addr add ${VTI_IP} dev ${VTI_IFACE}
    fi

    Also, we need to modify to read {VTI_IP} from the configuration file. I would suggest another keyword:

    vti-ip=192.168.168.2/30

    I believe the modifications should be fairly easy to implement. It should not be compatible with vti-shared as each tunnel must have its own unique ip. And by adding this feature it would make libreswan compatible with most VPN software (commercial) w/ Route based and Dynamic Routing Protocols.

     I would like to hear back from you guys if that's possible to do, and i believe it should not be much hard to implement.

Best regards,

Att,
Bruno Benchimol

Tribunal de Justiça do Estado Pará
Chefe do Serviço de Segurança e Sistemas Básicos
(91) 3250-8383

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20160905/f5dd51a2/attachment.html>