1

I have a problem about tun interfaces and the IPv6 handling by the kernel.

I'm trying to provide IPv6 to the end-users of my network over a pure IPv4 network. Summarizing (just a tunneling background theory) all the IPv6 packets are put into IPv4 packets and send through the tunnel and when go out this IPv4 header is removed and deliver to the system.

The scenario where I'm simulating all this is as follows:

  • I have only one machine, with two IPv4 virtual interfaces, used to send tunneled traffic between both. Let's call them "if4a" and "if4b". These interfaces are children of the management interface.
  • This machine, also has two IPv6 tun interfaces, used to mask the end-users IPv6 addresses. Let's call them "if6a" and "if6b". Each tun interface has attached a handmade program to put/remove the headers I need (GTP) before write/read the packets to/from tunnel (if4a with fd00:fea:2001::1 address and if4b with fd00:fea:2002::1 address).
  • I have two IPv6 addresses not defined anywhere, the end-users addresses in fact (fd00:cafe:2001::1 represents an user of if6a and fd00:cafe:2002::1 an user of if6b network).
  • The routing table is configured to send the end-users traffic to the "if6a" or "if6b" (tun interfaces).
  • There is a NAT configuration which changes the "fea" IPv6 addresses by "cafe" addresses to avoid the packets are delivered to destionation if6x interfaces directly and force the IPv6 traffic through the tun interfaces and therefore my GTP handling programs.

The issue is:

  • I send a ICMPv6 from fd00:fea:2001::1 to fd00:cafe:2002::1 through if6a.
  • NAT postrouting chain changes the source address by fd00:cafe:2001::1
  • The program listening on if6a read the ICMPv6, add GTP headers and send it to if4b (using IPv4)
  • The encapsulated IPv6 packet into GTP has these addresses: from fd00:cafe:2001::1 to fd00:cafe:2002::1
  • The server receives the packet, removes the GTP header and injects it (IPv6 packet) on the if6b interface.
  • Here is where tshark sniffs the packet and print the trace
  • NAT prerouting chain changes the destination address by fd00:fea:2002::1 and goes up the stack IP.
  • The packet is dropped because goes up the IPv4 stack instead IPv6 stack.

Some traces:

  • tshark:

 

[root@vm062 ~]# tshark -i if6b`
 Running as user "root" and group "root". This could be dangerous
 Capturing on 'if6b'
 1   0.000000 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104 Echo
 (ping) request id=0x7383, seq=1, hop limit=0
 1   2   0.785373 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=2, hop limit=0
 2   3   1.782000 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=3, hop limit=0
 3   4   2.781968 fd00:cafe:2001::1 -> fd00:cafe:2002::1 ICMPv6 104
 Echo (ping) request id=0x7383, seq=4, hop limit=0...
  • Dropped packets, as dropwatch shows:

 

 [ipv6test@vm062 ssh]$ echo start | dropwatch -l kas
 Initalizing kallsyms db
 dropwatch> start
 Enabling monitoring...
 Kernel monitoring activated.
 Issue Ctrl-C to stop monitoring
 1 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 1 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 2 drops at ip_rcv+c0 (0xffffffff81536450)
 ...

If I stop the ping6 the drops stop too.

I have been researching about the ip_rcv function and only works for IPv4 packets, so I suppose my IPv6 packets is entering through the IPv4 stack instead IPv6 stack. Why is the kernel doing that?

There is a similar question here.

  • Why don't you just use protocol 41? There is no need for you to write any programs to make a tunnel. – Michael Hampton Apr 5 '18 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.