Issue #2351
no traffic through tunnel
Description
Hi guys,
I've built 5.5.3 on a friendlyarm neo2 sbc board. StrongSwan built fine and I'm able to start a tunnel to a remote VPN server. The remote VPN server is confirmed working fine with another box running 5.5.2 with identical ipsec.conf and keys. Here's some config and logs, I hope someone can help workout what's missing / needed to get this working
ipsec.conf:
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn ikev2-conn
fragmentation=yes
rekey=no
dpdaction=clear
keyexchange=ikev2
compress=no
dpddelay=35s
ike=aes128gcm16-prfsha512-ecp256,aes128-sha2_512-prfsha512-ecp256,aes128-sha2_384-prfsha384-ecp256!
esp=aes128gcm16-ecp256,aes128-sha2_512-prfsha512-ecp256!
right=<server_ip>
rightid=<server_ip>
rightsubnet=0.0.0.0/0
rightauth=pubkey
leftsourceip=%config
leftauth=pubkey
leftcert=joe.crt
leftfirewall=yes
left=%defaultroute
auto=start
conn bypass
left=127.0.0.1
right=127.0.0.1
leftsubnet=192.168.0.1/24
rightsubnet=192.168.0.1/24
authby=never
type=pass
auto=route
Basic routing appears to be working ok and I've verified that IP forwarding is switched on and working:
root@nanopineo2:~# sysctl -A | grep forwarding net.ipv4.conf.all.forwarding = 1 net.ipv4.conf.all.mc_forwarding = 0 net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.mc_forwarding = 0 net.ipv4.conf.eth0.forwarding = 1 net.ipv4.conf.eth0.mc_forwarding = 0 net.ipv4.conf.lo.forwarding = 1 net.ipv4.conf.lo.mc_forwarding = 0 net.ipv6.conf.all.forwarding = 0 sysctl: reading key "net.ipv6.conf.all.stable_secret"net.ipv6.conf.all.mc_forwarding = 0 sysctl: reading key "net.ipv6.conf.default.stable_secret" net.ipv6.conf.default.forwarding = 0 net.ipv6.conf.default.mc_forwarding = 0 sysctl: reading key "net.ipv6.conf.eth0.stable_secret" net.ipv6.conf.eth0.forwarding = 0 net.ipv6.conf.eth0.mc_forwarding = 0 sysctl: reading key "net.ipv6.conf.lo.stable_secret" net.ipv6.conf.lo.forwarding = 0 net.ipv6.conf.lo.mc_forwarding = 0
When ssh'd into the box, a simple curl seems to attempt to route down the tunnel but eventually times out and fails. I've logged some traffic caught via tcpdump during a curl attempt:
root@nanopineo2:~# tcpdump -s 0 -n -i nflog:5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on nflog:5, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes 22:08:31.346391 IP 52.17.240.124.4500 > 192.168.0.10.4500: NONESP-encap: isakmp: child_sa inf2 22:08:31.346647 IP 192.168.0.10.4500 > 52.17.240.124.4500: NONESP-encap: isakmp: child_sa inf2[IR] 22:08:31.346676 IP 10.19.48.1.60727 > 172.16.0.1.53: 34884+ A? api.ipify.org. (31) 22:08:31.346785 IP 192.168.0.10.4500 > 52.17.240.124.4500: UDP-encap: ESP(spi=0xcd9a53cb,seq=0xa1), length 96 22:08:31.346812 IP 10.19.48.1.60727 > 172.16.0.1.53: 61822+ AAAA? api.ipify.org. (31) 22:08:31.346876 IP 192.168.0.10.4500 > 52.17.240.124.4500: UDP-encap: ESP(spi=0xcd9a53cb,seq=0xa2), length 96 22:08:31.346901 IP 52.17.240.124.4500 > 192.168.0.10.4500: UDP-encap: ESP(spi=0xce5e1f38,seq=0x39), length 288 22:08:31.346925 IP 172.16.0.1.53 > 10.19.48.1.60727: 34884 8/0/0 CNAME nagano-19599.herokussl.com., CNAME elb097307-934924932.us-east-1.elb.amazonaws.com., A 23.23.102.58, A 54.235.148.27, A 23.23.120.37, A 50.19.238.1, A 184.73.167.153, A 54.243.147.114 (225) 22:08:31.347051 IP 52.17.240.124.4500 > 192.168.0.10.4500: UDP-encap: ESP(spi=0xce5e1f38,seq=0x3a), length 272 22:08:31.347076 IP 172.16.0.1.53 > 10.19.48.1.60727: 61822 2/1/0 CNAME nagano-19599.herokussl.com., CNAME elb097307-934924932.us-east-1.elb.amazonaws.com. (208) 22:08:31.347163 IP 10.19.48.1.58938 > 23.23.102.58.80: Flags [S], seq 2827323425, win 25600, options [mss 1280,sackOK,TS val 2662267189 ecr 0,nop,wscale 6], length 0 22:08:32.658362 IP 10.19.48.1.58938 > 23.23.102.58.80: Flags [S], seq 2827323425, win 25600, options [mss 1280,sackOK,TS val 2662267447 ecr 0,nop,wscale 6], length 0 22:08:34.674350 IP 10.19.48.1.58938 > 23.23.102.58.80: Flags [S], seq 2827323425, win 25600, options [mss 1280,sackOK,TS val 2662267951 ecr 0,nop,wscale 6], length 0 22:08:38.802362 IP 10.19.48.1.58938 > 23.23.102.58.80: Flags [S], seq 2827323425, win 25600, options [mss 1280,sackOK,TS val 2662268983 ecr 0,nop,wscale 6], length 0 22:08:46.994360 IP 10.19.48.1.58938 > 23.23.102.58.80: Flags [S], seq 2827323425, win 25600, options [mss 1280,sackOK,TS val 2662271031 ecr 0,nop,wscale 6], length 0 22:08:56.274403 IP 52.17.240.124.4500 > 192.168.0.10.4500: isakmp-nat-keep-alive 22:09:03.122367 IP 10.19.48.1.58938 > 23.23.102.58.80: Flags [S], seq 2827323425, win 25600, options [mss 1280,sackOK,TS val 2662275063 ecr 0,nop,wscale 6], length 0 22:09:06.322373 IP 52.17.240.124.4500 > 192.168.0.10.4500: NONESP-encap: isakmp: child_sa inf2 22:09:06.322455 IP 192.168.0.10.4500 > 52.17.240.124.4500: NONESP-encap: isakmp: child_sa inf2[IR] 22:09:26.386407 IP 192.168.0.10.4500 > 52.17.240.124.4500: isakmp-nat-keep-alive 22:09:31.282360 IP 52.17.240.124.4500 > 192.168.0.10.4500: isakmp-nat-keep-alive ^C 21 packets captured 21 packets received by filter 0 packets dropped by kernel
iptables rules are pretty sparse:
root@nanopineo2:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination NFLOG udp -- anywhere anywhere multiport dports isakmp,ipsec-nat-t nflog-group 5 NFLOG ah -- anywhere anywhere nflog-group 5 NFLOG esp -- anywhere anywhere nflog-group 5 ACCEPT all -- anywhere nanopineo2 policy match dir in pol ipsec reqid 2 proto esp ACCEPT all -- anywhere 10.19.48.4 policy match dir in pol ipsec reqid 1 proto esp ACCEPT all -- anywhere 10.19.48.4 policy match dir in pol ipsec reqid 1 proto esp Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere nanopineo2 policy match dir in pol ipsec reqid 2 proto esp ACCEPT all -- nanopineo2 anywhere policy match dir out pol ipsec reqid 2 proto esp ACCEPT all -- anywhere 10.19.48.4 policy match dir in pol ipsec reqid 1 proto esp ACCEPT all -- 10.19.48.4 anywhere policy match dir out pol ipsec reqid 1 proto esp ACCEPT all -- anywhere 10.19.48.4 policy match dir in pol ipsec reqid 1 proto esp Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- nanopineo2 anywhere policy match dir out pol ipsec reqid 2 proto esp NFLOG udp -- anywhere anywhere multiport dports isakmp,ipsec-nat-t nflog-group 5 NFLOG ah -- anywhere anywhere nflog-group 5 NFLOG esp -- anywhere anywhere nflog-group 5
History
#1 Updated by Tobias Brunner over 8 years ago
- Status changed from New to Feedback
If stuff like ICMP (small packets) and DNS gets through the tunnel it's likely an MTU/MSS issue.
#2 Updated by Joe Lippa over 8 years ago
Hi Tobias, thank you yes that's what I thought this might be too. Early on I adjusted the mss via /etc/strongswan.d/charon/kernel-netlink.conf and set mss = 1280. This change has had some effect because I can see the mss applied in the strongswan 220 table added route:
root@nanopineo2:~# ip route show table 220 default via 192.168.0.1 dev eth0 proto static src 10.19.48.4 advmss 1280 192.168.0.0/24 dev eth0 proto static src 192.168.0.10 advmss 1280
But it's still not working. I've also had a play with iptables nat rules and my rules now look like this but again unfortunately no positive effect:
root@nanopineo2:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere nanopineo2 policy match dir in pol ipsec reqid 1 proto esp Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere nanopineo2 policy match dir in pol ipsec reqid 1 proto esp ACCEPT all -- nanopineo2 anywhere policy match dir out pol ipsec reqid 1 proto esp Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- nanopineo2 anywhere policy match dir out pol ipsec reqid 1 proto esp root@nanopineo2:~# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere policy match dir out pol ipsec ACCEPT all -- 10.19.48.0/24 anywhere policy match dir out pol ipsec MASQUERADE all -- 10.19.48.0/24 anywhere
I suppose the captured tcpdump does indicate that some traffic is getting through though.
I'm now wondering if this problem is somehow related to this device appearing in iptables as nanopineo2 rather than it's interface ip address. Do you think I have a more general networking configuration problem here?
#3 Updated by Joe Lippa over 8 years ago
The hostname shown in the iptables -L output was a red herring. This was caused simply the iptables client resolving ip addresses to hostnames and I've since learnt that this can be prevented / disabled with:
iptables -L -n
I've logged another tcpdump capture with an imcp ping in progress pinging to google.com which does successfully receive responses. I do think this proves that the tunnel is at least working for pings but I'd really appreciate it if someone can confirm this:
root@nanopineo2:~# tcpdump -s 0 -n -i nflog:5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on nflog:5, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes 09:27:10.541085 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 41, length 64 09:27:10.541289 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 41, length 64 09:27:10.541312 IP 192.168.0.10.4500 > 52.17.240.124.4500: UDP-encap: ESP(spi=0xc1280b45,seq=0x39), length 120 09:27:10.541433 IP 52.17.240.124.4500 > 192.168.0.10.4500: UDP-encap: ESP(spi=0xc43ec7bf,seq=0x31), length 120 09:27:10.541459 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 41, length 64 09:27:10.541482 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 41, length 64 09:27:10.541503 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 42, length 64 09:27:10.541523 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 42, length 64 09:27:10.541543 IP 192.168.0.10.4500 > 52.17.240.124.4500: UDP-encap: ESP(spi=0xc1280b45,seq=0x3a), length 120 09:27:10.541566 IP 52.17.240.124.4500 > 192.168.0.10.4500: UDP-encap: ESP(spi=0xc43ec7bf,seq=0x32), length 120 09:27:10.541590 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 42, length 64 09:27:10.541610 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 42, length 64 09:27:12.525045 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 43, length 64 09:27:12.525103 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 43, length 64 09:27:12.525126 IP 192.168.0.10.4500 > 52.17.240.124.4500: UDP-encap: ESP(spi=0xc1280b45,seq=0x3b), length 120 09:27:12.525158 IP 52.17.240.124.4500 > 192.168.0.10.4500: UDP-encap: ESP(spi=0xc43ec7bf,seq=0x33), length 120 09:27:12.525182 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 43, length 64 09:27:12.525203 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 43, length 64 09:27:12.525224 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 44, length 64 09:27:12.525244 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 44, length 64 09:27:12.525265 IP 192.168.0.10.4500 > 52.17.240.124.4500: UDP-encap: ESP(spi=0xc1280b45,seq=0x3c), length 120 09:27:13.549066 IP 52.17.240.124.4500 > 192.168.0.10.4500: UDP-encap: ESP(spi=0xc43ec7bf,seq=0x34), length 120 09:27:13.549123 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 44, length 64 09:27:13.549149 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 44, length 64 09:27:13.549170 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 45, length 64 09:27:13.549192 IP 10.19.48.4 > 216.58.198.78: ICMP echo request, id 2569, seq 45, length 64 09:27:13.549212 IP 192.168.0.10.4500 > 52.17.240.124.4500: UDP-encap: ESP(spi=0xc1280b45,seq=0x3d), length 120 09:27:13.549256 IP 52.17.240.124.4500 > 192.168.0.10.4500: UDP-encap: ESP(spi=0xc43ec7bf,seq=0x35), length 120 09:27:13.549290 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 45, length 64 09:27:13.549312 IP 216.58.198.78 > 10.19.48.4: ICMP echo reply, id 2569, seq 45, length 64 ^C 30 packets captured 30 packets received by filter 0 packets dropped by kernel
Interestingly and this might actually be closer to the problem, switching tcpdump into verbose mode does indicate checksum problems when performing a curl to google.com (mss is still set to 1280 via /etc/strongswan.d/charon/kernel-netlink.conf) - please see cksum 0xd70b (incorrect -> 0xa3c5):
root@nanopineo2:~# tcpdump -s 0 -n -i nflog:5 -vv
tcpdump: listening on nflog:5, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes
09:42:26.125083 IP (tos 0x0, ttl 64, id 28706, offset 0, flags [DF], proto UDP (17), length 56)
10.19.48.3.42398 > 172.16.0.1.53: [udp sum ok] 54862+ A? google.com. (28)
09:42:26.125383 IP (tos 0x0, ttl 64, id 25551, offset 0, flags [DF], proto UDP (17), length 120)
192.168.0.10.4500 > 52.17.240.124.4500: [no cksum] UDP-encap: ESP(spi=0xc08c3b4d,seq=0x1), length 92
09:42:26.125474 IP (tos 0x0, ttl 64, id 28707, offset 0, flags [DF], proto UDP (17), length 56)
10.19.48.3.42398 > 172.16.0.1.53: [udp sum ok] 61586+ AAAA? google.com. (28)
09:42:26.125528 IP (tos 0x0, ttl 64, id 25552, offset 0, flags [DF], proto UDP (17), length 120)
192.168.0.10.4500 > 52.17.240.124.4500: [no cksum] UDP-encap: ESP(spi=0xc08c3b4d,seq=0x2), length 92
09:42:26.125572 IP (tos 0x0, ttl 42, id 24881, offset 0, flags [DF], proto UDP (17), length 216)
52.17.240.124.4500 > 192.168.0.10.4500: [no cksum] UDP-encap: ESP(spi=0xc0ee8742,seq=0x1), length 188
09:42:26.125614 IP (tos 0x0, ttl 42, id 24882, offset 0, flags [DF], proto UDP (17), length 148)
52.17.240.124.4500 > 192.168.0.10.4500: [no cksum] UDP-encap: ESP(spi=0xc0ee8742,seq=0x2), length 120
09:42:26.125657 IP (tos 0x0, ttl 64, id 48780, offset 0, flags [DF], proto UDP (17), length 152)
172.16.0.1.53 > 10.19.48.3.42398: [udp sum ok] 54862 q: A? google.com. 6/0/0 google.com. A 209.85.203.113, google.com. A 209.85.203.138, google.com. A 209.85.203.139, google.com. A 209.85.203.100, google.com. A 209.85.203.101, google.com. A 209.85.203.102 (124)
09:42:26.125776 IP (tos 0x0, ttl 64, id 48781, offset 0, flags [DF], proto UDP (17), length 84)
172.16.0.1.53 > 10.19.48.3.42398: [udp sum ok] 61586 q: AAAA? google.com. 1/0/0 google.com. AAAA 2a00:1450:400b:c03::64 (56)
09:42:26.125850 IP (tos 0x0, ttl 64, id 31329, offset 0, flags [DF], proto TCP (6), length 60)
10.19.48.3.41896 > 209.85.203.113.80: Flags [S], cksum 0xd70b (incorrect -> 0xa3c5), seq 1747617283, win 25600, options [mss 1280,sackOK,TS val 4280932545 ecr 0,nop,wscale 6], length 0
09:42:27.181065 IP (tos 0x0, ttl 64, id 31330, offset 0, flags [DF], proto TCP (6), length 60)
10.19.48.3.41896 > 209.85.203.113.80: Flags [S], cksum 0xd70b (incorrect -> 0xa2c7), seq 1747617283, win 25600, options [mss 1280,sackOK,TS val 4280932799 ecr 0,nop,wscale 6], length 0
09:42:29.197064 IP (tos 0x0, ttl 64, id 31331, offset 0, flags [DF], proto TCP (6), length 60)
10.19.48.3.41896 > 209.85.203.113.80: Flags [S], cksum 0xd70b (incorrect -> 0xa0cf), seq 1747617283, win 25600, options [mss 1280,sackOK,TS val 4280933303 ecr 0,nop,wscale 6], length 0
09:42:33.453065 IP (tos 0x0, ttl 64, id 31332, offset 0, flags [DF], proto TCP (6), length 60)
10.19.48.3.41896 > 209.85.203.113.80: Flags [S], cksum 0xd70b (incorrect -> 0x9ca7), seq 1747617283, win 25600, options [mss 1280,sackOK,TS val 4280934367 ecr 0,nop,wscale 6], length 0
09:42:41.645067 IP (tos 0x0, ttl 64, id 31333, offset 0, flags [DF], proto TCP (6), length 60)
10.19.48.3.41896 > 209.85.203.113.80: Flags [S], cksum 0xd70b (incorrect -> 0x94a7), seq 1747617283, win 25600, options [mss 1280,sackOK,TS val 4280936415 ecr 0,nop,wscale 6], length 0
^C
13 packets captured
13 packets received by filter
0 packets dropped by kernel
So I might be getting closer to the cause of the problem now but I don't know what's causing these cksum fails. Thanks hugely for any further insights into what might be going on here!
#4 Updated by Joe Lippa over 8 years ago
- File curl-tunnel-capture.cap curl-tunnel-capture.cap added
Please find attached a tcpdump capture performed in highest verbose mode, captured whilst a "curl google.com" call was being performed down the tunnel (or at least I assume and hope this traffic was being routed down the tunnel).
It's interesting to view this wireshark and to follow stream from frame 15. The first thing to note is that there's no sign of any ACK at all in this dump which seems to indicate that the remote end just can't / is unable to talk to this side at all. Follow stream from frame 15 shows the initial SYN call followed by a number of retransmit SYN calls.
MSS was set to 1380 (as can be seen in the capture frames).
I'm struggling to understand this from a comms / routing perspective. Does this make sense to you at all? Thanks!
#5 Updated by Joe Lippa over 8 years ago
I've now also ran some tcpdump captures on the remote side. For the working box on this side that starts the tunnel to the remote, the capture contains everything you'd expect including DNS, ESP, SYN, SYN ACK handshakes and data frames. For the failing friendlyarm neo2 box there are some DNS and ESP frames but no sign of any SYN, SYN ACK or data frames. Even though the tunnel looks as though it was successfully established it seems a SYN packet never gets through.
Having visually compared the start SYN frames between the working box and the failing neo2 box, they do look very similar.
#6 Updated by Joe Lippa over 8 years ago
- File remote-ping-capture.cap remote-ping-capture.cap added
Please find attached another tcpdump capture from the remote VPN server side, captured whilst "ping google.com" and "ping bing.com" were performed from the challenged neo2 box. Clearly this works fine, traffic is travelling down the tunnel reaching the destination and travelling back to the neo2. ESP, DNS and ICMP frames are all there as they should be.
During all of these tcpdump tests I've not seen any packets reported as being dropped by the kernel and yet HTTP traffic appears to go missing when curl calls are performed from the neo2.
On the face of things, this should be working or at the very least should show some signs of traffic at the remote end when a curl call is in progress. Could this be a platform kernel bug?
#7 Updated by Noel Kuntze over 8 years ago
Pastebin iptables-save not iptables -L<something>, as it is written on the HelpRequests page. What kernel are you using? What is the output of ipsec statusall when the tunnel is up and the problem manifests.
#8 Updated by Joe Lippa over 8 years ago
Hi Noel thank you, here we go:
iptables-save output:
root@neo2:~# iptables-save # Generated by iptables-save v1.4.21 on Mon Jun 5 07:31:21 2017 *filter :INPUT ACCEPT [66:6401] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [42:4751] -A INPUT -d 10.19.48.2/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT -A FORWARD -d 10.19.48.2/32 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT -A FORWARD -s 10.19.48.2/32 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT -A OUTPUT -s 10.19.48.2/32 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT COMMIT # Completed on Mon Jun 5 07:31:21 2017
This is Debian running on the neo2 at the moment and uname -a reports the kernel as 4.11.2:
root@neo2:~# uname -a Linux neo2 4.11.2 #22 SMP Sat May 27 11:14:47 CST 2017 aarch64 GNU/Linux
Incidentally I did see this same issue on Armbian before switching to the FriendlyArm manufacturer supplied Debian image, which is what I'm testing with at the moment.
This is the output of ipsec statusall:
root@neo2:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.11.2, aarch64):
uptime: 8 minutes, since Jun 05 07:31:06 2017
malloc: sbrk 2596864, mmap 0, used 381264, free 2215600
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
loaded plugins: charon rc2 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl curve25519 agent xcbc cmac hmac attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-gtc eap-mschapv2 xauth-generic
Listening IP addresses:
192.168.0.10
Connections:
vpn: %any...52.17.240.124 IKEv2, dpddelay=35s
vpn: local: [CN=jess] uses public key authentication
vpn: cert: "CN=jess"
vpn: remote: [52.17.240.124] uses public key authentication
vpn: child: dynamic === 0.0.0.0/0 TUNNEL, dpdaction=clear
bypass: 127.0.0.1...127.0.0.1 IKEv1/2
bypass: local: [127.0.0.1] uses public key authentication
bypass: remote: [127.0.0.1] uses public key authentication
bypass: child: 192.168.0.0/24 === 192.168.0.0/24 PASS
Shunted Connections:
bypass: 192.168.0.0/24 === 192.168.0.0/24 PASS
Security Associations (1 up, 0 connecting):
vpn[1]: ESTABLISHED 8 minutes ago, 192.168.0.10[CN=jess]...52.17.240.124[52.17.240.124]
vpn[1]: IKEv2 SPIs: 6f6b7a6e1eb29df8_i* 35e36d53a2f3469e_r, rekeying disabled
vpn[1]: IKE proposal: AES_GCM_16_128/PRF_HMAC_SHA2_512/ECP_256
vpn{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cf6a43f6_i c4c3222c_o
vpn{1}: AES_GCM_16_128, 3419 bytes_i (44 pkts, 32s ago), 3415 bytes_o (46 pkts, 32s ago), rekeying disabled
vpn{1}: 10.19.48.2/32 === 0.0.0.0/0
Many thanks
Joe
#9 Updated by Noel Kuntze over 8 years ago
- Category set to kernel
Joe Lippa wrote:
This is Debian running on the neo2 at the moment and
uname -areports the kernel as 4.11.2:[...]
Incidentally I did see this same issue on Armbian before switching to the FriendlyArm manufacturer supplied Debian image, which is what I'm testing with at the moment.
This is the output of
ipsec statusall:[...]
Many thanks
Joe
#10 Updated by Joe Lippa over 8 years ago
Hi Noel, thanks hugely for finding this. This explains why this doesn't work on both Armbian and FriendlyArm Debian, both are 4.11 at the moment.
I'll report back to both. Thanks again, I'm not sure how you became aware of this, perhaps it's just that you're working in this area and are acutely aware of breaking issues like this.
Anyway I can't thank you enough.
Cheers,
Joe
#11 Updated by Noel Kuntze over 8 years ago
- Assignee set to Noel Kuntze
I'll report back to both. Thanks again, I'm not sure how you became aware of this, perhaps it's just that you're working in this area and are acutely aware of breaking issues like this.
It came up on the libreswan ml or the IRC channel a couple of days ago and remembered it.
#12 Updated by Joe Lippa over 8 years ago
I've patched Armbian with something that is very close to Steffen Klassert's patch which is aligned with the arm flavour of /sources/linux-sun50i-dev/sunxi64-4.11.y/net/ipv4/esp4.c and I can confirm that this now works. Happy days.
Many thanks again,
Joe
#13 Updated by Tobias Brunner over 7 years ago
- Status changed from Feedback to Closed
- Resolution set to No change required