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: [email protected]
Date: Wed, 17 Dec 2014 06:50:47 -0500
CC: [email protected]
To: [email protected]
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 <[email protected]>
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
[email protected]https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
