Please provide the following data: - Output of `iptables-save` of both hosts - Output of `ip route show table all` of both hosts - Output of `ip address` of both hosts
Kind regards Noel On 22.09.2017 07:17, Sandesh Sawant wrote: > I have referred to following links and configured strongSwan to establish a > route-based VPN tunnel between 2 Linux 4.4.57 boxes. > https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN > <https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN> > https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges > <https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges> > > The data path used to work perfectly fine when both sides are using > strongSwan v5.5.1. After upgrading same setup to v5.5.2, tunnel gets > established but ping between the VTI interfaces doesn't work. If we ping from > host running v5.5.2, no ESP packet is sent out. If we ping form host running > v5.5.1 to host running v5.5.2, ESP packet goes out, but host running v5.5.2 > doesn't send ESP in response. > > My ipsec.conf file is as follows (install_route=no is added in > strongswan.conf): > conn 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0 > left=10.160.229.241 > leftid=10.160.229.241 > rightid=10.160.229.240 > leftsubnet=0.0.0.0/0 <http://0.0.0.0/0> > right=10.160.229.240 > rightsubnet=0.0.0.0/0 <http://0.0.0.0/0> > authby=secret > keyexchange = ikev2 > mark = 1 > auto = start > esp=aes128-sha1-modp2048 > ike=aes128-sha1-modp2048! > > Tunnel establishment works fine, there is nothing suspicious in logs, and the > output of 'ipsec statusall' is as follows: > > Status of IKE charon daemon (strongSwan 5.5.2, Linux 4.4.57, x86_64): > uptime: 18 days, since Aug 18 10:58:17 2017 > malloc: sbrk 1477008, mmap 0, used 357360, free 1119648 > worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, > scheduled: 6 > loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 > revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem > openssl fips-prf xcbc cmac hmac attr kernel-netlink resolve socket-default > stroke vici updown xauth-generic > Listening IP addresses: > 10.160.229.241 > Connections: > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0: > 10.160.229.241...10.160.229.240 IKEv2, dpddelay=30s > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0: local: [10.160.229.241] > uses pre-shared key authentication > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0: remote: [10.160.229.240] > uses pre-shared key authentication > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0: child: 0.0.0.0/0 > <http://0.0.0.0/0> === 0.0.0.0/0 <http://0.0.0.0/0> TUNNEL, dpdaction=restart > Routed Connections: > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}: ROUTED, TUNNEL, > reqid 6 > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{253}: 0.0.0.0/0 > <http://0.0.0.0/0> === 0.0.0.0/0 <http://0.0.0.0/0> > Security Associations (1 up, 0 connecting): > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: ESTABLISHED 6 hours > ago, 10.160.229.241[10.160.229.241]...10.160.229.240[10.160.229.240] > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKEv2 SPIs: > 066c631f67deb19d_i 009d1bbbed44b77a_r*, pre-shared key reauthentication in 91 > minutes > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0[30]: IKE proposal: > AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}: INSTALLED, TUNNEL, > reqid 6, ESP SPIs: cc9cecd6_i ce4575a3_o > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}: > AES_CBC_128/HMAC_SHA1_96/MODP_2048, 0 bytes_i (0 pkts, 1556478s ago) ( 0 > integrity_failed_errors) (0 replay_errors) (0 decryption_failures) (0 > sa_expired_error) (0 recv_errors), 0 bytes_o (0 pkts, 1556478s ago) (0 > encryption_failures)(0 spi_overflow_error)(0 send_errors), rekeying in 35 > minutes > 10.160.229.241_0.0.0.0/0-10.160.229.240_0.0.0.0/0{263}: 0.0.0.0/0 > <http://0.0.0.0/0> === 0.0.0.0/0 <http://0.0.0.0/0> > > The SA & SP downloaded in kernel are as follows: > > # ip x s s > src 10.160.229.241 dst 10.160.229.240 > proto esp spi 0xce4575a3 reqid 6 mode tunnel > replay-window 0 flag af-unspec > mark 0x1/0xffffffff > auth-trunc hmac(sha1) 0x542da7b70b7a0ad1ba0814a6bf544eb96a5826ab 96 > enc cbc(aes) 0xedf587dc5374762dcb6330ccd495eecb > anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 > src 10.160.229.240 dst 10.160.229.241 > proto esp spi 0xcc9cecd6 reqid 6 mode tunnel > replay-window 32 flag af-unspec > auth-trunc hmac(sha1) 0xcc345e738d8969334d8c4e6588c98ca43029fd8a 96 > enc cbc(aes) 0x9867e41aa23002f9cdd1b5b17cfde26c > anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000 > # ip x p s > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> > dir fwd priority 399999 ptype main > mark 0x1/0xffffffff > tmpl src 10.160.229.240 dst 10.160.229.241 > proto esp reqid 6 mode tunnel > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> > dir in priority 399999 ptype main > mark 0x1/0xffffffff > tmpl src 10.160.229.240 dst 10.160.229.241 > proto esp reqid 6 mode tunnel > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> > dir out priority 399999 ptype main > mark 0x1/0xffffffff > tmpl src 10.160.229.241 dst 10.160.229.240 > proto esp reqid 6 mode tunnel > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> > socket in priority 0 ptype main > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> > socket out priority 0 ptype main > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> > socket in priority 0 ptype main > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> > socket out priority 0 ptype main > > The corresponding VTI is configured as follows: > > ip link add vti-1 type vti key 1 local 10.160.229.241 remote 10.160.229.240 > ip link set vti-1 up > ip addr add 1.1.1.1/24 <http://1.1.1.1/24> dev vti-1 > > # ip link show vti-1 > 17: vti-1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1428 qdisc noqueue state > UNKNOWN mode DEFAULT group default qlen 1 > link/ipip 10.160.229.241 peer 10.160.229.240 > # ip tunnel show vti-1 > vti-1: ip/ip remote 10.160.229.240 local 10.160.229.241 ttl inherit > nopmtudisc key 1 > # > > Similarly vti-1 on the VPN peer is configured with IP address 1.1.1.1. > However ping between the VTI addresses doesn't work: > ping 1.1.1.1 -I vti-1 -c 1 > PING 1.1.1.1 (1.1.1.1) from 1.1.1.2 vti-1: 56(84) bytes of data. > ^C > --- 1.1.1.1 ping statistics --- > 1 packets transmitted, 0 received, 100% packet loss, time 0ms > > There is no ESP packet going out of the system. TX error count & carrier > count increase in output of ifconfig after this. Also the NoRoute Error > counter in VTI stat gets incremented after ping is attempted. > > What can be the reason for this? > > # ifconfig vti-1 > vti-1 Link encap:UNSPEC HWaddr > 0A-A0-E5-F1-00-00-02-00-00-00-00-00-00-00-00-00 > inet addr:1.1.1.2 P-t-P:1.1.1.2 Mask:255.255.255.0 > UP POINTOPOINT RUNNING NOARP MTU:1428 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:1 dropped:0 overruns:0 carrier:1 > collisions:0 txqueuelen:1 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > [root@NSX-edge-2-0 ~]# ip -s tunnel show > > ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0 > > RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts > > 0 0 0 0 0 0 > > TX: Packets Bytes Errors DeadLoop NoRoute NoBufs > > 0 0 0 0 0 0 > > vti-1: ip/ip remote 10.160.229.240 local 10.160.229.241 ttl inherit > nopmtudisc key 1 > > RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts > > 0 0 0 0 0 0 > > TX: Packets Bytes Errors DeadLoop NoRoute NoBufs > > 0 0 1 0 1 0 > > [root@NSX-edge-2-0 ~]# > > None of the error counters in /proc/net/xfrm_stat got incremented after this. > > The routing table seems to be sufficient for the traffic to flow between VTIs > and there are no duplicate routes. > > There are no firewall rules which block the traffic for 1.1.1.0/24 > <http://1.1.1.0/24> network in either direction. > > # route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0 > 1.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 vti-1 > # > > If the 5.5.1 peer sends ping, then ESP is received at 5.5.2 host and vti > stats show Rx count incrementing correctly, but Tx count doesn't increment > which means system didn't attempt to ICMP response back via VTI/tunnel. > > Things are working with the same setup/configuration when both hosts are > using v5.5.1. Has anyone faced similar issue when using route-based vpn after > upgrading to v5.5.2? Any pointers to debug the issue are appreciated. > > In wiki found this issue https://wiki.strongswan.org/issues/2404 where a > change is mentioned as "That's the case since 5.5.2 or 067fd2c6." Could this > change be the culprit? Or are there any other route-based VPN related changes > which are done after 5.5.1? > > Thanks, > Sandesh >
signature.asc
Description: OpenPGP digital signature
