How to configure IPsec (strongswan) interface, so that only assigned interface gets virtual ip?

▲
1
▼

I have already used this configuration a bunch of times and I haven't had this problem before. Basically I establish the tunnel connection, but after connecting (with swanctl --initiate --child ch_vti0 --ike ch_vti0) I get my virtual ip assigned on the appropriate interface vti0, but also I have the same ip assigned on my main interface enp2s0 (The one connected to the internet)

From the journal with extended debugging options I get the following (shortened for the sake of brevity):

юли 29 09:33:45 malz charon-custom[21535]: 12[IKE] installing new virtual IP 172.13.14.3
...
юли 29 09:33:45 malz charon-custom[21535]: 12[KNL] virtual IP 172.13.14.3 installed on enp2s0
...
юли 29 09:33:45 malz charon-custom[21535]: 11[KNL] adding policy 192.168.122.0/24 === 172.13.14.3/32 in (mark 42/0xffffffff) [priority 371327, refcount 1]
...
юли 29 09:33:45 malz charon-custom[21535]: 11[KNL] using host 172.13.14.3
...
юли 29 09:33:45 malz charon-custom[21535]: 11[KNL] installing route: 192.168.122.0/24 via 10.3.218.62 src 172.13.14.3 dev enp2s0
...
юли 29 09:33:45 malz charon-custom[21535]: 11[IKE] CHILD_SA ch_vti0{1} established with SPIs cbaeec67_i c450a827_o and TS 172.13.14.3/32 === 192.168.122.0/24
...
юли 29 09:33:45 malz charon-custom[21535]: 16[KNL] 172.13.14.3 appeared on vti0

So basically I make the connection and immediately my main interface enp2s0 gets the virtual ip and after that the other interface vti0 gets the ip.

Side note: I know I can work around the issue by just deleting the route through the main interface, but my goal is to stop the assignment altogether.

My swanctl.conf (Initiator):

connections {
   ch_vti0 {
      send_cert = always
      encap = yes
      vips = 0.0.0.0
      remote_addrs = 10.3.218.62
      local {
         round = 1
         id = 10.3.72.29
         auth = psk
         certs = 
       }
      remote {
         auth = psk
         id = 10.3.218.62
         certs = 
       }
      children {
        ch_vti0 { 
            updown = /usr/local/etc/swanctl/updown.sh 0
            mark_in = 42 
            mark_out = 42 
            remote_ts = 192.168.122.2/24
            local_ts = dynamic
            inactivity = 300s
            mode = tunnel
            esp_proposals =  3des-sha1-modp2048
         }
      }
      version = 1 
      proposals =  des-md5-modp768, des-md5-modp1024, des-md5-modp1536
   }  }
secrets {
        eap-xauth {
        eap_id = test1
        id = test1
        secret = password
   }
        xauth-local {
        id = test1
        secret = password
        }
        ike-sec {
        id = %any
        secret = test
        }
        ike-local {
        id = 10.3.72.29
        secret = test
        }
}

The servers setup (responder):

connections {
   ch_vti0 {
      send_cert = always
      encap = yes
      pools = pools_users
      #aggressive = yes
      local {
         round = 1
         id = 10.3.218.62
         auth = psk
         certs = 
       }
      remote {
         auth = psk
         id = %any
         certs = 
       }
      children {
        ch_vti0 { 
            local_ts = 192.168.122.2/24
            inactivity = 120s
            mode = tunnel
            esp_proposals =  3des-sha1-modp2048
         }
      }
      version = 0
      proposals =  des-md5-modp768, des-md5-modp1024, des-md5-modp1536
   }  }
pools {
        pools_users {
                addrs = 172.13.14.2/24
        }
}
secrets {
        eap-xauth {
        eap_id = test1
        id = test1
        secret = password
   }
        xauth-local {
        id = test1
        secret = password
        }
        ike-sec {
        id = %any
        secret = test
        }
        ike-local {
        id = 10.3.218.62
        secret = test
        }
}

I also know that I can use the strongswan charon parameters:

# install_virtual_ip_on = vti0
# interfaces_use = vti0
# interfaces_ignore = enp2s0

But if I do the process can not progress as if it needs to use the enp2s0 interface. Has anyone else ever had this issue ? Any suggestions are welcome.

Also I am using strongSwan 5.7.2, Linux 4.18.0-25-generic.

About the updown script it really doesn't matter, because I get the same error if I do the same configuration without the script.

networking
ipsec
strongswan
bug
asked on Server Fault Jul 29, 2019 by Kostadin Krushkov • edited Jul 29, 2019 by Kostadin Krushkov

2 Answers

▲
0
▼

Seems like you need add only install_virtual_ip_on = vti0 option to solve your issue.

Don't touch the interfaces_use and interfaces_ignore options.

answered on Server Fault Jul 29, 2019 by Anton Danilov
▲
0
▼

So I finally found a way to do correct this. The problem as I said was that the wrong interface was used on top of the correct interface, I haven't figured out why, but the workaround I did find I believe is good enough. In the strongswan.conf (usually in /etc/strongswan.conf or /usr/local/etc/strongswan.conf) set the variable install_routes = no , its yes by default. From the StrongSwan docs the variable is:

Install routes into a separate routing table for established IPsec tunnels. If disabled a more efficient lookup for source and next-hop addresses is used since 5.5.2.

So by doing this I forbid the creating of table 220 and addition of routes to it. Instead it configures the correct route on it's own by checking which interface has a route to the particular IP.

As already mentioned using the variables may also solve your problem.

# install_virtual_ip_on = vti0
# interfaces_use = vti0
# interfaces_ignore = enp2s0

strongswan.conf:

charon {
        install_routes = no
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
include strongswan.d/*.conf
}
answered on Server Fault Jul 30, 2019 by Kostadin Krushkov

User contributions licensed under CC BY-SA 3.0