PPTP VPN Tunnel to get around double firewall/NAT?

Ok, I'm stuck between a double firewall / NAT at home, and I can't control the outer Firewall/NAT. (There aren't many choices of Broadband Internet Access where I live in so called Real Life).

I've now got a PPTP VPN set up from my Macintosh Powerbook at home to a server at a collocation facility that is on a great open connection. I seem to be able to just about anything via the tunnel, http, ssh, real video, etc.

But Second Life still doesn't work!

I set up an ethereal session on the remote gateway server (where the tunnel terminates at the collocation facility) and monitored UDP traffic as well as all traffic going to 69.25.104.148 (the second life server that my client was trying to talk to). All I saw was 5 outgoing 12034/UDP packets going out and then Second Life client would not get past "Verifying Protocol" and then threw up a dialog box saying Unable to Connect to Second Life. No different than if I didn't have the tunnel.

I do know that all my traffic from my Mac is going thru the tunnel:

% netstat -nr
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 64.124.66.58 UGSc 43 103 ppp0
10.240/16 64.124.66.58 UGSc 2 0 ppp0
64.124.66.58 192.168.10.1 UGHS 7665 14363 en1


The remote gateway is 64.124.66.58 which is also my Mac's default gateway.
(The Mac is 192.168.10.1 localy and has a tunnel IP address of 64.124.66.50

Any idea of what I am doing wrong or what I can do to make the best of this situation?

You can also email me at rberger at ibd dot com

Various threads in the Forums mention using a VPN as a way to get around it, but I just got this mininalist response from Linden Support:

Thank you for your inquiry. For a network connection to work, it has
to support bidirectional (upstream and downstream) communication on both
TCP and UDP on ports 12020 - 13050 (or, for the port-conscious,
12020-12050 and 13000-13050). VPN tunnels may be unable to provide this
degree of network control, particularly for both directions of
communication.

With a followup response when asked to escalate:

Thank you for your inquiry. Based on your description (that no incoming
network access is passing through the public gateway), as well as your
mentioning that the connection is equally blocked whether the tunnel is
set up or not, I'd suggest analyzing the connection through the public
gateway that said you cannot control. It also has to allow
bidirectional UDP/TCP communication on ports 12020-13050.

I see you've posted on the forums. I cannot search for NAT or VPN since
our forums search ignores three-letter words. Hopefully, if one of our
residents has information based on their experiences, they can share it.
A quick query among our developers didn't pull up any more information
other than a recommendation to check the public gateway configuration.

Just in case someone wants to actually help me with this. Attached is my secondlife.log

I set up Ethereal (packet sniffer) on the Internet/Ethernet interface of the public gateway (eth0 64.124.66.5 where the public side of the VPN tunnel (ppp0 64.124.66.51) terminate and an Ethereal on my Mac on the private side of the ppp interface (ppp0 64.124.66.51) of the VPN tunnel and watched while I started Second Life on my Mac.

The packets from the public IP address of the tunnel (64.124.66.51) with a src port of 12034 and dst port of 12036 are definately going out to the linden server util.agni.lindenlab.com (69.25.104.14, 6 of them over about 30 seconds. The packets have the correct src address of 64.124.66.51. The public gateway is showing the tunnel IP address in its arp table correctly.

But I see no packets coming back to any of these interfaces from any IP address in the same block as the lindenlabs server.

If I go to another computer on a different part of the Internet I can ping and ssh to the tunnel address (64.124.66.51) and properly communicate with my Macintosh, so its clear that the tunnel ip address is being properly and publicly propogated to the Internet.

I also made sure that the public gateway server firewall was configured to allow all packets and protocols to/from the Internet to the ppp tunnel.

I even turned off the host based firewall on the gateway to doubly make sure there were no firewall issues and there was no change.

So what's up? Am I missing something? Has anyone ever made something like this work. It seems like it should just work once I have the VPN up...

Any suggestions for how to simulate a secondlife UDP transaction?

Looks like there may be a firewall upstream from me at the collocation facility

It was thanks to Lee Lindon helping me brainstorm ways to figure it out that I found it.

The (now obvious) thing to do was to traceroute from some host not on the same LAN segment as my public gateway to my public VPN tunnel.

This showed that UDP (traceroute uses UDP by default) was not getting to my server:

$ /usr/sbin/traceroute 64.124.66.50
traceroute to 64.124.66.50 (64.124.66.50), 30 hops max, 38 byte packets
1 205.214.170.252 (205.214.170.252) 0.507 ms 0.377 ms 0.277 ms
2 172.ge-5-2-1.er10a.sjc2.us.above.net (209.249.69.26) 0.464 ms 0.521 ms 0.454 ms
3 209.133.17.29.gw.sjc.aaph.com (209.133.17.29) 3.336 ms !X * *
4 * 209.133.17.29.gw.sjc.aaph.com (209.133.17.29) 3.886 ms !X *
5 209.133.17.29.gw.sjc.aaph.com (209.133.17.29) 3.482 ms !X * 3.388 ms !X


Even though traceroutes out from my Macintosh to lindenlabs SL servers did work:

# traceroute data.agni.lindenlab.com
traceroute to data.agni.lindenlab.com (66.150.244.192), 30 hops max, 40 byte packets
1 gate0.ibd.com (64.124.66.5 65.049 ms 71.114 ms 38.582 ms
2 64.124.66.1 (64.124.66.1) 27.916 ms 20.098 ms 46.142 ms
3 716.ge-6-1-1.er10b.sjc2.us.above.net (209.133.17.27) 24.33 ms 60.161 ms 32.75 ms
4 so-1-0-0.mpr3.sjc2.us.above.net (64.125.30.97) 26.594 ms 24.334 ms 27.189 ms
5 so-3-0-0.mpr2.sjc7.us.above.net (64.125.30.173) 29.62 ms 22.699 ms 22.724 ms
6 so-3-2-0.edge1.sanjose1.level3.net (4.68.127.33) 25.265 ms 22.802 ms 29.232 ms
7 so-1-2-0.bbr2.sanjose1.level3.net (209.244.3.141) 61.49 ms 55.821 ms 22.783 ms
8 so-2-0-0.mp2.sanfrancisco1.level3.net (64.159.0.217) 23.911 ms 29.907 ms 24.265 ms
9 so-11-0.ipcolo2.sanfrancisco1.level3.net (4.68.96.146) 22.546 ms 26.966 ms 28.664 ms
10 gw-level3-sfo.internap.com (63.211.143.1 30.012 ms 29.211 ms 48.271 ms
11 border5.ge4-1-bbnet2.sfo.pnap.net (63.251.63.74) 37.626 ms 35.273 ms 27.263 ms
12 * * *


(I was told that as long as it got to the pnap.net gateway, its fine. the SL servers block traceroute UDPs to preven DoS attacks)

Now as long as I can get the person controlling that upstream gateway (209.133.17.29.gw.sjc.aaph.com) to open the SL ports, I SHOULD be able to finally get on to SL from home!

I will post the final results when it all works.