Thank you Paul,
ipsec verify
Version check and ipsec on-path [OK]
Libreswan 3.20dr1 (netkey) on 3.10.0-123.4.4.el7.x86_64
Checking for IPsec support in kernel [OK]
NETKEY: Testing XFRM related proc values
ICMP default/send_redirects [OK]
ICMP default/accept_redirects [OK]
XFRM larval drop [OK]
Pluto ipsec.conf syntax [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking rp_filter [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for IKE/NAT-T on udp 4500 [OK]
Pluto ipsec.secret syntax [OK]
Checking 'ip' command [OK]
Checking 'iptables' command [OK]
Checking 'prelink' command does not interfere with FIPS [OK]
Checking for obsolete ipsec.conf options [OK]
I have pretty stock routing, there is a simple SNAT and not much else.
This is the pattern I see, where the public IP is cell provider, server side is
AWS
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5df), length 100
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e0), length 100
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e1), length 100
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e2), length 100
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e3), length 100
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e4), length 100
IP 172.31.255.216.ipsec-nat-t > 199.119.233.253.36173: isakmp-nat-keep-alive
IP 172.31.255.216.ipsec-nat-t > 199.119.233.253.36173: isakmp-nat-keep-alive
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e5), length 116
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e6), length 100
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e7), length 100
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e8), length 116
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5e9), length 116
IP 199.119.233.253.36173 > 172.31.255.216.ipsec-nat-t: UDP-encap:
ESP(spi=0xXXXXXXXXX,seq=0x5eb), length 100
Also, as per
https://libreswan.org/wiki/FAQ#Using_SHA2_256_for_ESP_connection_establishes_but_no_traffic_passes_.28especially_Android_6.0.29
I experimented with leaving only esp=aes_gcm-null but nothing seems to change
> On Mar 10, 2017, at 5:09 PM, Paul Wouters <[email protected]> wrote:
>
> On Wed, 8 Mar 2017, Viktor Keremedchiev wrote:
>
>> I’ve adjusted the type to tunnel, although OSX clients work(ed) flawlessly.
>>
>> I removed marking but there is still no traffic from my android device
>>
>> Anything else I can try?
>
> I don't know then. It should work fine. Perhaps "ipsec verify" logs a
> few warnings ? Could be rp_filter or redirects or anything?
>
>> Also is there a way to push search domains, and NOT just domains
>> (modecfgdomain=)
>
> No. That would be a security issue. However for IKEv2 we are working to
> support https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns which
> does allow at least to specify multiple domains to forward via the VPN.
>
> Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
