[strongSwan] Strongswan using VTI - got it working!

Jeff Leung jleung at v10networks.ca
Sun Mar 8 09:39:39 CET 2015


Sorry to bring this topic up again, but here it goes...

 

 

Alright, there seems to be issues with strongSwan 5.2 on the way how it sets up a Cisco VTI tunnel. I was able to get a working VTI tunnel established between 2 VyOS 1.1 machines that has strongSwan 4.5.2 bundled. The kernel version used in VyOS 1.1 is the 3.13 series.

 

The following is the relevant ipsec.conf section VyOS 1.1 generates with the 4.5.2 stack:

 

conn peer-192.168.14.2-tunnel-vti

        left=192.168.14.1

        right=192.168.14.2

        leftsubnet=0.0.0.0/0

        rightsubnet=0.0.0.0/0

        ike=aes128-sha1-modp1024!

        keyexchange=ikev1

        ikelifetime=28800s

        esp=aes256-sha1!

        keylife=3600s

        rekeymargin=540s

        type=tunnel

        pfs=yes

        pfsgroup=modp1024

        compress=no

        authby=secret

        mark=9437185

        leftupdown="/usr/lib/ipsec/vti-up-down vti0"

        auto=start

        keyingtries=%forever

 

 

The following is the output from the ip xfrm policy command:

 

src 0.0.0.0/0 dst 0.0.0.0/0

        dir out priority 2051 ptype main

        mark 9437185/0xffffffff

        tmpl src 192.168.14.1 dst 192.168.14.2

                proto esp reqid 16388 mode tunnel

src 0.0.0.0/0 dst 0.0.0.0/0

        dir fwd priority 2051 ptype main

        mark 9437185/0xffffffff

        tmpl src 192.168.14.2 dst 192.168.14.1

                proto esp reqid 16388 mode tunnel

src 0.0.0.0/0 dst 0.0.0.0/0

        dir in priority 2051 ptype main

        mark 9437185/0xffffffff

        tmpl src 192.168.14.2 dst 192.168.14.1

                proto esp reqid 16388 mode tunnel

src ::/0 dst ::/0

        socket out priority 0 ptype main

src ::/0 dst ::/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src ::/0 dst ::/0

        socket in priority 0 ptype main

src ::/0 dst ::/0

        socket out priority 0 ptype main

src ::/0 dst ::/0

        socket in priority 0 ptype main

src ::/0 dst ::/0

        socket out priority 0 ptype main

src ::/0 dst ::/0

        socket in priority 0 ptype main

src ::/0 dst ::/0

        socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

 

The VTI tunnel was brought up by this command:

 

/sbin/ip link add $tunName type vti local $lip remote $peer okey $genmark

 

Where $tunName is vti0, $lip (192.168.14.1) is the host's local IP and $peer (192.168.14.2) is the Remote peer's address and $genmark (9437185) is the xfrm policy mark.

 

In the case outlined above, both ends can ping each other with the IP addresses assigned inside the VTI tunnel. Everything else works just fine.

 

However once we switch gears to a build of VyOS that is strongSwan 5.x aware, the configuration as follows breaks. What's worse is both ends can't ping anything other than the two peer's addresses that are not specified inside the VTI tunnel. In both ends ring returns with a TTL exceeded in transit error.

 

The following is the relevant ipsec.conf section for the strongSwan 5.2.2 IPsec stac:



conn peer-192.168.14.2-tunnel-vti

        left=192.168.14.1

        right=192.168.14.2

        leftsubnet=0.0.0.0/0

        rightsubnet=0.0.0.0/0

        ike=aes128-sha1-modp1024!

        keyexchange=ikev1

        ikelifetime=28800s

        esp=aes256-sha1,modp1024!

        keylife=3600s

        rekeymargin=540s

        type=tunnel

        compress=no

        authby=secret

        mark=9437185

        leftupdown="/usr/lib/ipsec/vti-up-down vti0"

        auto=start

        keyingtries=%forever

ip xfrm policy output of the machine with the 5.2.2 stack:

 

src 0.0.0.0/0 dst 0.0.0.0/0

        dir fwd priority 3075 ptype main

        mark 9437185/0xffffffff

        tmpl src 192.168.14.2 dst 192.168.14.1

                proto esp reqid 4 mode tunnel

src 0.0.0.0/0 dst 0.0.0.0/0

        dir in priority 3075 ptype main

        mark 9437185/0xffffffff

        tmpl src 192.168.14.2 dst 192.168.14.1

                proto esp reqid 4 mode tunnel

src 0.0.0.0/0 dst 0.0.0.0/0

        dir out priority 3075 ptype main

        mark 9437185/0xffffffff

        tmpl src 192.168.14.1 dst 192.168.14.2

                proto esp reqid 4 mode tunnel

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket in priority 0 ptype main

src 0.0.0.0/0 dst 0.0.0.0/0

        socket out priority 0 ptype main

src ::/0 dst ::/0

        socket in priority 0 ptype main

src ::/0 dst ::/0

        socket out priority 0 ptype main

src ::/0 dst ::/0

        socket in priority 0 ptype main

src ::/0 dst ::/0

        socket out priority 0 ptype main

 

One thing to note in particular in both cases - VyOS does not delete the default route in table 220 as generated by strongSwan. I suspect for some reason the way how the VTI tunnels are configured is causing the network stack not to redirect marked packets to the VTI tunnel interface.

If additional information is needed, please feel free to reply to this thread and ask for the missing information. I would be glad to provide you the missing information since strongSwan 5.2.2 may eventually end up in VyOS 1.3 or EdgeOS 1.8 releases. 

 

From: users-bounces at lists.strongswan.org [mailto:users-bounces at lists.strongswan.org] On Behalf Of Olivier PELERIN
Sent: Wednesday, February 25, 2015 05:36
To: André Valentin; users at lists.strongswan.org
Subject: Re: [strongSwan] Strongswan using VTI - got it working!

 

Hello,

Apologize for the huge delay but I had many things going on. I will try to restart my environment in a few days. I will paste the Cisco config + the Strongswan side. I'm sure it can be useful for someone.

Regards

________________________________

Date: Fri, 19 Dec 2014 15:37:32 +0100
From: avalentin at marcant.net
To: users at lists.strongswan.org
Subject: Re: [strongSwan] Strongswan using VTI - got it working!

Hi!

It would be wonderful if you could document your setup in an email to the list, inluding kernel version. I would even create an Wiki Article for it, if it's allowed.

Kind regards,

André

Am 19.12.2014 um 15:11 schrieb Olivier PELERIN:

	Thanks Martin!
	
	Quick question, If I understand you well, it's a global setting. 
	Are you planning to add a knob under the conn itself? It would be nice to be able to control it per conn.
	
	Regards,
	
	Olivier

	> Subject: Re: [strongSwan] Strongswan using VTI - got it working!
	> From: martin at strongswan.org
	> To: olivier_pelerin at hotmail.com
	> CC: schwarz at gaertner.de; noel at familie-kuntze.de; users at lists.strongswan.org
	> Date: Fri, 19 Dec 2014 15:07:09 +0100
	> 
	> 
	> > Question: what is the use of that table 220? Do we have a CLI to avoid
	> > Strongswan installing that route? It's not necessary in case of VTI.
	> 
	> strongSwan installs routes for negotiated policies to a dedicated
	> routing table mainly for two reasons:
	> * Avoid any conflicts with the main routing table, for example
	> with the default route
	> * Ignore routes from this table when doing route lookups for IKE
	> traffic; IKE packets should always bypass the tunnel.
	> 
	> To disable automatic route installation, set the install_routes option
	> to no in the strongswan.conf "charon" section. The routing_table and
	> routing_table_prio options allow you to customize installation of
	> routes.
	> 
	> Regards
	> Martin
	> 

	
	
	

	_______________________________________________
	Users mailing list
	Users at lists.strongswan.org
	https://lists.strongswan.org/mailman/listinfo/users



Mit freundlichen Grüßen
André Valentin
Systemadministrator
-- 
MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net | http://www.global-m2m.com

Internet * Netzwerk * Mobile Daten
Citrix Silver Solution Advisor

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___________________________________________________________
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter support at marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

_______________________________________________ Users mailing list Users at lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150308/2e3ee5d0/attachment-0001.html>


More information about the Users mailing list