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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
