[strongSwan] Strongswan using VTI

Olivier PELERIN olivier_pelerin at hotmail.com
Thu Dec 18 09:04:33 CET 2014


Unfortunately that does not help. 

Stats are not showing any drops!

manowar python # cat /sys/class/net/vti0/statistics/rx_bytes 
199752
manowar python # ping 10.0.0.2 -I vti0
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 vti0: 56(84) bytes of data.
^C
--- 10.0.0.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

manowar python # cat /sys/class/net/vti0/statistics/rx_bytes 
199920

All errors counters under vti0 are remaining to zero.

Date: Wed, 17 Dec 2014 08:42:26 -0500
Subject: Re: [strongSwan] Strongswan using VTI
From: ryan at ryanruel.com
To: olivier_pelerin at hotmail.com
CC: users at lists.strongswan.org

When I've seen this happen before (interface sees the traffic, ping or some other process does not), it usually means it's getting dropped by the Kernel.
It's usually RP-filtering...  you can try to turn it off:
# echo 0 > /proc/sys/net/ipv4/conf/vti/rp_filter# echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
I wouldn't leave if off permanently, but it might help you get further with testing where the packets are going.
/Ryan
On Wed, Dec 17, 2014 at 7:15 AM, Olivier PELERIN <olivier_pelerin at hotmail.com> wrote:


Kernel wise I'm on 3.18.1. I saw few links on the internet about this prerouting mangling rules but it's very unclear if it's needed or not.  I would assume the ikey in the ip tunnel command is enough.

I've modified the config by specifying the local address [ instead of using %any] now I've added left=10.1.1.1

ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2rc1, Linux 3.18.1-gentoo, x86_64):
  uptime: 2 minutes, since Dec 17 13:07:54 2014
  malloc: sbrk 2416640, mmap 0, used 377184, free 2039456
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon ldap aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
  192.168.255.134
  10.1.1.1
  10.0.0.1
Connections:
         VTI:  10.1.1.1...10.1.1.254  IKEv2
         VTI:   local:  [10.1.1.1] uses pre-shared key authentication
         VTI:   remote: [10.1.1.254] uses pre-shared key authentication
         VTI:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL
Routed Connections:
         VTI{1}:  ROUTED, TUNNEL
         VTI{1}:   0.0.0.0/0 === 0.0.0.0/0 
Security Associations (1 up, 0 connecting):
         VTI[1]: ESTABLISHED 2 minutes ago, 10.1.1.1[10.1.1.1]...10.1.1.254[10.1.1.254]
         VTI[1]: IKEv2 SPIs: 2be274863074302d_i* 720fa6a0e8c28b09_r, pre-shared key reauthentication in 2 hours
         VTI[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
         VTI{1}:  INSTALLED, TUNNEL, ESP SPIs: c8da39c8_i 938ec319_o
         VTI{1}:  AES_CBC_256/HMAC_SHA1_96, 12848 bytes_i (152 pkts, 23s ago), 12348 bytes_o (147 pkts, 23s ago), rekeying in 39 minutes
         VTI{1}:   0.0.0.0/0 === 0.0.0.0/0 


Now I'm one step further. I see bytes_i and bytes_o increasing.

running tcpdump directly on the VTI interface I see the echo-reply arriving

manowar python # tcpdump -nNi vti0
error : ret -1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vti0, link-type RAW (Raw IP), capture size 262144 bytes
13:09:37.669100 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 18052, seq 4366, length 64
13:09:37.669564 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 18052, seq 4366, length 64
13:09:38.669208 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 18052, seq 4367, length 64
13:09:38.669691 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 18052, seq 4367, length 64

Still traffic seems not to reach the ping process 

ping 10.0.0.2 -I vti0
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 vti0: 56(84) bytes of data.

vti0 sees the traffic but not the ping process??





Subject: Re: [strongSwan] Strongswan using VTI
From: ryan0751 at gmail.com
Date: Wed, 17 Dec 2014 06:50:47 -0500
CC: users at lists.strongswan.org
To: olivier_pelerin at hotmail.com

I was just trying to get this to work the other day myself and also had problems with the routing.
It wasn’t clear to me if you still need to create the PREROUTING mangle rules. such as:# mangle PREROUTING rules:
iptables -t mangle -A PREROUTING -s 192.168.10.0/24 -d 192.168.11.0/24 
-j MARK --set-mark 32
iptables -t mangle -A PREROUTING -p esp -s 10.1.3.2 -d 10.1.1.2 -j MARK 
--set-mark 32From what I had read the Kernel might have been patched to no longer require this?  
Have you checked the SA stats on the Linux box (setkey -D or using the ip xfrm command) to see if the packets are matching the SA and are being decrypted?
/Ryan
On Dec 17, 2014, at 6:08 AM, Olivier PELERIN <olivier_pelerin at hotmail.com> wrote:
Dear Strongswan alias,

I'm trying a VTI config between a linux box and a cisco router. 

I've created a VTI interface on my linux

ip tunnel add vti0 mode vti local 10.1.1.1 remote 10.1.1.254 okey 32 ikey 32
 ip link set vti0 up
 ip addr add 10.0.0.1/30 remote 10.0.0.2/30 dev vti0

conn VTI
        keyexchange=ikev2
        ike=aes256-sha1-modp1024
        esp=aes256-sha1!
        leftid=10.1.1.1
        leftauth=psk
        leftsubnet=0.0.0.0/0
        rightauth=psk
        right=10.1.1.254
        rightid=10.1.1.254
        rightsubnet=0.0.0.0/0
        mark=32
        auto=route




manowar python # ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.2rc1, Linux 3.18.1-gentoo, x86_64):
  uptime: 114 seconds, since Dec 17 11:53:47 2014
  malloc: sbrk 2416640, mmap 0, used 373840, free 2042800
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon ldap aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
  192.168.255.134
  10.1.1.1
  10.0.0.1
Connections:
         VTI:  %any...10.1.1.254  IKEv2
         VTI:   local:  [10.1.1.1] uses pre-shared key authentication
         VTI:   remote: [10.1.1.254] uses pre-shared key authentication
         VTI:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL
Routed Connections:
         VTI{1}:  ROUTED, TUNNEL
         VTI{1}:   0.0.0.0/0 === 0.0.0.0/0 
Security Associations (1 up, 0 connecting):
         VTI[1]: ESTABLISHED 109 seconds ago, 10.1.1.1[10.1.1.1]...10.1.1.254[10.1.1.254]
         VTI[1]: IKEv2 SPIs: e1e9a005055323ab_i* 78c7cc9d34a5886f_r, pre-shared key reauthentication in 2 hours
         VTI[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
         VTI{1}:  INSTALLED, TUNNEL, ESP SPIs: c8031e20_i 37b2a5a2_o
         VTI{1}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 1848 bytes_o (22 pkts, 8s ago), rekeying in 44 minutes
         VTI{1}:   0.0.0.0/0 === 0.0.0.0/0 


I do have ESP in 

manowar python #  tcpdump -nNi netio0
error : ret -1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on netio0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:07:57.840726 IP 10.1.1.1 > 10.1.1.254: ESP(spi=0x37b2a5a2,seq=0x2bf), length 132
12:07:57.841405 IP 10.1.1.254 > 10.1.1.1: ESP(spi=0xc8031e20,seq=0x2bf), length 132
12:07:58.840971 IP 10.1.1.1 > 10.1.1.254: ESP(spi=0x37b2a5a2,seq=0x2c0), length 132
12:07:58.841336 IP 10.1.1.254 > 10.1.1.1: ESP(spi=0xc8031e20,seq=0x2c0), length 132


But it seems not be decapsulated by the kernel.

Any ideas why?
_______________________________________________Users mailing listUsers at lists.strongswan.orghttps://lists.strongswan.org/mailman/listinfo/users 		 	   		  

_______________________________________________

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/20141218/b8d7da05/attachment-0001.html>


More information about the Users mailing list