[strongSwan] (no subject)

Tue Oct 3 14:34:46 CEST 2017

Hi Noel,

Apologies for late response. The setup I was using had to be dismantled and
rebuilt. After further debugging it is found that this issue isn't related
to strongswan/xfrm behavior - it's related to firewall. The reason for the
VTI ping not going out of ipsec tunnel was a firewall rule: iptables -A
POSTROUTING -m state --state INVALID -j DROP
If this rule is deleted or overridden with iptables -I POSTROUTING -o
vNic_0 -j ACCEPT
then everything works fine. But I don't want to do it for security reasons.
Any idea why packet originating from VTI and entering corresponding tunnel
local endpoint interface is considered as INVALID state?

Thanks,
Sandesh

On Fri, Sep 22, 2017 at 2:50 PM, Noel Kuntze <
noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:

> 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 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 <
> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171003/315424ff/attachment-0001.html>