• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

FreeBSD 8.1 - Can't get IPv6 traffic through PPTP Tunnel

Started by theultramage, September 01, 2010, 05:23:39 AM

Previous topic - Next topic

theultramage

HE.net offers point to point tunnels with public static ipv4 endpoints, and even suggests on the news page that these endpoints can be used to establish ipv6 tunnels. However, there are no instructions how to accomplish this... but I've decided to try anyway.

First thing was to establish a PPTP tunnel using mpd5. This went well, and I got a new interface called ng0.
Since my machine was now multihomed, I added the pf rule "pass in quick on ng0 reply-to ng0 all keep state".
Then I took the instructions from the tunnel page and entered them. This created another interface, gif0, and defined an ipv4 tunnel from my pptp endpoint to the ipv6 tunnel server, and an ipv6 tunnel.

My remaining problem is that all ipv6 packets sent go through my physical network interface rl0, instead of the virtual ng0 tunnel. Even worse, it actually spoofs the sender address. I don't know how to correct this issue and I've been trying for hours. If I just add a route to the gif0 endpoint through the ng0 endpoint, the entire ng0 tunnel breaks down. Not sure why either. It could be that the pf rule is actually interfering.

cholzhauer

Quote
It could be that the pf rule is actually interfering.

Why not remove all of the firewall rules (or comment them out) and see if things work?

Quote
Then I took the instructions from the tunnel page and entered them. This created another interface, gif0, and defined an ipv4 tunnel from my pptp endpoint to the ipv6 tunnel server, and an ipv6 tunnel.

Let me preface this by saying I've never tried PPTP either, but, I'm not sure you needed to do that.

Have you looked through the forums?  I don't know if someone posted directions for the PPTP stuff or not.

theultramage

Quote from: cholzhauer on September 01, 2010, 05:30:31 AMWhy not remove all of the firewall rules (or comment them out) and see if things work?
Because then I also remove the reply-to rule and replies to packets on ng0 will suddenly start going through rl0 instead, causing loss of connectivity :)
And I already tried an "allow all" setup, and all I got was the same deal going on with gif0 and rl0. Maybe I need to find a way to write a reply-to rule for the gif0 tunnel?

Quote from: cholzhauer on September 01, 2010, 05:30:31 AMHave you looked through the forums?  I don't know if someone posted directions for the PPTP stuff or not.
I took a quick peek, but all posts so far have been very hard to read and understand; people posting their entire unfiltered configs and such. I could not find anything directly relevant to me. One other topic is about Mac OSX, and there the solution was to check a GUI checkbox - not really an option for me.

cholzhauer

Let me see if I understand correctly...your problem is that your IPv6 traffic is passing through the rl0 instead of ng0?

What is your default route set to?


theultramage

The default route is through the physical rl0 interface, of course.

I've also discovered that the tunnel interface ng0 itself does not operate properly because of this - I am unable to initiate a send through it, no matter how I try. Also FreeBSD does not allow multiple default routes; thus if I attempt to do a send with ng0's source address, it will still go through rl0, creating a malformed spoofed packet (which will then get NATed).

I can say that this is driving me nuts :) ... any tips?

cholzhauer


theultramage

Because then the underlying physical route would go away; plus I'd prefer not to pipe all traffic through he.net's servers.

I concluded that the fault is in pf. So I went back to ipfw with a custom kernel to support forwarding, added a 'forward' rule from my local pptp IP to the remote pptp server, and voila, it works! Now I have the ipv4 tunnel working in both directions like it should be.

The remaining issue is how to layer ipv6 on top of it. I installed gif0 according to the standard instructions. However, now I'm in a state where according to tcpdump, ping6 packets go to where they should, and get a reply back along the same path, but the replies never get delivered to the application... seems that something's eating them, but even switching to a fully permissive firewall didn't solve it.

theultramage

More specifically, tcpdump on ng0 (the pptp tunnel) says:
01:34:24.201017 IP 184.104.106.248 > 216.66.80.30: IP6 2001:470:1f0a:408::2 > 2001:470:1f0a:408::1: ICMP6, echo request, seq 0, length 16
01:34:24.217317 IP 216.66.80.30 > 184.104.106.248: IP6 2001:470:1f0a:408::1 > 2001:470:1f0a:408::2: ICMP6, echo reply, seq 0, length 16

However, on gif0 (the ipv6 tunnel layered on top of ng0) says:
01:35:19.182416 IP6 2001:470:1f0a:408::2 > 2001:470:1f0a:408::1: ICMP6, echo request, seq 0, length 16

This implies that the reply did arrive but the network stack did not handle it correctly all the way.

doneill

you don't need a second or replacement default route, simply a specific route for packets destined to your tunnel broker to go via the pptp interface.

that said, such a setup has some dire and nasty consequences on linux for reasons beyond my understanding, and requires a SECOND routing table to be established, whereby packets destined to the tunnel broker are instead passed through this second table which has a default route which goes via the pptp tunnel.

it all really is a PITA. :)

jimb

Yep.  Unfortunately you need to use policy routing to make it work 'cause the PPTP and 6in4 tunnels share the same IPv4.  I've never done it on BSD, so I dunno how.