I have a local server written in C++ listening to inbound TCP connects using plain socket ::accept() and UDP recvfrom(). I have two problems with this that I wish to solve:
Can I programatically make Windows let me open the accept socket without it automatically being blocked by the Windows (software) firewall?
Are there any ports I can use that will allow my packets to pass through both Windows firewall and external firewall? Port 80 is often taken by things like Skype, but are there others? Will most external firewalls typically by default allow incoming UDP and TCP connects on port 80?
Thanks!
In general, network routers need Port Forwardng enabled for the listening port, and firewalls need the listening port opened. If you are using a uPNP-enabled firewall/router, then you can dynamically set up those settings programmmably via the uPNP API. But more times than not, uPNP is either disabled or unavailable, requiring manual settings by the firewll/router admin.
Related
Specifically, I have a Windows server (Windows 7), but the netstat -an command only shows whether ports are TCP or UDP. I thought these were the only kinds of ports, but node.js seems to distinguish between HTTP ports and TCP ports (example at bottom of linked page). I'm currently using node.js in a program that will run on my server, and it opens HTTP ports by default. These appear as TCP ports under netstat -an.
Is there a command line trick for distinguishing whether an open port on this server is HTTP or TCP? I make requests to my Information Technology office about ports that I need on this server, and they need to know whether these ports will be TCP, UDP, etc.
If necessary to use a remote client, I have a Mac that can do the job.
HTTP is an application protocol. Its definition presumes an underlying and reliable transport layer protocol. The transmission Control Protocol is commonly used. However HTTP can use unreliable protocols too (example SSDP).
Now to answer to your question:
netstat -lt : List TCP Listening Ports
netstat -lu : List UDP Listening Ports
If you want to know wether a TCP Port is running HTTP or not, you can check the standard port on HTTP (grep :80). The standard HTTP port is 80. The standard HTTPS port is 443.
All HTTP traffic is transmitted over TCP Ports. I think what may be causing some confusion is that the first node.js example uses the http module and the second example uses the net module.
The http module is built on top of the net module (which handles the TCP layer underlying HTTP).
Refer to: nodejs - net or http module
EDIT:
Only one process can bind to a port. If you're having difficulties connecting, shut down any other applications that may be using the same port, such as your Java Hello World server. Run netstat -an to make sure you don't see the port listed that you're trying to listen on in you node.js TCP server (port 1337) in the example. If nothing is listening on the port, fire up your node.js TCP server and run netstat -an again to make sure it's actually listening on the intended port.
Another suggestion - temporarily turn off the software firewall then use the telnet client on the local server to attempt to connect to the port using the command telnet 127.0.0.1 1337 (replace 1337 with your port) from the command prompt. This will eliminate any network devices such as firewalls between the client (telnet in this case) and the server. If the screen goes blank, you've connected. If you get the message Could not open connection to the host, on port then it's still not listening on the TCP Port. If you can connect locally from Telnet but you cannot connect remotely then there is something blocking your connection.
I am trying to find somw Windows based tools that can help me validate TCP and UDP connection on remote machines.
My Problem (just one use case):
At work, I manage many clustered servers that I run load tests against. In order to get a rich test, I use Jmeter-Plugins which provides a Server agent that opens a TCP socket on port 4444 on a target remote machine: http://code.google.com/p/jmeter-plugins/wiki/PerfMonAgent
There are many times when I setup a new load test farm, that either the network, or the server configuration, or the ServerAgent itself can have issues and thus not allowing a Load test client to access that TCP connection.
The issue I have is that I dont know what part of the system is broken.
What I think I need:
I would like to know how I can open a TCP (not HTTP with cUrl), connection to a remote server to validate that the network allows the connection, as well as the Server firewall allows the given TCP connection to be accessed remotely.
What I have looked:
These are some of the tools I have looked at so far:
Nmap http://nmap.org
Ncat http://sourceforge.net/projects/nmap-ncat/
TCP/IP Builder http://www.drk.com.ar
Zenmap 6.01 and nmap might do the job I want, but some machines where not accessible to Zenmap when I know 100% that the server was accessible via HTTP, so that was strange.
I have looked at many tools and either they:
Dont allow remote connections
Dont seem to want to connect to a TCP socket
Or I dont understand the tools to accomplish the validation I stated above.
I would greatly appreciate all comment and suggestions to help with this re-occurring problem I face.
Mick,
Firebind.com can do what you'd like to do. Firebind is an Internet based server that can listen on any of the 65535 UDP or TCP ports. It uses a java based client to send traffic to and from the server from your machine.
Carl
www.firebind.com
I am splitting an application into a tray application and a Windows Service and I want to use TCP to communicate between the two*. They will both be running on the same machine.
My question is do firewalls block TCP communication between applications running on the same machine? I want to know whether firewalls are something I need to worry about when testing.
(*note that I want to use TCP instead of named pipes for communication because the apps might one day run on separate computers but that will be far in the future)
The primary objective of the firewall is to control the incoming and the outgoing network traffic! Firewall's are designed to work on IP or PORT basis.
So yes, it is 100% capable of blocking connection on same machine.(I guess you are using Class A IP [127.x.y.x] address used mainly for loopback testing and interprocess communication on the local computer).
Some firewall are preconfigured not to block local machine connection while other are configured to block them. But either way a firewall can be configured to allow/deny such connection.
I am using Boost asio in Visual C++. I am trying to connect to a static IP which listens TCP on port 1222. unfortunately i can only connect with Lan and cannot connect from another Lan to the TCP listening PC(203.143..).
It connects perfectly with the EC2 server. Is it something to do with firewall. but when i run the app it ask for the user to allow firewall for the specific port. I can post my code but i guess it's not something to with the code.
Usually a firewall on the server side (the PC you are trying to connect to) have to be configured to allow incoming connections.
Firewall on your side should be OK, it usually allows any type of outgoing connections.
I don't know what you meant by "the app ask for the user to allow firewall for the specific port" (clarify).
I'm wondering whether or not it's possible to configure a TCP socket such that it cannot accept connections from 'off-machine'.
I want to spin up an HTTP server that should only be accessible from clients running on the same machine, and although I can always filter out 'unauthorized' requests from off-machine, I would prefer it if this local-only behaviour were baked-in.
Also, opening a socket on windows triggers a firewall warning and request for the user to block/unblock the port being opened. I'm hoping that a means exists to avoid this message, if the socket can be configured to only accept local connections.
Bind to loopback interface, ip 127.0.0.1.