I am able to connect to the PPTP server, but I am not able to pass any traffic (I can send out packets, but none come back). Is there a problem with the service?
I'm having the same problem, I think the problem is the IPv6 tunnel server and the pptp server share the same IP, because when the PPTP tunnel comes the IP is added via the default route, what IPs do I route over the PPTP tunnel?
Quote from: jgadmin on May 28, 2010, 01:41:14 AM
I am able to connect to the PPTP server, but I am not able to pass any traffic (I can send out packets, but none come back). Is there a problem with the service?
You can't pass IPv4, or IPv6 traffic? You should be able to ping at least the other side of the tunnel via the PPTP interface.
If you can't, it may be a NAT issue if you're behind a NAT.
Quote from: eonesixfour on May 28, 2010, 02:30:20 AM
I'm having the same problem, I think the problem is the IPv6 tunnel server and the pptp server share the same IP, because when the PPTP tunnel comes the IP is added via the default route, what IPs do I route over the PPTP tunnel?
I notice that when the PPTP tunnel comes up, it delivers a route for the tunnel server IPv4 which points it through my LAN default router, and not through the PPTP tunnel. If one tries to set up a a 6in4 tunnel to that server, it won't go through the PPTP tunnel, but through the LAN default router.
However, I
don't have the "VPN is tunnel endpoint" option set. This may be why it's delivering this route. I presume that if I had that clicked on, it would deliver a route pointing it through the PPTP tunnel. But I haven't tested this yet.
Anyway, if you want to use the static IPv4 that comes with the PPTP tunnel to access the internet, you must have the "use default gateway on remote network" box checked under the "General" tab "Advanced TCP/IP Settings" CPL window (this is under XP, not sure where they put this on 7, etc). Under XP this is on by default, not sure about other windows OS (but I presume it's the same).
Hello, first of all big thanks for the great idea of a PPTP tunnel service!!
I enabled the PPTP tunnel on my linux machine. ppp0 is used to get the internet connection with PPPoE and ppp1 is the tunnel to the Frankfurt POP (216.66.80.30). Pinging the IPv4 PPTP endpoint is just fine ( ping 172.31.255.1 ).
But I can not pass traffic through ppp1.
I need a route to the PPTP tunnel server through ppp0.
And I need a second route to the IPv6 tunnel endpoint, trough the PPTP tunnel (ppp1), but both share the same IP.
Can this be achieved? Or should the PPTP server have a different IPv4 adress?
Quote from: jimb on May 28, 2010, 02:49:11 AM
However, I don't have the "VPN is tunnel endpoint" option set. This may be why it's delivering this route. I presume that if I had that clicked on, it would deliver a route pointing it through the PPTP tunnel. But I haven't tested this yet.
I have checked this box, but the same route appears here, too.
# ip route show
216.66.80.30 dev ppp0 scope link src 85.176.142.132 # <------ this one seems to be wrong
213.191.84.199 dev ppp0 proto kernel scope link src 85.176.142.132
172.31.255.1 dev ppp1 proto kernel scope link src 184.104.125.112 <--- works fine
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.10
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
default dev ppp0 scope link
I tried to change the route, to point to ppp1, but then the tunnel is dead.
Quote from: jimb on May 28, 2010, 02:39:28 AM
Quote from: jgadmin on May 28, 2010, 01:41:14 AM
I am able to connect to the PPTP server, but I am not able to pass any traffic (I can send out packets, but none come back). Is there a problem with the service?
You can't pass IPv4, or IPv6 traffic? You should be able to ping at least the other side of the tunnel via the PPTP interface.
If you can't, it may be a NAT issue if you're behind a NAT.
I cannot ping the other side, and I am trying this on my router (no NAT in the way) and Laptop (behind NAT). Other PPTP VPNs work on my laptop, when I try them, just not the HE one.
I just tried a PPTP test to the London server and it didn't work. But PPTP to the Fremont, CA, USA server works.
Quote from: jimb on May 28, 2010, 02:39:28 AM
You can't pass IPv4, or IPv6 traffic? You should be able to ping at least the other side of the tunnel via the PPTP interface.
If you can't, it may be a NAT issue if you're behind a NAT.
I can't ping the other side of the PPTP tunnel (172.31.255.1) but packets are being sent back and forth from my end to the remote end of the PPTP connection just fine or the tunnel would keeping timing out and dropping, which is what happened before I realised what was going on with the PPTP/IPv6 tunnel server sharing the same IP and tried to re-route it over the tunnel, which caused the tunnel to drop.
I'm on the LA server, going to try the Freemont server.
Quote from: claas on May 28, 2010, 02:56:53 AM
Quote from: jimb on May 28, 2010, 02:49:11 AM
However, I don't have the "VPN is tunnel endpoint" option set. This may be why it's delivering this route. I presume that if I had that clicked on, it would deliver a route pointing it through the PPTP tunnel. But I haven't tested this yet.
I have checked this box, but the same route appears here, too.
# ip route show
216.66.80.30 dev ppp0 scope link src 85.176.142.132 # <------ this one seems to be wrong
213.191.84.199 dev ppp0 proto kernel scope link src 85.176.142.132
172.31.255.1 dev ppp1 proto kernel scope link src 184.104.125.112 <--- works fine
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.10
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
default dev ppp0 scope link
I tried to change the route, to point to ppp1, but then the tunnel is dead.
OH wow. I just realized that the PPTP server and 6in4 servers appear to use the same IPv4 address! I was using the DNS name so didn't realize it mapped to the same IP. I really shouldn't stay up until 3AM answering posts on here. :P
Well, that'd do it. You can't route the 6in4 tunnel through the PPTP tunnel without breaking connectivity to the PPTP tunnel.
Perhaps Windows and OSX has some "magic" which deals with this or something, since I presume it was tested and worked for windows, but maybe linux doesn't? I wanted to test this by clicking that box on and seeing how it traced, but the london PPTP didn't work for me at all (connected, didn't pass traffic). Now I'm too tired to play anymore tonight.
Remember, this
is beta. :P
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.
Reporting down while it appears up could also be a bug on this side. :D
The easy test is if you can ping the v4 address of your side of the PPTP connection from somewhere else, then it's up.
Quote from: kcochran on May 28, 2010, 03:56:30 AM
Reporting down while it appears up could also be a bug on this side. :D
The easy test is if you can ping the v4 address of your side of the PPTP connection from somewhere else, then it's up.
I can ping it even when the PPTP connection is not running.
Quote from: kcochran on May 28, 2010, 03:56:30 AM
The easy test is if you can ping the v4 address of your side of the PPTP connection from somewhere else, then it's up.
While I can ping the IP, no traffic comes over the PPTP link when I use ngrep to sniff packets.
Gah, I meant if you can ping 172.31.255.1, then it's up. I think it's too early in the morning.
Quote from: kcochran on May 28, 2010, 04:11:22 AM
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.
Quote from: jimb on May 28, 2010, 03:30:18 AM
Remember, this is beta. :P
Right, and we help you to test it
Quote from: eonesixfour on May 28, 2010, 03:33:32 AM
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):
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.
/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:
/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:
/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.
Quote from: kcochran on May 28, 2010, 04:11:22 AM
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.
Quote from: claas on May 28, 2010, 04:30:46 AM
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.
From the shorewall IPv4 manpages:
Quote
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...
Quote from: claas on May 28, 2010, 05:54:02 AM
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...
Quote from: eonesixfour on May 28, 2010, 06:04:04 AM
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.
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.
Quote from: kcochran on May 28, 2010, 06:16:04 AM
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
Quote from: eonesixfour on May 28, 2010, 06:56:59 AM
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.
Quote from: kcochran on May 28, 2010, 07:09:47 AM
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.
Quote from: eonesixfour on May 28, 2010, 08:32:53 AM
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 8)...
All my tests were done in Windows 2000 (shall test Linux another day) and connecting thru Frankfurt.
--
Ninho
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. :D
It is now working for me. Though I cannot use the PPTP connection for a IPv6 to the same server.
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).
PPTP to Amsterdam PoP working fine here.
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 (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).
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.
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
Quote from: jgadmin on May 28, 2010, 10:54:45 PM
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.
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
Quote from: jimb on May 29, 2010, 01:06:03 PM
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.
Quote
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.
Quote from: kcochran on May 28, 2010, 07:09:47 AM
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?
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.
Quote from: MentalPower on May 29, 2010, 07:19:01 PM
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 ...
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 :).
Quote from: MentalPower on May 30, 2010, 09:08:34 AM
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.
OK forget what I said about BBQ I guess. ;D (though I went to a nice one yesterday myself)
Quote from: kcochran on May 28, 2010, 06:16:04 AM
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:
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:
# 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):
# 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
Quote from: kcochran on May 30, 2010, 11:06:19 AM
Quote from: MentalPower on May 30, 2010, 09:08:34 AM
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.
When I use a very short time, PPTP will not have any actual network traffic. But the windows system and found no disconnect.
I am windows 2003 and And in behind a router. LAN other computers sharing the PPTP connection.
Very anxious to solve this problem. ???
The tunnel stops working for me about every half hour. I get times between 20 minuets and 5 hours.
Interesting. I wonder what's causing the instability? Is there more or less constant traffic across the PPTP? I would suspect some stateful firewall or NAT closing a hole if the traffic dies out for more than two minutes or so. Maybe try some keepalive pings, one per minute or so?
It's a pretty common situation if there's not an explicit rule to allow the traffic all the way through. For instance, I have a friend set up on a 6in4 connection, and I must run a cron job to do a v6 ping across the pipe every two minutes or else his firewall (some Westell) closes the hole.
Quote from: jimb on June 02, 2010, 03:49:44 PM
Interesting. I wonder what's causing the instability? Is there more or less constant traffic across the PPTP? I would suspect some stateful firewall or NAT closing a hole if the traffic dies out for more than two minutes or so. Maybe try some keepalive pings, one per minute or so?
There is not NAT in the way because my router, which has a real IP, is making the connection. The router is checking every 60 seconds if the other side of the VPN is pingable. If it is not then the interface is brought down then 10 seconds later brought back up.
Quote from: jgadmin on June 02, 2010, 05:27:51 PM
Quote from: jimb on June 02, 2010, 03:49:44 PM
Interesting. I wonder what's causing the instability? Is there more or less constant traffic across the PPTP? I would suspect some stateful firewall or NAT closing a hole if the traffic dies out for more than two minutes or so. Maybe try some keepalive pings, one per minute or so?
There is not NAT in the way because my router, which has a real IP, is making the connection. The router is checking every 60 seconds if the other side of the VPN is pingable. If it is not then the interface is brought down then 10 seconds later brought back up.
It wouldn't necessarily have to be NAT. Any firewall without an explicit policy rule allowing the traffic.
Quote from: jimb on June 02, 2010, 03:49:44 PM
I would suspect some stateful firewall or NAT closing a hole if the traffic dies out for more than two minutes or so.
I don't think that's the reason - PPTP still dies after a random interval even if I run 'ping -t ripe.net' on my Win7 machine the whole time.
K. Who knows then. Look at your logs. :p
Quote from: jimb on June 02, 2010, 03:49:44 PM
Interesting. I wonder what's causing the instability? Is there more or less constant traffic across the PPTP? I would suspect some stateful firewall or NAT closing a hole if the traffic dies out for more than two minutes or so. Maybe try some keepalive pings, one per minute or so?
Yes, there is running ping over VPN.
I don't think that this is NAT issue because other (not tunnelbroker) PPTP VPN works fine.
Quote from: jimb on June 02, 2010, 07:32:37 PM
It wouldn't necessarily have to be NAT. Any firewall without an explicit policy rule allowing the traffic.
Hi Jim! I'm in the same boat as the others - or similar -
I don't run a software firewall at the moment on the Windows box which serves as IPv6 router and local tunnel endpoint. If it were a firewall thing, it would have to be inside the Speedtouch ST510 box, but that ain't it because 1) I have explicit firewalling disabled in the ST router, 2) if it were an (implicit?) rule blocking traffic somewhere along the chain, things would not work AT ALL. That it works correctly for minutes proves it is not this kind of settings problem.
What I experience and, I think, Jgadmin, Donald and others also have been experiencing is traffic inside the tunnel ceasing after X minutes, while the tunnel itself remains formally open.
A first thought would be dynamical NAT entries timing out, but the tunnel dies out even while pinging the end point constantly at 1 second intervals.
I even tried this : in the router, unbind the "helper" applications for proto 47 (GRE) and PPTP (TCP :1723) and establish FIXED mappings to the windows box instead [like I do, with success, for proto 41]. Unfortunately, in this instance it doesn't work ! Either I goofed while unbinding/reNATting, or the problem may be on HE's side.
I'd appreciate feedback/ help / diagnosing ideas from both the HE people on the one hand, you and the other Masters OTOH. Did I forget about some server addresses/ ports/ protos ?
JimB, you are telling you have got NO problem ? Are you connected directly to a public IP or behing a local NAT ? I could try a direct connection - by temporarily replacing the ST 510 by my old ST 330 (ADSL on USB) but I am not in a hurry to do that if it could be avoided at all...
It's definitely not a NAT issue because PPPoE is established by my Linux box, not the ADSL router (which is set to bridge mode), so no NAT is involved. It's not conntrack either, because I have another PPTP tunnel going out of that box, and it's working fine.
I'm not using PPTP. I'm using a straight 6in4 tunnel from a linux box with a public IP. I experimented with the PPTP just to play, and got it working from a Windows box behind my NAT, but didn't do any long term testing.
I don't know what's causing the problems people are having, and can only guess. If you've eliminated some connection hole closing issue w/ firewall, then it's something else. Could be anything. Could easily be on the HE side (some bug in the PPTP or 6in4 or whatever in whatever software/hardware they're using). Only way to know is to maybe do some packet captures, look at logfiles/event logs for clues, etc.
Will both tunnelservers (PPTP and IPV6) stay on the same IPv4 address?
Are there plans to change it?
Hi JimB !
Quote from: jimb on June 03, 2010, 01:25:29 PM
I'm not using PPTP. I'm using a straight 6in4 tunnel from a linux box with a public IP. I experimented with the PPTP just to play, and got it working from a Windows box behind my NAT, but didn't do any long term testing.
Oh, OK then! I don't
need to use the PPTP either, simple 6in4 working very well across the Speedtouch's NAT w/ termination at either Linux or Windows boxes. Just trying to help test the BETA PPTP tunnel; when test is over and things eventually work that may be helpful too as a conveniient secondary injection point into the V4 internet, for special test purposes or if/when the national gov' insists on controlling what we must/can't do and see on the web...
QuoteI don't know what's causing the problems people are having, and can only guess. If you've eliminated some connection hole closing issue w/ firewall, then it's something else. Could be anything. Could easily be on the HE side (some bug in the PPTP or 6in4 or whatever in whatever software/hardware they're using). Only way to know is to maybe do some packet captures, look at logfiles/event logs for clues, etc.
Yes I agree, as much as I hate to blame other parties for the problems
I may experience, it could well be some connection tracking bug on HE's side.
Ok, we think we finally tracked down this one and in theory, it should be squished. Tunnels shouldn't stop working randomly once they're up... or so it says here in fine print.
As it is, we already do some NAT preservation by sending LCP pings periodically over the PPP control link. Keeps that channel live, and checks for dead links.
I 'spose you don't want to reveal what it was? I'm always curious about this stuff. Probably can't go into any detail without revealing the 11 herbs and spices though. ;)
Quote from: kcochran on June 04, 2010, 01:13:35 AM
Ok, we think we finally tracked down this one and in theory, it should be squished. Tunnels shouldn't stop working randomly once they're up...
Good shot! Looks OK now from where I stand ! Pending confirmation, thank you again...
QuoteAs it is, we already do some NAT preservation by sending LCP pings periodically over the PPP control link. Keeps that channel live, and checks for dead links.
Haha! I told'm all it could be at the LCP level under PPTP. Anyway like Jim I'd be delighted to read more in-depth explanations, even though I might not grasp the full picture ;=)
My tunnel's been up for 2.5 hours and it's still working. Looks like the problem is gone, thanks to crew at HE.
By the way, what's with the "encryption" option in the tunnel settings? How do I enable it?
Quote from: donaldgmartin on June 04, 2010, 06:58:44 AM
My tunnel's been up for 2.5 hours and it's still working. Looks like the problem is gone, thanks to crew at HE.
By the way, what's with the "encryption" option in the tunnel settings? How do I enable it?
Glad to hear it.
And you don't. It's purely there as an informational note for now. I've updated the help text associated with it clarifying that.
+1. Tunnel still working after being left unattended for a few hours :)
As for encryption, it'll be a plus if you would enable it as an option some time later.
Frankfurt VPN works almost 6 hours.
Thanks for fixing it.
Yep, still up for me too after 3 hours.
I am using the 72.52.104.74 server, the PPTP Connected but no Traffic question happen again now.
I have a Fedora 12 box with DSL modem, I tried this:
ip route delete default
ip route add default route dev ppp0 scope link metric 10
ip route add default via 192.168.0.1 dev eth0 proto static metric 11
ppp0 is my PPTP device and 192.168.0.1 my default gw,
I'm not sure metrics is the right way, but works for me.
Anackin
Quote from: anackin on July 21, 2010, 03:43:21 PM
I have a Fedora 12 box with DSL modem, I tried this:
ip route delete default
ip route add default route dev ppp0 scope link metric 10
ip route add default via 192.168.0.1 dev eth0 proto static metric 11
ppp0 is my PPTP device and 192.168.0.1 my default gw,
I'm not sure metrics is the right way, but works for me.
Anackin
Presuming you're doing 6in4 through this? If so, perhaps this is an alternative to policy routing.
I'm
guessing what makes this work is the lower metric + the scope clause on the default through the PPTP. I'm not positive, but I'm thinking maybe the scope clause causes routing to ignore the default route unless the ppp0 interface is involved, which would be the case when the source IP is the ppp0 IPv4, then that default is considered and selected because of the lower metric?
That'd have basically the same affect as policy routing if it works the way I describe above, only using the default through ppp0 if the source IPv4 lives on the ppp0 interface. But I'm guessing here since I'm not fully understanding how the "scope" thing works in this context.
Yep. I think scope link means route goes to the device, whatever its IP (looking some ipsysctl howto).
What I want is route all traffic TO the pptp and receive from pptp; so, packet sent via ppp0 must reach pptp server. But if pptp is default gw they never reach remote pptp link.
Metrics make all packet go to ppp0 dev (first choice, lower metric); but packet of pptp tunnel loops, so they find another default gw with higher metric, the local one, and they reach pptp server.
The problem is: in no way my 6in4 tunnelbroker work if I choose same endpoint of VPN. The only way I managed was to change the IPv4 tunnel endpoint and then attach it to my dynamic IP DSL. It's like having 2 vpn, one ipv4 and other ipv6, with ipv6 tunnel endpoint in my dsl dynamic ip.
Can anyone make tunnelbroker ipv6 and vpn with same endpoint work in linux?
Ah. I thought u were already doing that. You need to use policy routing. see the post by mthode.
Thank you. I follow mthode post.
Now
->pptp works.
->with policy routing I had my ipv6 tunnel work with pptp endpoint.
->With default gateways ppp0 + eth0 with different metrics, I make my connection get pptp IP. (I mean, www.myip.net give my pptp ip.), while before it was my dynamic dsl IP. I think metrics is the workaround for my NAT issues.