I have a windows server 2008 machine on which I am unable to bind to a socket at a particular high-port range without getting an error 10013 (WSAEACCES). In particular, I can't bind to ports 62788-64764, which is rather inconvenient since I'm trying to start up a service that is configured to run on ports in that range, and I can't change that configuration. The process is launched from a cmd window having Administrator privileges.-a
Why can't I bind to these port numbers?
I've tried all the obvious things:
Netstat -a does not show any processes listening on those ports.
Using netsh int ipv4 show excludedportrange protocol=tcp, I verified that there aren't any excluded ports in this range:
Start Port End Port
---------- --------
80 80
443 443
8172 8172
47001 47001
The machine was running a DNS server, so I set the DNS SocketPoolSize to zero, but that didn't work. (I even shut the server down, but that didn't help either).
I've rebooted (and kicked) the machine several times, and I've reset the winsock catalog (netsh winsock reset).
There's got to be some other configuration setting I am missing; any ideas?
UPDATE: I discovered that shutting down the Windows service "Internet Connection Sharing" makes the problem go away, although why that service was locking up these specific ports is still unclear to me.
I'd guess with ICS enabled, Hide NAT is also enabled (internal IPs hiding behind a single - or multiple - external IPs). That means the Server will need to rewrite source IP and source port of clients going to the internet to avoid source port collisions.
Hiding NAT gateways thus usually reserve a port range in the higher area (>port 50000) for that. So ICS may block a whole range of high ports for NAT porposes.
And this is why server applications should stay in the low / privileged range of ports (i.e. <1024)
Related
I have setup a simple HTTP java server running locally on port 8000. It simply prints a message "Hello world" when a request comes. When I try to ping it from the browser by running http://localhost:8000/test I get my message printed.
I want to get the same results from another computer that is not local. When I try to use my public IP lets say http:/43.xxx.xxx.xxx:8000/test (even from the same machine) I get an ERR_CONNECTION_REFUSED .
I probably suspect that has something to do with the firewall. Can anyone guide me a little more because I lack the experience?
Thanks in advance
You don't specify what host OS your server/firewall is running so I'll keep this generic...
Without knowing your application, it seems like the server is sending a reset (RST packet) when the first SYN packet shows up indicating that the port (on that interface [your external]) is closed. You can do a quick port scan from here (https://mxtoolbox.com/PortScan.aspx) if you don't have access to a remote machine to test with. Odds are, TCP/8000 will not be open.
If it is, in fact, closed, you'll have to look at the firewall that your host OS is running and find out how to allow TCP/8000 to your host. In a major firewall vendor, your rule would look similar to this:
Source: Any
Destination: Your Public IP Address
Service: TCP/8000
Action: Allow
Logging: Full
That being said, you mentioned this was a PC so look into "iptables" (if you're running *nix) or the Windows Firewall (if you're running Windows) on adding firewall rules (Unfortunately I just joined and can't ask questions/comments, yet).
If you really want to find out what packet is being sent, run a tcpdump on your external interface (let's say eth1) (assuming your remote IP is 1.2.3.4 and your home public IP is 4.5.6.7):
tcpdump -nn -vvv -e -s 0 -X -c 100 -i eth1 host 1.2.3.4 and host
4.5.6.7 and port 8000
Here you're looking for the SYN/SYN-ACK/ACK for a successful TCP negotiation or SYN/RST if there is a firewall rejecting (not dropping) the TCP stream to the port.
Once the port is open on the host OS firewall, take a look at the application to make sure it's configured properly. If this were a standard webserver, you could take a look at the configuration files for the "Allow from" directives to make sure that everyone can access the site. If this is a custom application that you've created, you'll have to check this yourself.
I finally solved my problem. I needed to open a forwarding port in my router that maps my local ip address to the public. My router is TP Link so this what I did:
http://www.tp-link.com/us/faq-72.html
Also in order for this to work every time and not to have to reconfigure this every time I reconected to the router (because I get a new local IP), I have created a static local ip for my server following this guide:
http://www.tp-link.com/us/faq-182.html
Thanks for all the replies.
Target Goal: Be able to ping my VM which has a bunch of SOAP calls at localhost:1337/service.asmx
Current VM Settings: Set to Bridged with Replicate Physical Network Connection State enabled.
Known issues:
I cant hit the internet at all from within the VM. test via cnn.com fails.
I can hit localhost:1337 from within the VM
I cant hit VM localhost from the host computer.
What sort of adjustments am I going to need to make in order to open up my VM of MS Server 2012 R2 to the network for testing?
Since I set up a custom port: 1337 there was actually a firewall issue.
On the VM, set it back to NAT from Bridged (in the adapter settings)
On the Windows Virtual Machine, go into Firewall Settings.
Go into Inbound Rules.
Add New Rule for the defined port.
save it.
Now the host can access via that port the page i created.
The Preamble
I start up my local SSH terminal at work behind a firewall, and connect to a remote server all the time without any problem.
The way Xdebug works, correct me if I'm wrong, is that it sends an "unsolicited" request to my network's port 9000. I actually initiated that action by sending the remote server an HTTP request through my browser with a POST/GET/COOKIE variable instructing xdebug to start up. But my network doesn't know that. All it knows is that it is getting a request on port 9000 from the internet. It doesn't know which computer in its private network to forward it to (without setting up port forwarding on the router), and can only ignore the request.
So if you can't do port forwarding, another option (and a much better one from what I can tell), is SSH tunneling. My computer sends the SSH request, the server responds. My router knows which computer in its network to route these responses to. Piggybacking on that SSH connection allows those "unsolicited" port 9000 requests from the remote server to get to me.
I think I understand that much.
I finally got tunneling to work, thanks to stackoverflow, but how it works is still fuzzy to me.
On the remote server, I tell Xdebug to connect to localhost (not to my ip via xdebug.remote_host=173.123.45.56, and not to xdebug.remote_connect_back=1 which also would end up at my IP) on port 9000. Connecting to localhost seems a bit weird, since I picture that as the server sending messages to its own IP address, as if it is sending messages into itself (but I think that connecting to localhost is probably fundamentally different than connecting to any other IP... I don't think the message gets routed out and back in to localhost).
On my computer at work, I open up an SSH connection on port 22, specifying a tunnel to/on port 9000, and remote port 9000. I've seen some explanations of the various settings here but still don't understand them. Some even seem to involve three machines. What seems to be happening though, is I'm connected as usual via port 22, but I've told the remote machine that I want to receive its port 9000 communications. I've specified "localhost" in my tunnel, and I suppose that might need to match the localhost in my xdebug.remote_host value. I wonder if I specified my IP address in both places (i.e. xdebug.remote_host=173.123.45.56 on the remote server, and same IP in my SSH terminal), would that work too?
So Xdebug on the remote server sends me a request to initiate a debug session. It comes through my port 22, but my SSH tunnel somehow makes it seem that it is coming in on port 9000. So my IDE that is listening on port 9000 receives the request and sends a response (also on 9000), which my SSH tunnel intercepts somehow and sends back to the remote server on port 22, where it is similarly spoofed into looking like port 9000 to xdebug.
The Crux
So what I'm really not clear on is, what exactly is the localhost in my SSH tunnel configuration referring to? Does it relate directly to the xdebug.remote_host=localhost value? Can I change them both to my IP address?
Are all of the remote server's outgoing communications on port 9000 being forwarded to me, or just some of them? E.g., if someone in Chattanooga initiates a debug session in their browser, will I receive Xdebug's response?
Are all of my outgoing communications on port 9000 being forwarded to that server? I.e. can I debug two applications on two different servers at the same time, with some of my port 9000 communications going one way and some the other, or would I need one port per local application? (I can use Google Chrome and Firefox browsers at the same time, both on port 80, for example.)
The tunnel consists of an SSHD listening to port 9000 (as well as 22) at your end and an SSHD listening to port 22 at the other end. When you connect your XDebug to your local 9000, the SSHDs intercommunicate and the remote SSHD connects to port 9000 at the remote. Thereafter your local port 9000 behaves identically to the remote port 9000: all data written to either end appears at the other end.
All connection attempts on RhodeCode on CentOS 6.3 are refused except from localhost.
Note that iptables is not running, and I am only trying to visit the web interface.
I have googled the exact error message below and looked around SO. I have yet to find a solution.
abort: error: No connection could be made because the target machine actively refused it
If the firewall is down, and I am not trying to modify any repository, what else is preventing me from connecting? EDIT: See #5 below. Not sure how to address it yet.
Things tried and other info
Using localhost, 127.0.0.1 and hostname in production.ini
service iptables stop
Connected over HTTP successfully. In other words, connections are accepted outside RhodeCode.
Made sure no authentication methods were enabled or configured in production.ini
Although the server accepts connections on localhost, netstat -l does not show that port 5000 is listening. Port 5000 is set in production.ini and ps uax | grep paster confirms the server is running. No other software tries to grab port 5000.
Ok, apparently I have been misunderstanding the host configuration. I was running on the assumption that host should be set to 127.0.0.1 or localhost in production.ini for RhodeCode to know what host to look for for another service. This was a faulty presumption on my part, since I am used to pointing web applications to local systems to look for databases.
It turns out that host binds the application to a specific address for access, meaning that it RhodeCode was supposed to only respond to local requests, regardless of what other system policies say. The setup docs did not make this clear because it did not specify that external connections would be refused. All it said was:
This command [paster serve] runs the RhodeCode server. The web app should be available at the 127.0.0.1:5000. This ip and port is configurable via the production.ini file created in previous step
The problem was fixed by binding RhodeCode to 0.0.0.0, which opened it to outside connections. Kudos to Łukasz Balcerzak for pointing this out in the RC support google group.
I need to scan the open ports of my server.
I tried nmap by: nmap ***.dyndns.info from within my local network.
It gave me:
Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-09 16:05 JST
Nmap scan report for ***.dyndns.info (***.***.***.39)
Host is up (0.00097s latency).
rDNS record for ***.***.***.39: ************.ne.jp
Not shown: 994 closed ports
PORT STATE SERVICE
23/tcp open telnet
53/tcp open domain
80/tcp open http
Then I tried the open ports tool provided by dyndns.com by specifying a specific port like:
global ip address 23
global ip address 53
global ip address 80
For each of those tests, it gave me "timed out" as a result, which is contradictory with the nmap results.
I know that depending on the way that nmap performs the tests, it may turn out that the result is "open".
So, I think the best way to test the ports of a given server is from outside, like the dyndns open ports tool.
But I'd like to test all ports at once, as opposed to one by one.
Is there any reliable tool for that, especially that I can use in command line?
I am on ubuntu 10.10.
Try Gibson Research Corporation ShieldsUP. It will test your firewall.
Note that whether or not a port is 'open' is also a function of the requesting source host and port; it is pretty easy to configure a firewall system to open a port for a specific set of source IP and port ranges. So there's no sure-fire way to tell if a port is open or not from the outside; netstat -an or similar tools will more reliably tell you which ports are open. (Except in the case of a rootkit, but any respectable rootkit would probably limit access to the open ports to a handful of netblocks as well, just to keep their property theirs.)
It'd be a piece of cake to buy a VPS slice from your favorite hosting provider for $10 for a month and portscan your own machine; nmap's default -T3 scanning option already parallelizes the scan, which is useful, but if your network connection is decent, -T4 may go more quickly.