Can't port forward to client behind router+CPF

Condition:
-. A client behind Router+CPF host an online game (ie: Warcraft III - Port: 6112)
-. Rules created → Allow = “Any” to “Any” - Source Port “Any” - Remote Port “6112” - Direction “In/Out” TCP/UDP

Problem:
-. Any computer (Net) trying to join the game behind the firewall (LAN) will get stuck to resolve the game host, because CPF say → “Ok, 6112 = Allowed.”
-. CPF doesn’t forward the request to the host.

The allowed details:
-. Source IP (The client’s IP trying to joint the game)
-. Remote IP (The router IP’s)
-. TCP Flag: SYN
-. Remote Port: 6112
*. I’ve tried to set the “Remote IP” to the “LAN/Trusted Zone”

Help?

…anybody?

…somebody?

~_~…

#UPDATE#
I read the following post: https://forums.comodo.com/index.php/topic,210.msg1294.html#msg1294
I turn the Windows Firewall: on. And tell to forward the specific ports to the correct IP, and it works now.

…so, CPF still needs other instance to tell wich way to go, eh?

*. I think this should be move to the FAQ section.

Still…
There’s a problem with this configuration.

Condition:
-. A client behind Router+CPF host an online game (ie: Warcraft III - Port: 6112)
-. The host can receive (host) incoming trafic from the Net

Problem:
-. Additional client from the same LAN won’t be able to join the host

===============================================Another word
Comp-A:
-. Can host the game OK.
-. It can receive incoming connection from internet

Comp-B:
-. From the same Comp-A’s LAN/Network trying to join the game
-. Failed to join the game
==============================================/Another word/

Anyone with the light?

I’m thinking one of the initial issues is that you have not forwarded the incoming 6112 traffic on your router to your machine hosting the game. Doing that should eliminate the Windows Fire wall port forwarding… I’m kind of suprised that “worked” in the first place anyway. If your friends are using your routers IP, the router is going to say “Thanks for the packet, now what?” if there is no rule to foward to your machine from the router.

I’m wondering about the changes you said to add the remote IP to your trusted/Lan zone… I am thinking you may have wanted to make a separate zone rule for the remote IP(s), then add new Network and Application rules to control the flow.

So basically you would have 1 set of rules for your LAN, then a “duplicate” set of rule that control the remote PC communication. Trying to mix them is probably what caused you LAN PC to not connect.

Have you read my first post yet?
I said → “Any” to “Any”, “In/Out”, 6112, TCP/UDP
It means:
Any (Net, LAN, whatever…) connections to Any (Net, LAN, whatever…) either it’s Inbound nor Outbound would flagged “Allowed” by CPF if it’s 6112 TCP/UDP.

…and yes I’ve even tried puting additional rule, like:
-. Allow - Source IP (Router’s public IP) - to Zone LAN - source port 6112 - remote port “Any” - TCP/UDP.

Unless there’s something I miss, or you know something I don’t…
I’ll say it again…
CPF needs other instance to forward the port corectly from the Net to any client on the LAN.

Anyhow… this Warcraft port forward thing’s, probably the most popular technical discussion on the profesional gamers community right now.
…and if by any chance you CAN re-create my problem, …Dude! You’re a God!
…because any solution I’ve known so far is to use Linux’s Iptables.

Still… I’d like to be proven wrong tho’.

====================================Here’s how the Warcraft Battle.Net works

  1. Battle.Net server online
  2. Battle.Net server “Allow” 6112-6119 (the default supported port by Warcraft)
  3. User login to Battle.Net
  4. User create/host a game
  5. Battle.Net act as a lobby
  6. Battle.Net server annouce; “Yo! There’s a game open - by this IP:port (either it’s 6112 up to 6119; user’s preferences)”
  7. User trying to join the game will try to resolve the IP:port
  8. Hoster accept the connection from IP:port (random) to it’s original port (6112-6119)

====================================/Here’s how the Warcraft Battle.Net works/

What’s weird about all of this, is that the connection won’t go near the host whatsoever, even if you say: “ANYYYYYY!!! PLEASE!!! CPF, I SAID ANYYYY!!!”

…it’ll work with any PC directly hooked to the Net, allright.
But user behind Router + CPF will definetly need additional instance.

Anywho…
Being success to host the game isn’t enough.
Any client from (inside) the very same LAN as the hoster won’t be able to join the game.
Why?
Check out step 3 on the ilustration I stated above.
YES! You need to go to the internet in order to join your friend’s game.

…any example I found from various site, show’s that Iptables can re-routing this trafic pretty smart.
…is that possible with CPF?

Sorry if I misunderstood your first post wisanggeni, I did read it… but I interpreted the rule you said you created as a rule you made in CPF, not a rule made in the router.

I was only trying to ensure you had made a rule in the admin page of your router. Obviously you’re saying you’ve done that.

It’s ok.
Still… I’m happy to see your attention.
You’ve just saved me from going on to my monoloque routine…

*. It’s 22.01 here. I need a sleep.
*. I hope gaming God would send their hero to solve this problem, tomorow

OK… this is WEIRD…
I found out, that turning Windows Firewall: OFF, won’t have any effect to the current port forward I’ve set on it. The port just kept forwarding itself thru CPF.

For example:
-. I port-forward 6112 to 192.168.0.20
-. Turned OFF Windows Firewall
-. The connection’s still VALID!
-. CPF’s log show’s it all
-. Any request to port 6112, gets directed to 192.168.0.20
-. Change the forwarding IP to 192.168.0.8
-. …and there you have it! CPF log’s will show any request to port 6112 will sudenly change to 192.168.0.8

…I really need to scratch my head now…
The Windows Firewall is OFF. But how come CPF understand the forwarding task?

Egemen, will you have a word on this?

*. I’ve tried turned the WinWall:OFF. Reboot the Router. …and it still finely forwarding the request!

Windows Firewall may enable port forwarding in TCP/IP stack of the Windows OS. So when you close, TCP/IP still forwards. In this case, Windows Firewall may be just acting as an interface to configure this stuff.

Egemen

I see…
Will this “wicked stuff” get fix in the future release?
Frankly, I or anybody else would have no comfort to a firewall that can’t handle stuff they should.

*. Chances are… any simple script can execute netsh.exe and put a code or two, and CPF would allow that! …UFF! Scary…

[EDIT]
Inside look to Netsh: http://technet2.microsoft.com/WindowsServer/en/Library/6c7033fb-2bbb-48a8-8ff2-be435b2cd8a11033.mspx

Take a look at the “Netsh Commands” section!
You can see how devastating this thing can be; if it ever combined with a simple SSH Tunneling engine, and nothing to control over it.

…another Windows “feature” (?)
[/EDIT]

Can you please describe your problem and threat description with a more complete english sentences. Sorry but i am not following you.

You asked why while i disabled windows firewall, port forwarding still worked. If this is a bug, it belongs to Microsoft. CPF does not do any port forwarding.

You can do any sort of scripting, hijacking, infection etc. It is not easy to bypass CPF. But if you can describe the threat in your mind better, we can see if we miss something.

Egemen

If I do something like this (from command prompt):
netsh firewall add portopening ALL 22 ENABLE ALL (which will open-up TCP/UDP port 22 and applied that to any profiles and scope/Ethernet Card), it’s not bypassing CPF?
That’s a port opening right? Would that still be stealthed away by CPF? …because I DON’T see that stealthy-thingy at my example (July, 11-2006), which indicated; that CPF will allow every traffic thru’ it. …hey, there’s no current software holding those port. …but the traffic DO bypassing CPF, right? …and the so-call WinWall is OFF.

…and you say, it’s not easy??? With this example, HOW HARD easy is?

With current pop-up (and it’s reference), I can see any software trying to be some application’s parrent. …but the explanation at the pop-up message, sometimes can missleading any user to pick the wrong decition.
I have one or two installer which, after they install the application I want, will sometimes try to open-up their own website with a welcome or congratulations page. …Firefox for example. Thing is, instead explaining the unknown *.exe, CPF’s pop-up instead display the known application.

Example:
-. Installing K-Lite Codec Pack.
-. After installation, the installer with try to launch default browser and display their update page.
-. Here’s CPF’s POP
-. Message displayed at CPF’s pop-up, will say something like firefox.exe is a safe application. …and underneath that, explained a hijacking attempt by “c:\document~bla…bla…\local settings\bla.exe”
-. A trigger happy user seeing the “safe application” will allow that attempt.
-. This things goes to svchost.exe, etc…

…I believe you know tunneling better than I do.
So, if I try to zombified a computer, I can simply executed netsh, do some port forward and routing (this sort of things doesn’t yield CPF’s attention right?), and finaly executed the tunneling machine (let’s name it “officesystem.exe”) via svchost, or any safe-known application.
And when the pop-up POP, there’s a chance a user will be more than happy to allow that connection.

*. So CPF doesn’t port forward things. Thanks for the info.
*. This is indeed one of those Windows “feature”. …but shouldn’t CPF handle this stuff away?

Would this possible defect be sidestepped if CPF deactivated the windows firewall during installation (with the users consent, of course)?

Just a thought.

Ewen :slight_smile:

Ok Lets go step by step.
For example lets assume we added the following port forwarding rule :
netsh firewall add portopening TCP 80 8081

Which will forward all requests for port 80, to port 8081.
In this case, when a request comes to your PC on port 80, CPF will see it before it is forwarded to 8081 and apply network rules. Say it is allowed. Then Windows firewall will forward the request to port 8081. If the request is destined for your host, an application will receive a connection on port 8081, in this case, CPF will ask you about the connection reception or must have already asked it.

Since CPF sees packets before windows firewall, it all depends on your network monitor configuration.

If the packet is not destined for you computer but for another computer, then CPF will apply filtering while the request leaves the computer.
Ofcourse, default network configuration of CPF is not for gateway PCs. It is for personal computers. You will need to shape your traffic.

With current pop-up (and it's reference), I can see any software trying to be some application's parrent. ...but the explanation at the pop-up message, sometimes can missleading any user to pick the wrong decition. I have one or two installer which, after they install the application I want, will sometimes try to open-up their own website with a welcome or congratulations page. ...Firefox for example. Thing is, instead explaining the unknown *.exe, CPF's pop-up instead display the known application.

So can a trojan add a port forwarding to my computer without being detected? It will need to communicate with svchost.exe over COM to do so, in which case, CPF should warn you about this hijacking attempt.

Another example : Assume a trojan listens on port 8081 and you allowed it to do so. And we have used windows firewall port forwarding to forward 80 to 8081. Unless you dont have a ALLOW TCP IN TO PORT 80 in network monitor, CPF will not pass any requests and block them before being forwarded.

Lets go over step by step on scenarios to see what is happening so that we will determine the threat accurately. If there is something wrong, we will always fix it immediately.

Thx,
Egemen

…my goal is to poisoning the gateway by using an active application. …which is heavyly need user intervention. Like, allowing the application’s rule (pop-up) by using missleading application’s name.
So… every traffic generated by this application would bypassing CPF. Thus I can start poluting the TCP/IP stack and start to ram my way around the local network.

The more I get into it, the more I see, that THIS is one of those crazy Windows “feature”.
And since you state; CPF is CPF; which is for personal use, I’ll say no more about this “feature” I found.

Thanks, Egemen.
Glad to see you up to the chalenge.
You ROCKS! (Tho’ Jin Kazama Rocks Harder than you… ^_^’ )

*. netsh is surely something surpricing to be found, yet unequal to it’s host defence system. …oh, well. ~_~…

How come COMODO can’t do port forwarding? And the Windows Firewall can?

This would be a worthwhile feature, that could be disabled by default, but can be enabled and used by the people who need it in these few circumstances.

cheers, rotty