Print

[eonesixfour]

Gah, I meant if you can ping 172.31.255.1, then it's up.  I think it's too early in the morning.

I can't which is why I was hoping someone would give a working linux pptp config.

[claas]

Remember, this is beta.  

Right, and we help you to test it

Does anyone have a working pptp config for linux (or even better for debian) they can paste?

The reason I ask is the pptp tunnel is up and passing packets back and forth, but on the tunnel page it always reports the tunnel is down.

The pptp tunnel itself works, here is how I did this using Ubuntu Linux (should work with debian the same way):

Code: [Select]

apt-get install pptp-linux binutils
pptpsetup --create tunnelbroker --server tserv6.fra1.ipv6.he.net --username 'USER%99999' --password foobar99999
 # --encrypt does not work yet
pon tunnelbroker

The tunnel appears as interface 'ppp1' here, since ppp0 is already taken from my internet uplink.

Optional: Adjust firewalling. I am using shorewall and shorewall6.

Code: [Select]

/etc/shorewall/interfaces
net     ppp0            -
net     ppp1            -       # <-------- this line had to be added
loc     eth0            detect          tcpflags,nosmurfs,routefilter,logmartians

/etc/shorewall/tunnels
pptpclient              net     216.66.80.30    # tserv6.fra1.ipv6.he.net

/etc/shorewall/shorewall.conf
DISABLE_IPV6=No        # could also work with =Yes, please try afterwards.

That's it for the PPTP part. You can enable the tunnel with "pon tunnelbroker", disable it with "poff tunnelbroker" and read the logs by "plog".

You can put the defaultroute on the tunnel, if you set a direct route to your PPTP tunnel endpoint.

The local PPTP tunnel endpoint is not yet autoconfigured. Therefore you need to place two scripts in /etc/ppp/ip-{up,down}.d/ in order to configure your IPv6 tunnel.
But this only works if the PPTP tunnel endpoint and the IPv6-Tunnel-server-endpoint-IPv4 are not the same!

I got it running! The trick is to use two different tunnels, the PPTP tunnel to Frankfurt and the IPv6-Tunnel to Amsterdam for example.

My setup continues like this:

Code: [Select]

/etc/ppp/ip-up.d/he-ipv6-tunnel
#!/bin/sh

if [ $PPP_IPPARAM != 'tunnelbroker' ]; then
        # echo "This script shall only be used for the tunnelbroker PPTP tunnel!"
        exit;
fi

# ---------- change the IPv4 tunnel endpoint to the IP of the local PPTP IPv4 adress ----------
USERID="b74fb74fb74fb74fb74fb74fb74fb74fb74f"       # your UserID (not your account name!)
MD5PASS="abcdabcdabcdabcdabcdabcdabcdabcd"      # your password as MD5, create with: echo -n 'yourpassword' | md5sum
GTUNID="99999"  # your global tunnel ID
/usr/bin/wget --no-check-certificate -q -O - https://ipv4.tunnelbroker.net/ipv4_end.php\?ipv4b=$IPLOCAL\&pass=$MD5PASS\&user_id=$USERID\&tunnel_id=$GTUNID
# for debugging purposes, you may add: >> /tmp/debug-he-ipv6-tunnel
# if no debugging is needed, you may change '-O -' to '-O /dev/null'

# --------- enable Tunnel ---------
SERVER_IPv4_ENDPOINT=216.66.80.30
CLIENT_IPv6_ENDPOINT=2001:470:1f0a:9999::2/64

# add a route to the $SERVER_IPv4_ENDPOINT through the PPTP tunnel...
route add $SERVER_IPv4_ENDPOINT dev $PPP_IFACE
# should be changed to "ip route add..."

#modprobe ipv6
ip tunnel add he-ipv6 mode sit remote $SERVER_IPv4_ENDPOINT local $IPLOCAL dev $PPP_IFACE ttl 255
ip link set he-ipv6 up
ip addr add $CLIENT_IPv6_ENDPOINT dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -f inet6 addr

and for shutting down the tunnel:

Code: [Select]

/etc/ppp/ip-down.d/he-ipv6-tunnel
#!/bin/sh

if [ $PPP_IPPARAM != 'tunnelbroker' ]; then
        # echo "This script shall only be used for the tunnelbroker PPTP tunnel!"
        exit;
fi

#disable tunnel
ip route del ::/0 dev he-ipv6
ip tunnel del he-ipv6

# Still to be done here: clean up the zombie route to the PPTP tunnel server

The rest can be done like described here: http://www.tunnelbroker.net/forums/index.php?topic=941.0

Now, we only need to get a different IPv4 address for PPTP and IPv6 tunnel server at each POP and it should work without tricks.

[jgadmin]

Gah, I meant if you can ping 172.31.255.1, then it's up.  I think it's too early in the morning.

I cannot ping that IP from my router (Mikrotik) even when it says it is connected.

[eonesixfour]

DISABLE_IPV6=No        # could also work with =Yes, please try afterwards.

I wonder if this is what we need to do, add the IPv6 address to the pptp interface instead of adding a secondary interface to route packets over the pptp interface... Although it's academic at this point in time since I can't ping the first hop.

[claas]

From the shorewall IPv4 manpages:

DISABLE_IPV6=[Yes|No]
If set to Yes or yes, IPv6 traffic to, from and through the firewall system is disabled. If set to No or no, Shorewall will take no action with respect to allowing or disallowing IPv6 traffic. If not specified or empty, “DISABLE_IPV6=No” is assumed.

If set to "No"/"no" you need to have shorewall6 installed if you want firewalling for IPv6, too. This can not done by shorewall. Or you do ip6tables manual firewalling...

[eonesixfour]

If set to "No"/"no" you need to have shorewall6 installed if you want firewalling for IPv6, too. This can not done by shorewall. Or you do ip6tables manual firewalling...

I didn't mean firewall, I meant attaching the IPv6 address to the ppp interface after it comes up, alternatively pppd on linux supports IPv6. So the IPv6 address information could be sent along with the IPv4 IP... However I'm still stumped as to why I can get a connection up, but can't ping the next hop...

[eonesixfour]

I didn't mean firewall, I meant attaching the IPv6 address to the ppp interface after it comes up, alternatively pppd on linux supports IPv6. So the IPv6 address information could be sent along with the IPv4 IP... However I'm still stumped as to why I can get a connection up, but can't ping the next hop...

I finally figured it out, pptp is no better than using IPv6 directly, since it uses GRE protocol, I was hoping/expecting it to be using UDP instead, and while the control packets keeping the tunnel up is using TCP. Nice idea I guess, but can/does break just as much as regular IPv6, please add l2tp which can use UDP instead.

[kcochran]

The underlying PPP doesn't have your tunnel's v6 addresses attached to it in any way.  We looked at ways of doing that to make this whole process even simpler, but the implementation of IPv6 in PPP doesn't lend itself to this application.  IPv6 in PPP only negotiates link-level addresses, and then hands it off to RA for prefix announcements and stateless/stateful configuration.  As there's no nice way to find out what your computer decided to configure itself with the RA/SLAAC, there's no nice way to route your /64 or /48 to it.  DHCPv6 would be an option for stateful configuration tagging along with RA... but DHCPv6 support is spotty on the major operating systems.

[eonesixfour]

The underlying PPP doesn't have your tunnel's v6 addresses attached to it in any way.  We looked at ways of doing that to make this whole process even simpler, but the implementation of IPv6 in PPP doesn't lend itself to this application.  IPv6 in PPP only negotiates link-level addresses, and then hands it off to RA for prefix announcements and stateless/stateful configuration.  As there's no nice way to find out what your computer decided to configure itself with the RA/SLAAC, there's no nice way to route your /64 or /48 to it.  DHCPv6 would be an option for stateful configuration tagging along with RA... but DHCPv6 support is spotty on the major operating systems.

It could though, you send IPv4 address information out, you could also send out IPv6 information, when I asked pppd to request IPv6 details I got this back:

Protocol-Reject for 'IPv6 Control Protovol' (0x8057) received

[kcochran]

It could though, you send IPv4 address information out, you could also send out IPv6 information, when I asked pppd to request IPv6 details I got this back:

Protocol-Reject for 'IPv6 Control Protovol' (0x8057) received

The only thing PPP actually configures with IPv6 enabled is the link-local address.  fe80::/10 space.  Anything beyond that is up to RA/SLAAC/DHCPv6 unless you want to get much more involved.

[eonesixfour]

The only thing PPP actually configures with IPv6 enabled is the link-local address.  fe80::/10 space.  Anything beyond that is up to RA/SLAAC/DHCPv6 unless you want to get much more involved.

So yet another fine example of IPv6 at it's best, and yet another reason why I'm really not surprised that it hasn't taken off.

If we poor geeks are having so much trouble what hope is there for the rest of the world?

I can see NAT living long long into the future until the rest of the bugs are sorted out so IPv6 "just works" for any one under most circumstances.

[Ninho]

If we poor geeks are having so much trouble what hope is there for the rest of the world?

As the first outsider who tested, or at least reported, I can say this : yesterday it was all working like a charm, including DNS, TCP and UDP, in both configurations of VPN being tunnel endpoint or not (and dynamically switching between them). Now 24 hours later - at 19:15  European time 05/28 - things are flaky and mostly NOT working. So, I assume, there are temporary problems at the PoP, maybe they didn't withstand the load from our testing ? Keep hope, all ye this read ...

All my tests were done in Windows 2000 (shall test Linux another day) and connecting thru Frankfurt.

--
Ninho

[kcochran]

Ok, made a couple changes, let us know how things go.  Certain elements of pppd and the support scripts seem to not quite line up all the time.  That shouldn't be an issue now... I hope. 

[jgadmin]

It is now working for me.  Though I cannot use the PPTP connection for a IPv6 to the same server.

[homeipv6]

Hi all,

I have the same problem. VPN works but IPv6 tunnel don't.
When I start ping of DNS 2001:470:20::2 I see that replies from DNS comes back on ppp0 interface
but on he-ipv6 interface only outgoing icmp packets (41 protocol is accepted  in iptables).

If problem in the same IPv4 address for PPTP and IPv6 tunnel endpoint may be changing of
IPv6 Tunnel Endpoint Server IPv4 address to 172.31.255.1 can fix this problem?

By the way VPN dies after some time of work (no reply from 172.31.255.1 but connection with VPN server alive).