On 18/08/2018 3:25 am, Paul Wouters wrote:
On Sat, 18 Aug 2018, Reuben Farrelly wrote:
I'm now testing with another router running classic IOS (not-XE) and
it is also seeing some problems establishing an IPSec session. This
router is running the latest released version of classic IOS (15.8(3)M).
The IOS XE router won't connect to any versions at all.
I've posted the debugs for both classic IOS sessions up online for
comparison:
http://www.reub.net/files/libreswan/Libreswan-3.22-working.txt
and
http://www.reub.net/files/libreswan/Libreswan-3.25-NOT-working.txt
The non-working one and the working one both setup an IPsec SA for 0/0
to 0/0 according to the logs using the same IKE and ESP parameters.
The non-working one immediately receives an additional INFORMATIONAL
exchange message with a ISAKMP_NEXT_v2CP Configuration Payload as
defined in https://tools.ietf.org/html/rfc7296#section-3.15
It seems the Informational exchange can contain a CP payload, although
we surely aren't expecting this to happen:
https://tools.ietf.org/html/rfc7296#section-1.4
So we treat the informational as a DPD type and just reply with an
empty informational exchange packet. Then we receive another
informational but now a real empty one, so a real DPD one and we
reply. All seems well. Nothing in the logs you post indicate a problem,
or show that the tunnel is "not working".
It's definitely not working with 3.25 but always works with the 3.22,
and is 100% reproducible.
My test case is a single /30 between the router and Libreswan, and I'm
attempting to ping across it. In other words no routing required as the
two ends are on the same IP subnet.
Configs:
conn router-2.reub.net-ipv4
left=110.232.112.209
[email protected]
leftsubnet=0.0.0.0/0
right=%any
[email protected]
rightsubnet=0.0.0.0/0
authby=secret
ikev2=insist
ikelifetime=86400s
salifetime=3600s
# IOS XE
#ike=aes-sha2_512;dh19
# Classic IOS
ike=aes-sha2_512;dh5
dpddelay=15
dpdtimeout=45
dpdaction=clear
auto=add
mark=-1/0xffffffff
vti-interface=vti-1
leftvti=192.168.6.1/30
Cisco:
interface Tunnel1
description Libreswan site-to-site IKEv2 VPN
bandwidth 256
ip address 192.168.6.2 255.255.255.252
ip mtu 1294
ip nat outside
ip virtual-reassembly in
ip tcp adjust-mss 1378
tunnel source GigabitEthernet0
tunnel mode ipsec ipv4
tunnel destination 110.232.112.209
tunnel path-mtu-discovery
tunnel protection ipsec profile reub-ipsec-profile
end
crypto ikev2 profile reub-ikev2-profile
match identity remote any
identity local email [email protected]
authentication remote pre-share
authentication local pre-share
keyring local reub-keyring
dpd 15 2 periodic
nat keepalive 30
aaa authorization group psk list default reub-ikev2-authorization
[No change to the Cisco config at any stage with either head end version]
Now I know that while this isn't the subject of the original problem,
I think we should get to the bottom of this first, just in case the
root causes happen to be related. The debugs look a little similar in
all cases where things go wrong in that we have retransmits that don't
seem to make much sense.
Do you know what happened on the Cisco end? What error did it log?
Nothing in terms of errors, aside from debugging. The Cisco seems to be
all happy with the connection in both cases, and the Tunnel interface
comes up on the Cisco indicating it thinks everything has negotiated fine.
Maybe the IPsec SA was up, but somehow you didnt add the proper VTI
routes?
Routing looks to be OK on both sides according to the routing table.
What I have noticed is that with 3.25, each packet that comes in is
logged as an error on the vti-1 interface:
vti-1: ip/ip remote any local 110.232.112.209 ttl inherit key 1001
RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts
20 2403 53 0 0 0
TX: Packets Bytes Errors DeadLoop NoRoute NoBufs
17 1668 16 0 16 0
<5 ping packets later>
vti-1: ip/ip remote any local 110.232.112.209 ttl inherit key 1001
RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts
20 2403 58 0 0 0
TX: Packets Bytes Errors DeadLoop NoRoute NoBufs
17 1668 16 0 16 0
===> Errors have gone from 53 to 58.
This is consistent with the Cisco counters which show for each ping, a
packet is sent out but nothing is received.
With 3.25 on the Libreswan device (a Gentoo box) we have a valid route:
192.168.6.0/30 dev vti-1 proto kernel scope link src 192.168.6.1
But attempting to ping results in:
lightning /usr/portage/net-vpn/libreswan # ping 192.168.6.2
PING 192.168.6.2 (192.168.6.2) 56(84) bytes of data.
From 192.168.6.1 icmp_seq=1 Destination Host Unreachable
From 192.168.6.1 icmp_seq=2 Destination Host Unreachable
The NoRoute counts go up as well even though there is a valid route:
lightning /usr/portage/net-vpn/libreswan # ip route
default via 110.232.112.1 dev eth0 metric 2
110.232.112.0/24 dev eth0 proto kernel scope link src 110.232.112.209
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.6.0/30 dev vti-1 proto kernel scope link src 192.168.6.1
lightning /usr/portage/net-vpn/libreswan #
Running tcpdump on the vti-1 interface there is no output captured but
if I run it on the outside interface I can see the ESP packets coming in
(one per ping). So we know the traffic is definitely being sent to, and
received by the Libreswan box (again, one packet received per ping packet).
It looks like something changed between 3.22 and 3.25 with VTI that has
caused this, but aside from the errors I can't see anything else amiss.
I've compared the output of ipsec status with both working and
non-working cases and can not find anything different either.
Everything looks the same with the Cisco between the two different
versions too.
Reuben
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
