Slashdot Mirror
Life Behind the Firewall Curtain?
beegle asks: "After a recent move, I discovered that my only broadband option is a cable company that puts all of its customers behind a NAT box. That means that my ISP gives me a 'private' 10.x.x.x address instead of a routable IP address. I'd like to connect to my machines remotely and use software that depends on a real address (P2P, games, etc.). The ISP doesn't prohibit this, but they're not willing to help, either. I've considered setting up a VPN to a friend's network, but that seems terribly inefficient. What hardware or software would you recommend for those of us who are stuck with 'fake' IP addresses?"
Post what ISP it is, so everybody knows not to ever go with them.
You can tunnel IP6 over IP4. Once you have that set up, you can have a static IP6 address on the real IP6 Internet. Now all you have to do is find a game server to talk to you at your IP6 address. Good luck.
No weapon in the arsenals of the world is so formidable as the will and moral courage of free men.-Ronald Reagan
I'm behind a NAT box and games work fine. Some games may have special requirements but modern NAT boxes tend to understand the protocols (I'm pretty sure games like Quake3 will work no matter what).
P2P is going to be somewhat of a problem. But only for people trying to connect to you. Some of the modern P2P protocols can work around it (by way of you initiating the outgoing connection). Other than that all the P2P stuff I have used worked (although I'm not a big P2P user).
All in all, NAT isn't that bad and most of the time I don't even notice it's there. It's my NAT box though, so it's a little different. However, I haven't done any special configuration other than allowing the occasional VNC/SSH connection to internal machines.
The ratio of people to cake is too big
Consider what is possible if you hack TCP/IP to permit opining an inbound connection with merely a TCP ACK with the right sequence number (which was published on a P2P network when you "open" the non-standard port). The first respondant to connect "wins" and you can spawn a session. To accept another one on the same port, you publish a new ACK sequence number. The downside is that inbound connections have to poll to connect, and this does not scale well -- breaking the sequence number space into "inbound" and "response" sequences can address this somewhat. This is meant as an example of how the TCP connection sequence can be made symetrical and not a definitive best way of doing so.
While it is easy for an ISP to filter inbound TCP SYN packets, ensuring outbound ACKs aren't really rogue connection iniatiators using this hacked protocol requires the ISP's filtering to suddenly become stateful (otherwise they can not know that it is a bonafide response).
The downside of a symetrical session-establishment protocol is, of course, the race between inbound and outbound connection attempts (think of the difference between picking up the phone to make vs. answer a call -- you don't know which one you're doing utill after you listen for dialtone or a surprised counterparty ("...but it didn't ring yet!?"). But, that can be overcome.
You could've hired me.