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: [email protected]
[mailto:[email protected]] On Behalf Of Olivier PELERIN
Sent: Wednesday, February 25, 2015 05:36
To: André Valentin; [email protected]
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: [email protected]
To: [email protected]
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: [email protected]
> To: [email protected]
> CC: [email protected]; [email protected];
[email protected]
> 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
[email protected]
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 [email protected] ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
_______________________________________________ Users mailing list
[email protected] https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
