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 < [email protected]> 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: [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 32 > > From 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 list > [email protected] > https://lists.strongswan.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > https://lists.strongswan.org/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
