|
IPv6 over IPv4 IPSec via 6in4
![[us]](/s/countries/us.gif) Shadow Hawkins on Tuesday, 26 July 2011 00:09:48
Centos 5.6 doesn't support IPv6 IPSec via network-scripts. So I thought I had a nifty solution: I already have IPv4 IPSec configured between the two nodes, so I simply added an IPv6 route to send the subnet to the private IPv4 IP.
IPv4 IPSec connects 192.168.1.0/24 to 192.168.2.0/24 via public IPs 1.2.3.4 and 1.3.5.7. IP6 connectivity takes place via 6in4 interface sit0.
on 192.168.1.1/1.2.3.4/2001:db8:1::1:
route -A inet6 add 2001:db8:2::/48 gw ::192.168.2.1
resulting gateway device is sit0 as expected. I would expect packets to 2001:db8:2:: to be sent to IP4 ip 192.168.2.1 via IPSec
on 192.168.2.1/1.3.5.7:
route -A inet6 add 2001:db8:1::/48 gw ::192.168.1.1
ping of the private Ipv4 IPs results in ESP/AH packets over public interface as expected. ping6 works, but the packets are sent unencrypted to the public IP! Somehow it bypasses IPsec and translates 192.168.2.1 to 1.3.5.7. Why is that?
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Tuesday, 26 July 2011 00:13:25
I forgot to note that it does *not* send the packets to the default IP6 gateway - it sends them directly to the other nodes public IP4. So the IP6 route *is* having an effect. It just bypasses IPSec for some reason. I'm guessing that the IPv4 IPSec refuses to handle the 6in4 packets for some reason.
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Tuesday, 26 July 2011 05:18:49
Ok, got this to work. Once again, 6to4 was biting me. Only 6to4 IPv6 IPs bypass IPSec - they seem to be grabbed earlier in the stack. (Go ahead and castigate me for using documentation IPs in the example instead of real IPs - blithely forgetting all the special quirks of 6to4).
Assigning any other IPv6 subnet works - so this is a viable way to use IPv6 over IPSec when your system only supports IPv4 IPSec. I ended up assigning a /64 subnet from my sixxs.net tunnel.
Note, the ping uses the IPv6 assigned to your sit interface as the source IP by default - so you can easily end up with encryption only one direction if you reuse your 6to4 interface for the VPN.
IPv6 over IPv4 IPSec via 6in4
Hmm, I am a bit surprised that 6to4 would be treated specially as it is on the outbound path just like proto-41 is.
What you might want to do though is start using the 'ip' command (thus 'ip tunnel add...') instead of using sit0, as that method is very very old, and that is maybe causes a the issue you are running into.
Btw, documentation prefix for IPv4 is 192.0.2.0/24 ;)
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Tuesday, 26 July 2011 16:17:30
If you'll forgive me for waxing all expert after only a few weeks experience, I think the issue is routing. The 6to4 IPs have routing special cases, which basically say "send me directly to the public IP I encode ignoring IPv6 routing". So the 6in4 packets are sent directly to the public IP, rather than the private IP in the IPv6 routing table.
IPv6 over IPv4 IPSec via 6in4
I think the issue is routing
The routing in both the Linux and FreeBSD kernels and a few others I have seen all handle 6to4 in the kernel in a similar way:
- destination address is looked up in the routing table
- the device that the packet needs to go to, along with a gateway, is figured out from this
- at this point the packet is handed to either a ethernet interface, tun/tap, or the special sit0 interface
Assuming the 6to4 destination packet thus a routing entry looking like: "2002::/16 dev sit0"
- the sit0 device sees 'hey it is 6to4' as the destination is in 2002::/16
- Grabs the IPv4 address out of it, encapsulates the IPv6 packet inside IPv4, setting the src/dst IPv4 addresses and sends it out
Assuming native IPv6 over ethernet:
- the eth0 device forwards the packet to the gateway given in in the route
As such IPv6 routing comes FIRST, the encapsulation is done because it is send to that device.
You can easily verify this by accidentally doing: "ip -6 ro add 2002::/17 dev eth0; ip -6 ro add 2002:8000::/17 dev eth0" then all packets end up on eth0 untouched.
So the 6in4 packets are sent directly to the public IP, rather than the private IP in the IPv6 routing table.
I think you are mixing something up heavily:
6to4 is for addresses in 2002::/16.
6in4 or "proto-41" is IPv6-in-IPv4.
Your configuration with the routes over ::<ipv4> notation are strange, to say the least and old. Change them to 'ip -6 ro add <prefix> <gateway>" and then look at the output of "ip -6 ro sho" to see what you actually are getting out of it. (Configuration commands don't always match the configuration that is in place).
Unless using the special sit0 device, which configuration is deprecated you need to make explicit tunnels to IPv4 endpoints if you want to route over them, as such, try:
on 192.168.1.1:
ip tunnel add tunnel_to_two local 192.168.1.1 remote 192.168.2.1 mode sit
ip -6 addr add 2001:db8::1/64 dev tunnel_to_two
ip -6 ro add 2001:db8:2::/48 2001:db8::2 dev tunnel_to_two
on 192.168.2.1:
ip tunnel add tunnel_to_one local 192.168.2.1 remote 192.168.1.1 mode sit
ip -6 addr add 2001:db8::2/64 dev tunnel_to_one
ip -6 ro add 2001:db8:1::/48 2001:db8::1 dev tunnel_to_one
Note that I introduced a 2001:db8::/64 for a tunnel between the hosts to connect to each other
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Thursday, 28 July 2011 18:06:23
The 6to4 tunnel was already created using ip commands as above. I renamed it to tun6to4, but that doesn't change anything. It is necessary to create an additional tunnel to funnel the IPv6 subnet over an IPv4 IPSec.
For those using RedHat/Centos/Fedora:
ifcfg-eth1:
-----------
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=dhcp
HWADDR=00:01:02:03:04:05
TYPE=Ethernet
PEERDNS=no
IPV6FORWARDING=yes
IPV6TO4INIT=yes
IPV6INIT=yes
ifcfg-sit1:
-----------
IPV6TUNNELIPV4=192.168.2.1
IPV6TUNNELIPV4LOCAL=192.168.1.1
IPV6ADDR=2002:c000:0201:8888::1/128
ifcfg-ipsec0:
-------------
ONBOOT=yes
IKE_METHOD=PSK
DSTGW=192.168.2.1
SRCGW=192.168.1.1
DSTNET=192.168.2.0/24
SRCNET=192.168.1.0/24
DST=192.0.2.129
TYPE=IPSEC
IPv6 over IPv4 IPSec via 6in4
Why are you bothering with 6to4? And please note that 6to4 can't work for RFC1918 addresses. (Well, it will work, but it is quite futile) Also note that 6to4 is on the track of being deprecated by the IETF for various reasons.
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Thursday, 28 July 2011 18:30:59
This thread is about 6in4 tunnels over IPv4 IPSec. It doesn't matter whether you are using 6to4 or a (sixxs or other provider) 6in4 tunnel for IP6 access - the config for the 6in4 tunnel over IPv4 IPSec is the same. Attempting to reuse the sixxs 6in4 tunnel for the IPSec route, for instance, will also fail for a different reason. You need an additional 6in4 tunnel for each IPSec tunnel you wish to route IP6 traffic over.
IPv6 over IPv4 IPSec via 6in4
It doesn't matter whether you are using 6to4 or a (sixxs or other provider) 6in4 tunnel for IP6 access - the config for the 6in4 tunnel over IPv4 IPSec is the same
Actually it matters a lot as 6to4 per design does not carry any packets not destined to a 6to4 address on the IPv6 layer. Your configurations that you are showing above are thus then also obviously wrong.
Attempting to reuse the sixxs 6in4 tunnel for the IPSec route, for instance, will also fail for a different reason.
Primarily because IPSec is not supported on the SixXS PoP side.
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Thursday, 28 July 2011 21:31:57
You missed the part where it is *IPv4* IPSec. The configurations are correct, and work beautifully. Since packets are going over IPv4 IPSec, the kind of tunnel used for global IPv6 connectivity doesn't matter. Please note, this is *not* the global IPv6 connection - just a VPN connection between two IPv6 (and IPv4) subnets.
There is no real point in the SixXS PoP supporting IPSec, because your packets are unprotected once they get out in the wild anyway.
Why not use IPv6 IPSec?
1) it doesn't seem to work in RedHat/Centos 5.6. (The main reason for me :-) )
2) If you have to use 6in4 or 6to4 for IPv6 anyway, then there is no extra overhead sending your 6in4 tunnel over IPv4 IPSec - and you get dual stack VPN for "free" without having to maintain an additional tunnel.
Once native IPv6 is available, then the need for working IPv6 IPSec becomes more acute.
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Thursday, 28 July 2011 21:39:17
I should mention that you need a static route:
ip route add 2002:c000:0281::/48 dev sit1
And, of course, ignore the 6TO4 eth1 config if you have a sixxs tunnel and subnet instead. I just included it to emphasize that you need an *additional* 6in4 link.
I also didn't include the PSK - on RedHat/Centos, that goes in keys-ipsec0.
IPv6 over IPv4 IPSec via 6in4
Shadow Hawkins on Thursday, 28 July 2011 23:07:21
ifcfg-sit1 should also specify MTU:
IPV6_MTU=1384
1384 is 1500 (Ether) - IPv4 IPSec - 6in4
tracepath6 can determine the MTU for a path experimentally.
|
![[ch]](/s/countries/ch.gif)
on Tuesday, 26 July 2011 09:57:07
Posting is only allowed when you are