[Swan] vti support

[Charles Wyble]

Hello again,

I have established an IPSEC tunnel between by Cisco 2811 and Ubuntu 14.04.

I'm now attempting to have VTi work.

Per https://libreswan.org/wiki/Route-based_VPN_using_VTI it requires libreswan 3.18, however only 3.17 is released. I downloaded the source from github and compiled, that gives me

***@tsys-shared-router:~# ipsec --version
Linux Libreswan v3.17-270-g40099bd-master (netkey) on 4.2.0-35-generic
***@tsys-shared-router:~#

Is VTI working? Is there anything else I need to do to enable it?

No vti interface exists (except perhaps one instantiated by the kernel?)

***@tsys-shared-router:~# ip a |grep vti
15: ***@NONE: <NOARP> mtu 1332 qdisc noop state DOWN group default
***@tsys-shared-router:~#

[Paul Wouters]

I’m now attempting to have VTi work.
Per https://libreswan.org/wiki/Route-based_VPN_using_VTI it requires libreswan 3.18, however only 3.17 is released. I downloaded
the source from github and compiled, that gives me

You can also grab

https://download.libreswan.org/development/libreswan-3.18dr2.tar.gz

Is VTI working? Is there anything else I need to do to enable it?

Yes, see man ipsec.conf for the options mark= vti-interface= and
vti-routing=

That is explained in the VTI wiki page you linked above.

No vti interface exists (except perhaps one instantiated by the kernel?)

You need to establish the tunnel for the device to be created.
To see the tunnel device, use: ip tun

Paul

[Charles Wyble]

Ah ok. Thanks.

That did the trick. Greatly appreciate all of the help. Traffic is coming across on vti01 via tcpdump now.

I've got some routing/firewall issues to work out, but that's my problem.

:)

[Ruben Laban]

Hi,

Post by Charles Wyble
Ah ok. Thanks.
That did the trick. Greatly appreciate all of the help. Traffic is coming across on vti01 via tcpdump now.
I've got some routing/firewall issues to work out, but that's my problem.
:)

Just curious: did you have to use a newer version of the iproute(2)
package? My recent tests with both 14.04 and 16.04 led me to believe
that the `ip` command shipped with those, lack proper vti support.

Regards,
Ruben

[Charles Wyble]

Yes I sure did. I also had to symlink /bin/ip to my updated iptools, otherwise I got the dreaded "ipip doesn't support keys" or whatever message.


Anyway I'm having a terrible time with VTI. I can't get packets to transit the tunnel. I'm hoping it's something incredibly stupid, and I'll get called out in 2 seconds...


So here's the Cisco side:

satx-rtr01#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.195.2/30
MTU 17862 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.40.170.22, destination 158.69.183.161
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1422 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "VTI")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
131 packets output, 11756 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out

satx-rtr01#ping 192.168.195.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.195.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
satx-rtr01#

Tunnel0 config:

interface Tunnel0
ip address 192.168.195.2 255.255.255.252
tunnel source 10.40.170.22
tunnel destination 158.69.183.161
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
end


Here's the libreswan side:

# Connection to rack at JUAF-SAT01
conn satx
left=158.69.183.161 #ovh outside ip
leftsubnet=10.253.0.0/16 #ovh network
#leftsubnet=0.0.0.0/0
leftid=158.69.183.161 #ikeid of ovh side
right=38.103.217.178 #IOS outside address
rightsubnet=10.40.170.0/24 #network behind IOS
#rightsubnet=0.0.0.0/0
rightid=10.40.170.22 #IKEID sent by IOS
ike=aes128-sha1;modp4096
esp=aes128-sha1
type=tunnel
authby=secret
auth=esp
keyexchange=ike
keyingtries=2
disablearrivalcheck=no
ikev2=no
auto=start
mark=5/0xffffffff
vti-interface=vti01



The tunnel is being brought up by libreswan now (after running /usr/local/sbin/ipsec pluto --stderrlog --config /etc/ipsec.d/satx.conf --nofork and seeing the ipip key message)

Before starting ipsec, I have:

15: ***@NONE: <NOARP> mtu 1332 qdisc noop state DOWN group default
link/ipip 0.0.0.0 brd 0.0.0.0


After:
24: ***@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1332 qdisc noqueue state UNKNOWN group default
link/ipip 158.69.183.161 peer 38.103.217.178

(I'm capturing the output of the ipsec pluto to a typescript)

Looking through it I see:

***@tsys-shared-router:~# grep vti debug-ipsec-21387
Jun 1 01:58:08: "satx": prepare-client output: net.ipv4.conf.vti01.disable_policy = 1
Jun 1 01:58:08: "satx": prepare-client output: net.ipv4.conf.vti01.rp_filter = 0
Jun 1 01:58:08: "satx": prepare-client output: net.ipv4.conf.vti01.forwarding = 1
***@tsys-shared-router:~#


Please let me know if I can provide any more information.

At this point I believe it may be related to shorewall. I'm double and triple checking my configuration. At one point I had output from tcpdump of vti01 when I was attempting ping (getting ICMP unreachable from the Cisco side, yet he has no ACLs). I'm at my whits end here.



-----Original Message-----
From: Swan [mailto:swan-***@lists.libreswan.org] On Behalf Of Ruben Laban
Sent: Tuesday, May 31, 2016 12:50 AM
To: ***@lists.libreswan.org
Subject: Re: [Swan] vti support

Hi,

Post by Charles Wyble
Ah ok. Thanks.
That did the trick. Greatly appreciate all of the help. Traffic is coming across on vti01 via tcpdump now.
I've got some routing/firewall issues to work out, but that's my problem.
:)

Just curious: did you have to use a newer version of the iproute(2) package? My recent tests with both 14.04 and 16.04 led me to believe that the `ip` command shipped with those, lack proper vti support.

Regards,
Ruben

[Paul Wouters]

Post by Charles Wyble
Anyway I'm having a terrible time with VTI. I can't get packets to transit the tunnel. I'm hoping it's something incredibly stupid, and I'll get called out in 2 seconds...

Maybe :)

Post by Charles Wyble
interface Tunnel0
ip address 192.168.195.2 255.255.255.252
tunnel source 10.40.170.22
tunnel destination 158.69.183.161
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
# Connection to rack at JUAF-SAT01
conn satx
left=158.69.183.161 #ovh outside ip
leftsubnet=10.253.0.0/16 #ovh network
#leftsubnet=0.0.0.0/0
leftid=158.69.183.161 #ikeid of ovh side
right=38.103.217.178 #IOS outside address
rightsubnet=10.40.170.0/24 #network behind IOS
#rightsubnet=0.0.0.0/0
rightid=10.40.170.22 #IKEID sent by IOS
ike=aes128-sha1;modp4096
esp=aes128-sha1
type=tunnel
authby=secret
auth=esp
keyexchange=ike
keyingtries=2
disablearrivalcheck=no
ikev2=no
auto=start
mark=5/0xffffffff
vti-interface=vti01

You need to vti-routing=yes but I do believe that is the default.

But when you set the leftsubnet and rightsubnet, you limit the tunnel

Post by Charles Wyble
satx-rtr01#ping 192.168.195.1
Type escape sequence to abort.

is coming from 192.168.195.1, which doesn't fall within 10.253.0.0/16

If you type "ip route list" you will see that only 10.40.170.0/24 got
routed into the vt01 device, and only those packets will end up getting
encrypted.

Post by Charles Wyble
link/ipip 158.69.183.161 peer 38.103.217.178

That only shows you the gateway IP's to switch the VTI tunnel is bound.
You need to use "ip xfrm pol" (or actually ip -s xfrm pol) to see
which packets will match the policy to get encrypted for the IPsec SA.

Paul

[Charles Wyble]

Yes sir. Thank you!

Solved.

satx-rtr01>ping 192.168.195.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.195.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/136/180 ms
satx-rtr01>



leftsubnet=192.168.195.0/30
rightsubnet=192.168.195.0/30
auto=start
mark=5/0xffffffff
vti-interface=vti01
vti-routing=yes

[Paul Wouters]

Post by Charles Wyble
Yes sir. Thank you!
Solved.
satx-rtr01>ping 192.168.195.1
Type escape sequence to abort.
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/136/180 ms
satx-rtr01>

Awesome! Enjoy your vti01 interface and routing based VPN :)

Paul

Post by Charles Wyble
leftsubnet=192.168.195.0/30
rightsubnet=192.168.195.0/30
auto=start
mark=5/0xffffffff
vti-interface=vti01
vti-routing=yes

[Roberto Suárez Soto]

Post by Paul Wouters
Awesome! Enjoy your vti01 interface and routing based VPN :)

Sorry to be late to the party, but I've just noticed this
thread. Does VTI support mean that we don't have to use GRE+IPSec
anymore? Do these tunnels support dynamic routing protocols, like RIP,
BGP and OSPF? (specially considering that OSPF uses multicast)
Gracias,

[Paul Wouters]

Sorry to be late to the party, but I've just noticed this thread. Does VTI support mean that we don't have to use GRE+IPSec anymore? Do
these tunnels support dynamic routing protocols, like RIP, BGP and OSPF? (specially considering that OSPF uses multicast)

If you use a routing based VPN from 0.0.0.0/0 to 0.0.0.0/0 then
you can dynamically route into the vti device to send traffic
over the tunnel:

conn vti
[...]
leftsubnet=0.0.0.0/0
rightsubnet=0.0.0.0/0
vti-interface=vti0
vti-routing=no
mark=5/0xffffffff

When the connection comes up, you have a vti0 device. You can use
ip rule and ip route to do source and/or destination based routing
into the device to get those ranges encrypted and sent over the
tunnel.

Use vti-routing=yes if you just want to let libreswan do the routing
for you, which obviously cannot be done for 0/0 to 0/0 tunnels, but
can be done for simpler tunnels, like:

conn vti
[...]
leftsubnet=0.0.0.0/0
rightsubnet=10.0.0.0/8
vti-interface=vti0
vti-routing=yes
mark=5/0xffffffff

This will cause all packets destined for 10/8 to get encrypted without
any additional manual routing changes.

If people use this in a neat setup, please let us know because we would
like to add some example uses to our wiki.

See: https://libreswan.org/wiki/Route-based_VPN_using_VTI

Note: you need to use libreswan-3.18dr2 or git master for this feature.
We are planning to do the full 3.18 release later this week.

Paul