[Swan-dev] [Swan] Cisco IOS IPv6 Transport with IKEv2 to Libreswan
Reuben Farrelly
reuben-libreswan at reub.net
Sat Jun 30 09:02:15 UTC 2018
Hi again,
I didn't receive any response to my last email and I've been looking
again at this today, still with no luck...but I have more ideas:
On 13/06/2018 10:14 pm, Reuben Farrelly wrote:
> On 13/06/2018 7:49 am, Paul Wouters wrote:
>>> Is there any way to support both families concurrently (a type of
>>> autodetect)
>>
>> Not yet. You will have to define a v4 and a v6 conn.
>
> Ok - that's fine. That works (but for anyone else who tries this as I
> did - just remember you need to have a different conn name for each one
> even if the policies are otherwise almost identical, otherwise Libreswan
> starts normally but only applies one of the two conns)
>
> I have copied my original and appended it with -ipv4 and the new one
> with -ipv6. The only difference aside from the conn name is the left=
> and right= parameters.
>
>>> But back to this connection, it's now progressing a lot further - but
>>> not quite completing still and data is still not flowing:
>>
>> The below only shows liveness. So that assumes the connection
>> established? So can you show "ip xfrm pol" and "ip xfrm state" and
>> "ipsec status |grep router-2.reub.net"
>
> It looks more or less OK but there's still no data flow. I still cannot
> ping IPv4 between the two devices over IPv6.
>
> Just to recap - this is what I have on the Cisco side:
>
> interface Tunnel1
> <snip>
> tunnel mode ipsec ipv6 v4-overlay
> tunnel destination 2400:8901::F03C:91FF:FE6E:9DC
> end
>
> The router is an 819 with IOS 15.7(3)M2, which is the latest release for
> this platform.
>
> Do the mark or any other values of the two separate conn's need to be
> different even if only one is used at a time?
>
> Here are the outputs requested above:
>
> lightning /etc/ipsec.d # ip xfrm pol
> src 0.0.0.0/0 dst 0.0.0.0/0
> dir out priority 1048575
> mark 0xc/0xffffff
> tmpl src 2400:8901::f03c:91ff:fe6e:9dc dst
> 2001:8004:1400:20c9:1863:feff:fea4:d208
> proto esp reqid 16397 mode tunnel
> src 0.0.0.0/0 dst 0.0.0.0/0
> dir fwd priority 1048575
> mark 0xc/0xffffff
> tmpl src 2001:8004:1400:20c9:1863:feff:fea4:d208 dst
> 2400:8901::f03c:91ff:fe6e:9dc
> proto esp reqid 16397 mode tunnel
> src 0.0.0.0/0 dst 0.0.0.0/0
> dir in priority 1048575
> mark 0xc/0xffffff
> tmpl src 2001:8004:1400:20c9:1863:feff:fea4:d208 dst
> 2400:8901::f03c:91ff:fe6e:9dc
> proto esp reqid 16397 mode tunnel
> src ::/0 dst ::/0
> socket out priority 0
> src ::/0 dst ::/0
> socket in priority 0
> src ::/0 dst ::/0
> socket out priority 0
> src ::/0 dst ::/0
> socket in priority 0
> src ::/0 dst ::/0
> socket out priority 0
> src ::/0 dst ::/0
> socket in priority 0
> src ::/0 dst ::/0
> socket out priority 0
> src ::/0 dst ::/0
> socket in priority 0
> src ::/0 dst ::/0
> socket out priority 0
> src ::/0 dst ::/0
> socket in priority 0
> src ::/0 dst ::/0
> socket out priority 0
> src ::/0 dst ::/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket out priority 0
> src 0.0.0.0/0 dst 0.0.0.0/0
> socket in priority 0
> src ::/0 dst ::/0 proto ipv6-icmp type 135
> dir out priority 1
> src ::/0 dst ::/0 proto ipv6-icmp type 135
> dir fwd priority 1
> src ::/0 dst ::/0 proto ipv6-icmp type 135
> dir in priority 1
> src ::/0 dst ::/0 proto ipv6-icmp type 136
> dir out priority 1
> src ::/0 dst ::/0 proto ipv6-icmp type 136
> dir fwd priority 1
> src ::/0 dst ::/0 proto ipv6-icmp type 136
> dir in priority 1
> lightning /etc/ipsec.d #
>
> lightning /etc/ipsec.d # ip xfrm state
> src 2001:8004:1400:20c9:1863:feff:fea4:d208 dst
> 2400:8901::f03c:91ff:fe6e:9dc
> proto esp spi 0x1d6f43e9 reqid 16397 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha1)
> 0x56130393b7b349ff0c61ee45a0ed58dc1db52b3a 96
> enc cbc(aes) 0x909d165e146fcd52272a4946a3bea41d
> anti-replay context: seq 0x12, oseq 0x0, bitmap 0x0003ffff
> src 2400:8901::f03c:91ff:fe6e:9dc dst
> 2001:8004:1400:20c9:1863:feff:fea4:d208
> proto esp spi 0x2867ffcc reqid 16397 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha1)
> 0xb8aba431f6d67229bca8fb3d66fca8edeb7f8f8f 96
> enc cbc(aes) 0xb406eb113427edb19abcc0c752dbc1d1
> anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
> lightning /etc/ipsec.d #
The outputs as of today are still the same. I have moved to another VPS
which changes the IPv6 addresses above but the configs otherwise remain
almost the same. I had to enable narrowing, but the negotiation seems
to be OK.
Question: I am not seeing a VTI come up at all when I use IPv6
transport. Has this sort of configuration been tested before with IPv6?
Unlike the working IPv4 case, no vti is being created for IPv6 and
there are no IPv4 (connected) routes in the routing table.
_updown.netkey seems very IPv4 centric too.
The Cisco thinks everything is up and running just fine, and it
transmits packets over the tunnel, but never receives a response.
I also don't know what the kernel requirements are in terms of IPv6 and
kernel/interface modules either (perhaps these could be added to the
documentation for those not using Fedora/RHEL/Centos?)
I'm obviously breaking new ground here, I can't find any reference to
someone trying to do this before. However it doesn't seem to me to be a
far fetched scenario....?
Thanks,
Reuben
More information about the Swan-dev
mailing list