[strongSwan] (no subject)
Sandesh Sawant
sandesh.sawant at gmail.com
Fri Sep 22 07:17:06 CEST 2017
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/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
right=10.160.229.240
rightsubnet=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 ===
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 ===
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 ===
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 dst 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 dst 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 dst 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 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 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 dev vti-1
# ip link show vti-1
17: vti-1 at 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 at 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 at 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170922/71a852ab/attachment.html>
More information about the Users
mailing list