PPTP Connected but no Traffic

[hisken]

PPTP to Amsterdam PoP working fine here.

[jimb]

BTW, London was working for me today on a Windows XP box.  

I also tested 6in4 through PPTP and it worked fine for me despite the route pointing the 6in4 server IP via my LAN router instead of the PPTP tunnel.  

I just brought up the PPTP tunnel, and added the 6in4 tunnel via netsh using the PPTP IPv4 as source, put my client IPv6 on the tunnel interface, added a default route via the other side of the 6in4 tunnel, and it worked just fine.  

Somehow windows makes an exception and appears to ignore the route table for PtP addresses/interfaces or something.  Really not sure how it works, but it was sending the 6in4 traffic through the PPTP despite the route (presumable added by windows when one brings up the PPTP) which should send that traffic to the LAN gateway.

Note that it doesn't work if you turn off the "use default route on remote network" checkbox.  Apparently the "magic routing" doesn't work unless there's a lower metric default route pointing through the PPTP connection, so if you wanted to do a "split tunnel" type deal, it wouldn't work.  I haven't experimented with adding say, a lower metric route for the TS through the PPTP or anything like that though.  

For Linux, I think you'll have to resort to policy routing (see this thread):  http://www.tunnelbroker.net/forums/index.php?topic=951.0

This basically sets up a separate alternate routing table with a default route through the PPTP device which is used only when the source IP is the PPTP IPv4 (via ip rule).

[homeipv6]

Frankfurt working for me after I setup policy routing.
After some time of work no replies from 172.31.255.1 but connection with VPN alive - LCP echo request/echo reply are received/send.

[jgadmin]

I had a working connection earlier today (could ping 172.31.255.1), but now I do not (and have not since I got home from work 4+ hours ago)

EDIT--

I got it working (at least for 6in4).  I setup a watchdog timer to cycle the PPTP connection when it cannot ping 172.31.255.1

[Ninho]

I had a working connection earlier today (could ping 172.31.255.1), but now I do not (and have not since I got home from work 4+ hours ago)

Here too, the PPTP tunnel ceased to work after a while.
As a dirty workaround, constantly pinging the server 172.31.255.1 seems to maintain things in the up state. Can you confirm it works the same for you ? <UPDATE> I let the system alone for ~ 1 hour pinging in the background; coming back, found the tunnel dead - pinging that address was not the magical remedy... :=(   </UPDATE>

There appears to be timeouts, but exactly where ?
In my case one guess might be the home router - it has a "helper" for the GRE protocol,  but this may not be adequate for maintaining the state of PPTP. A test would be to remove the "helper" and forward proto 47 (I think) manually. I didn't bother because I'm not overly wanting to have the PPTP tunnel work, and on the other hand sadly I have real hard problems falling upon my head in the true life. Anyway just a suggestion, look at your NATting device if you have one.

[jimb]

The helper is only really needed if there's more than one PPTP user behind the NAT.

Is it the PPTP that's dieing, or the 6in4?

Only way to really try to figure out what's going on is by sniffing things when it dies and/or looking at firewall logs to see if anything is being dropped.  

I'm no expert on how PPTP works internally, but it does use both a TCP connection (port 1723) and GRE.  So it's possible it could either of those.  What I don't know is how/when the TCP connection is used.  i.e., does it need a constant TCP connection for control or key exchange or something like that?  Or is it just for initial connection setup, etc?  I'm sure the actual packet data uses GRE.

FWIW, I've found it to work well long term (24+ hours) when I used to establish PPTP tunnels from work to my home servers for accessing file shares and such at work.  This was from an XP box to a home linux Poptop server.  I didn't do anything special with the firewalls at work (Netscreen), and at home I had a static destination NAT (iptables DNAT) for one of my static IPs which pointed TCP 1723 and GRE protocol to my Poptop box.  That's it.

Of course it could also be something happening on the HE side, even things like reloading the router, etc.  Although typically windows will redial and reconnect after a delay (little box will come up on the screen).

Anyway, don't expect much from HE until Monday or Tuesday, as it's Memorial Day Weekend here in the States and everyone is out BBQing.  :P

[Ninho]

The helper is only really needed if there's more than one PPTP user behind the NAT.

Is it the PPTP that's dieing, or the 6in4?

The PPTP stops transmitting payload data (IPv4). It's independent of the 6in4. Actually the tunnel itself stays up, as seen by the control icon on the Windows client side as well as the tunnel details webpage at tunnelbroker.net. It seems to be the PPP part inside the tunnel which stops working - and, as you know, PPP itself is comprised of several sublayers, could be a LCP problem, as a wild guess.

Anyway, don't expect much from HE until Monday or Tuesday, as it's Memorial Day Weekend here in the States and everyone is out BBQing.  :P

Perso I'm neither competent nor having the time to engage in real deep diagnosing. Meanwhile enjoy your holiday ... and BBQ !

--
N.

[kjotte]

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.

Even getting that far then setting up the IPv6 route by hand would be an improvement.  That way you're not doing a tunnel (6in4) within a tunnel (PPTP).  Perhaps in the next generation?

[MentalPower]

For me, I can ping both the first hop (172.31.255.1), the tunnel's public IP (tserv12.mia1.ipv6.he.net) and a majority of HE's network (DNS servers and such). But I can't get to anything that would result in more than one hop (tunnelbroker.net, google.com, etc) any traceroute tests to these die after the first hop. Methinks its a routing issue in the server. Note that this is without any IPv6 stuff enabled yet, using a Win7 box.

[Ninho]

For me, I can ping both the first hop (172.31.255.1), the tunnel's public IP (tserv12.mia1.ipv6.he.net) and a majority of HE's network (DNS servers and such). But I can't get to anything that would result in more than one hop (tunnelbroker.net, google.com, etc) any traceroute tests to these die after the first hop. Methinks its a routing issue in the server. Note that this is without any IPv6 stuff enabled yet, using a Win7 box.

For me at least while it (=the PPTP tunnel) works, it does work i.e. full IPv4 service is available without any of the limitations you cite. The only little problem is service dies out after awhile...

Let's wait till the fine team at HE is back at sorting out the problems ...

[MentalPower]

It may be that some sites are less buggy than others. I created a tunnel in New York and it worked fine, whereas my Miami tunnel still doesn't route. I'll patiently wait for the HE folks to finish their BBQs :).

[kcochran]

It may be that some sites are less buggy than others. I created a tunnel in New York and it worked fine, whereas my Miami tunnel still doesn't route. I'll patiently wait for the HE folks to finish their BBQs :).

Miami should be happier now.

[jimb]

OK forget what I said about BBQ I guess.   ;D  (though I went to a nice one yesterday myself)

[donaldgmartin]

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.

It's still a point to point link, right? As such, it should be able to take routes without an actual nexthop address:

Code Select Expand


ip -6 route add 2001:470:1f09:12d::/64 dev pppX

But then again, I'm not sure this qualifies as "nice". Alternatively, you could use PPP Link-Local Address configuration to set peer address to something like fe80::2, and then route user's /64 or /48 through it.

Speaking on the topic, I'm having the same problem with London server. I can ping 172.31.255.1 for 5 minutes after PPTP is brought up, then it dies off. Pings are still sent out through the PPP link, but no answer is received:

Code Select Expand


# tcpdump -i ppp1 -nnp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp1, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
16:45:30.159453 IP 184.104.53.221 > 172.31.255.1: ICMP echo request, id 31255, seq 1, length 64
16:45:31.158497 IP 184.104.53.221 > 172.31.255.1: ICMP echo request, id 31255, seq 2, length 64
16:45:32.158344 IP 184.104.53.221 > 172.31.255.1: ICMP echo request, id 31255, seq 3, length 64
16:45:33.158194 IP 184.104.53.221 > 172.31.255.1: ICMP echo request, id 31255, seq 4, length 64


However, the tunnel doesn't time out and go down eventually, because LCP still works as it should (ppp0 is PPPoE):

Code Select Expand


# tcpdump -i ppp0 proto gre and host 216.66.80.26 -nnp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
16:44:54.383500 IP 216.66.80.26 > 188.x.x.x: GREv1, call 0, seq 297, length 24: LCP, Echo-Request (0x09), id 31, length 10
16:44:54.383674 IP 188.x.x.x > 216.66.80.26: GREv1, call 53504, seq 1442, ack 297, length 28: LCP, Echo-Reply (0x0a), id 31, length 10
16:44:54.544181 IP 216.66.80.26 > 188.x.x.x: GREv1, call 0, ack 1442, no-payload, length 12
16:44:59.387813 IP 216.66.80.26 > 188.x.x.x: GREv1, call 0, seq 298, length 24: LCP, Echo-Request (0x09), id 32, length 10
16:44:59.387957 IP 188.x.x.x > 216.66.80.26: GREv1, call 53504, seq 1443, ack 298, length 28: LCP, Echo-Reply (0x0a), id 32, length 10
16:44:59.547716 IP 216.66.80.26 > 188.x.x.x: GREv1, call 0, ack 1443, no-payload, length 12


[MentalPower]

It may be that some sites are less buggy than others. I created a tunnel in New York and it worked fine, whereas my Miami tunnel still doesn't route. I'll patiently wait for the HE folks to finish their BBQs :).

Miami should be happier now.

Much happier indeed. Thanks! I hope you're enjoying your weekend.