[strongSwan] (no subject)
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Thu Oct 5 00:03:19 CEST 2017
Hi Sandesh
There's no POSTROUTING chain in the *filter table, so your command will never work.
The table is probably *mangle, because *nat never gets packets with ctstate INVALID.
You're probably missing something major here.
Please provide the information listed here[1] using the provided commands.
[1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests
On 03.10.2017 14:34, Sandesh Sawant wrote:
> 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 <mailto: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 <tel:22.09.2017%2007>: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/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> <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> <http://0.0.0.0/0>
> > right=10.160.229.240
> > rightsubnet=0.0.0.0/0 <http://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> <http://0.0.0.0/0> === 0.0.0.0/0 <http://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> <http://0.0.0.0/0> === 0.0.0.0/0 <http://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> <http://0.0.0.0/0> === 0.0.0.0/0 <http://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> <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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> <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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> <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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> <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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> <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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> <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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> <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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> <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> <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 <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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171005/c55d7b25/attachment-0001.sig>
More information about the Users
mailing list