Translating outbound packets for nifty work-arounds

If there is one thing that frustrates me the most about common routers, it’s that they forbid outgoing packets with a destination address of the router’s public IP from returning to the local network.

For example:

If my public IP is 123.123.123.123 and my local machine on 192.168.0.2 sends out a TCP or UDP packet destined for 123.123.123.123 port 5003, which local machine 192.168.0.3 is listening to, it’s impossible to configure the router to forward local network packets to that machine. It will only accept remote packets sent to that port and provide ip translation.

There could be a solution though.

If the local machine who is sending out packets to 123.123.123.123:5003 recognized that address belongs to 192.168.0.3:5003, it could perform the translation itself.

I am hoping that Comodo might have this ability, or could have this ability added to it. It would completely solve a number of problems that have been written off as “impossible to work around”.

  • It is impossible for multiple local machines to play Starcraft on Battlenet within the same game.
    (solution: each machine runs Comodo and translates outbound address:port combinations to the appropriate local-address:port)

  • It is impossible to run a server on any local machine, and access it from the public internet address. Say you’re running an HTTP/FTP server on a given machine on your local network, it is only possible to access that server vial local-ip:80 or local-ip:21 and not public-ip:80/21 or publicaddres.dyndns.org:80/21
    (solution: set Comodo to recognize outbound http/ftp connections to 123.123.123.123 and translate them to 192.168.0.14. Because the router won’t.)

I hope this all makes sense to you. And if I am not overlooking something obvious, I’m certain such a feature would draw the attention of a huge community of gamers.

bump :BNC

re-bump? (:WAV)

***unbump ***

G’day,

* It is impossible to run a server on any local machine, and access it from the public internet address. Say you're running an HTTP/FTP server on a given machine on your local network, it is only possible to access that server vial local-ip:80 or local-ip:21 and not public-ip:80/21 or publicaddres.dyndns.org:80/21 (solution: set Comodo to recognize outbound http/ftp connections to 123.123.123.123 and translate them to 192.168.0.14. Because the router won't.)

This is just port forwarding and I can’t think of a router that can’t do this. In the example above, you set up a port forward rule in the router for port 80 to 192.168.0.14. Any incoming request to the public IP’s port 80 is forwarded inside the LAN to 192.168.0.14.

* It is impossible for multiple local machines to play Starcraft on Battlenet within the same game. (solution: each machine runs Comodo and translates outbound address:port combinations to the appropriate local-address:port)

The only way I can think you could do this is if you have either A) multiple routers connecting to a single outbound router or B) a router with multiple internal interfaces. A software firewall is not the answer to this. A smarter, multi interfaced hardware router is required.

Cheers,
Ewen :slight_smile:

Thanks for the reply panic,

I still maintain that Comodo can provide a useful solution to my problem, so let me elaborate. I will use the Starcraft on Battlenet scenario as a direct example.

In Starcraft, when you got play on Battlenet, the server connects multiple players together by sharing each player’s public IP address. Each player then individually pings (sends packets) to each other player. This is how latency is determined.

When two players from a single LAN network try to join the same Starcraft game on Battlenet, each player shows nominal ping responses from the Game Host, but the ping responses between each-other show as non-responsive (bad). This prevents either player from participating in the game.

The reason for this happening is not because Starcraft or Battlenet can’t properly communicate to each player. This can be demonstrated by the simple fact that both players on the same LAN can still enjoy playing different games at the same time, just not the same game. This shows proof that it’s not a problem of inbound packets having difficulty finding their way home.

The problem is with packets that exit the LAN from one computer, attempting to re-enter the LAN to reach the second computer. MOST all routers prohibit the return of packets that already passed through them, as they are a potential for infinite looping which can lag a network.

Each player sees each-other as the same IP address, the public IP address. However, each player is using a different game data port (configured in the Windows Registry or Game Settings). Even though the IP address cannot distinguish exactly which player is which, the port number is a dead give away.

Yes, the solution would seem to be simply forward those ports to the appropriate machines, BUT, as I stated above, the router refuses to allow packets leaving the network to re-enter the network, no ifs-ands-or-buts.

So the only solution is to translate the addresses before they reach the router. Each machine configured to recognize the destination ip:port combination (the public-ip of that network, and the local machine’s game data port), and translate the address to that local-machine’s ip. When this reaches the router, the router will say “hey, I know that machine, it’s local and not trying to re-enter the network, so everything’s good”.

I could do a flow chart if this description still doesn’t make sense. :slight_smile:

Thanks,

Eric

PS. I noted that this only affects MOST routers, but SOME routers do handle the packets properly. There are a number of Starcraft forums where people complain about this, and a few of them address the issue by recommending a different router that doesn’t restrict outbound packets from re-entering the network. It has been identified by the Starcraft community as what I stated above.

Assuming you don’t play Starcraft, here is a more direct approach for testing and trouble-shooting.

Host a webserver on a machine on your network. Try connecting to that webserver via your public internet IP address from a second machine. You cannot access the server, even though port 80 is configured to forward. Though, other people on the Internet can.

Solution: Locally translate (via Comodo) any outbound packets destined for 67.42.205.247:80 to 192.168.0.42:80. Then all requests for http://67.42.205.247:80/ will make it to the webserver (from any machine running Comodo).

Hmm… Not sure I understand the problem correctly, but I’m gonna try to give some explanation into how NAT/PAT works.

There are 3 private address ranges to chose from.
A-class: 10.0.0.0 - 10.255.255.255
B-class: 172.16.0.0 - 172.31.255.255
C-class: 192.168.0.0 - 192.168.255.255

In my example I’m using the C-class address-range (192.168.1.0)

We all know that IPv4 addresses are scarce and very limited, so NAT was implemented to solve this. This is a translation scheme that permits privately used IP addresses (ex. 192.168.1.0/24) to communicate with the Internet. Unless you have a NAT scheme, your private IP address isn’t routable across Internet. This means that your internal address 192.168.1.x is translated into a public one provided by your ISP and further routed across Internet. The return traffic is then translated back to your private address by the ISP. If you use a private router (eg. wifi routers), they too provide NAT. Which means you NAT and already NAT’ed address. Confused? Keep reading :slight_smile:

Hosts behind NAT-enabled routers do not have true end-to-end connectivity and sometimes cannot participate in some Internet services. Unless the NAT router makes a specific effort to support such protocols, incoming packets cannot reach their destination and will be dropped by your ISP. Fortunately most common routers today supports NAT extensively and the above statement is no longer any problem at all.

The thing that can be an issue is Port Forwarding. Port forwarding (sometimes referred to as tunneling) is basically forwarding a network port from one network node to another. This technique can allow an external user to reach a port on a private IP address (inside a LAN) from the outside via a NAT-enabled router. Port forwarding allows remote computers (e.g. public machines on the Internet) to connect to a specific computer within a private LAN.

So in your case Raccoon, if you’re hosting a Starcraft server and want people to be able to join, you need to properly forward the port you want them to connect to. If however you’re connecting to a Starcraft server hosted by Blizzard, this isn’t an issue. You don’t need to forward outbound ports. The TCP/IP protocol will hold all information needed to both properly translate NAT’ed addresses and the source port you’re using and make sure you’re getting the proper traffic in return. This is the major advantage with using connection oriented protocols like TCP.

The other problems you described in your scenario is something Blizzard/Battlenet needs to sort out. Forwarding ports won’t solve this as it’s not a port issue. And just so you know, sourceport numbers are randomized each time. I wouldn’t place much proof-of-origin on that :wink:

Some ISP employ port filtering as part of their “total customer service”. If you’re getting intermittent connectivity or none at all, check with your ISP to determine this. Just remember to be friendly and polite, and you’ll be amazed how helpful they can be :slight_smile:

I hope this explains a little bit. If not, please feel free to comment or ask further questions :slight_smile:

I’m sorry, Triplejolt, it doesn’t.

I’m afraid you’re underestimating my familiarity with NAT and have a misconception of battlenet hosted games. Much like most P2P networks, Battlenet does not act as a central server, but tries to connect two individuals together in whatever means possible. Both Active and Passive connections.

That is, you don’t HAVE to port forward to host a server on Battlenet, but it’s a Good Thing to do. If you don’t, then ONLY people who do forward their game-data-port can connect to you (you the server are really connecting to each of them).

As such, if multiple computers on a local network want to host games on Battlenet (effectively), each machine assigns a different game-data-port than the default, allowing each machine to act as a server for players to connect to.

Players are able to connect to you because Battlenet tells them your IP and Port combo. That is, your Public IP.

Now, unfortunately as I have been trying to explain, and this is the important part so please push aside all other information for a moment…

You cannot attempt to establish a connection to your own Public IP Address, NO MATTER what port it is-- EVEN if that port is being forwarded to a different machine on your network-- EVEN if others are able to connect to it from outside your network, YOU cannot.

Because Battlenet is broadcasting the host’s Public IP, and not their Local IP, connection is refused.

Please please please, try demonstrating by following this example which I have suggested in earlier posts.

You have 2 computers on your local network. Computer A tries to host a server (any server) be it an FTP server or HTTP server or simply a listening port of any kind. The NAT Router is configured to port forward port connections to this machine. Computer B tries to connect to this server, with the Public IP address, and not the Local Address of Computer A.

Computer A (192.168.0.101) Listening to TCP:80
Router (192.168.0.1) Forwarding TCP:80 to 192.168.0.101
Router is (64.26.38.25) WAN Address
Computer B (192.168.0.102) Sends to 64.26.38.25 TCP:80
Router determines outbound packet to 64.26.38.25 is destined for the Internet, and not the Local Network-- completely ignoring its Port Forwarding rule.

This is the case of most every router. It is a security measure to prevent infinite loops.

Comodo to the rescue!

Computer A (192.168.0.101) Listening to TCP:80
Router (192.168.0.1) Forwarding TCP:80 to 192.168.0.101
Router is (64.26.38.25) WAN Address
Computer B (192.168.0.102) Sends to 64.26.38.25 TCP:80
COMODO FIREWALL intercepts the packet and translates to 192.168.0.101 TCP:80
Router determines network packet to 192.168.0.101 is destined for Computer B, and relays the packet (doesn’t even look at the forwarding rule, since the “Zone rule” takes precedence)

Does this make any more sense?

Hi racoon.
I’m not sure it’s the feature of a firewall but there’s already a few tools out there that do network packet search and replace. Using these tools you can just replace the public ip with the local ip. There’s a few method from dll injection to real tcp stack interception. And the price vary accordingly. The free and most popular one is Winsock Packet Editor. However it is detected by some anitvirus as hacktool. And most game with anticheat will try to block it. Off course it’a alwais possible to hide it but it’a another story.

anywais … here’s three working packet editor (intercept search and replace) that i know to works:

http://www.bo-solutions.com/index.php

No, I didn’t underestimate you. I provided an explanation so that others beside you and me can read and understand our dialog :slight_smile:

You provided the explanation yourself. If you want to host Internet-based services behind a NAT enabled router that relies on ports, you have to forward the port in question. Otherwise you need to get the ISP to use static translations (Either NAT or PAT)

You are partially correct here. The connection to your public IP is already made. But this connection is dynamic, which means your public IP address may change. Setting up port forwarding to your ISP-provided public IP address won’t work in your case. You can however port forward the other way, from your router to the specific host inside your LAN. Just make sure your host listens to the specific port and that it’s not a random one.

As I tried to explain earlier, some Internet based services relies on true end-to-end connectivity (eg. Battlenet, Torrents). Your ISP would normally support that even when NAT is employed, but not all router equipment does. Older routers and similar equipment doesn’t do that (or doesn’t until a firmware upgrade is done)

Wrong. This has nothing to do with security, but routing. The infinite loops that you refer to are countered by employing TTL (TimeToLive) values inside the IP header. When you PING something, you can see the TTL counter at the end of each PING attempt. If the TTL field reaches zero before the datagram reaches its destination, the datagram is discarded and an ICMP error datagram (11 - Time Exceeded) is sent back to to you. The whole purpose of the TTL field is to avoid situations where undeliverable datagram keeps circulating and eventually swamping a system (eg. PING flooding)

Furthermore. Computer B in your example is on the same LAN as Computer A, so sending HTTP requests to the outside interface of your router destined for Computer A won’t work. Your router will only route Internet traffic to the inside and LAN traffic to the outside. Thats a routers main function anyway :slight_smile:

Not really. Firewalls doesn’t route packets. It’s not their primary function either. I don’t want to burst your bubble here, but COMODO firewall doesn’t intercept packets and route them based on “Zone Rule” precedence. COMODO Firewall, or any other firewall for that matter, either permits or denies traffic based solely upon access-filters and rulesets. Your packet will either pass the firewall or get dropped based upon this. Some firewalls however can provide secondary functions such as basic routing, but these are uncommon for the private market.

The core problem you are referring to here isn’t an uncommon one. There’s lots of discussions on the Comodo forum that revolves around peering softwares like the one you mentioned and similar ones (Azureus, uTorrent etc.). Here’s the link toe the FAQ. You might find the answer to what you’re looking for here :slight_smile:

THAT is why this is a Feature Suggestion.

Just please add it.

Translating outbound packets for nifty work-arounds

I doubt the “feature” you’ve suggested is going to be implemented my friend…

Cheers though! Have a cold one on me :slight_smile:
:■■■■