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