7

I have enabled port forwarding on my router to do some testing with Nmap. The internal IP address 10.0.0.10 on port 4245 is being sent to my public IP address on port 4245. I can access this with x.x.x.x:4245

However, Nmap is reporting port 4245 to be closed. To be sure, I have specified the port number and disabled host discovery. I have tried this both over TCP and UDP. The commands I have tried are sudo nmap -sS -Pn -p 4245 x.x.x.x and sudo nmap -sU -Pn -p 4245 x.x.x.x

Both of these results show port 4245 as closed.

Note: x.x.x.x being my public IP address.

Improve this question
12
  • It's not fully clear from your description: you have configured your router to forward external IP port 4245 to some internal IP port 4245 and there is some internal device responding to port 4245 on this IP (i.e. nmap inside the internal network shows open or closed - and which one of these)?
    – Steffen Ullrich
    Commented Dec 20, 2016 at 5:42
  • I have configured my router to forward the internal IP address's port 4245 to the public IP address on port 4245. This way, I can access a device by going to X.X.X.X:4245 remotely. I can see this is working because I can access it public. However, Nmap cannot detect port 4245 (or any other port for this matter) as it is reporting closed.
    – Gavin Youker
    Commented Dec 20, 2016 at 5:47
  • Since you don't specify how you use nmap my guess is that you are using nmap in the default setting where it first tries to ping the device and the router simply does not respond to the ping so no further tries to check specific ports are done.
    – Steffen Ullrich
    Commented Dec 20, 2016 at 5:52
  • 1
    Use -Pn. From the documentation of this option: By default, Nmap only performs heavy probing such as port scans, version detection, or OS detection against hosts that are found to be up. Disabling host discovery with -Pn causes Nmap to attempt the requested scanning functions against every target IP address specified.
    – Steffen Ullrich
    Commented Dec 20, 2016 at 6:02
  • 1
    Because nmap will not scan the host if host discovery does not show the host is up. Have you tried? And it is -Pn not -pN
    – Steffen Ullrich
    Commented Dec 20, 2016 at 6:13

2 Answers 2

Reset to default
2

Long answer, see TL;DR below!

I don't think it's an Nmap problem, but rather a port-forwarding problem. I imagine you are scanning from the local network (if that's not the case, please ignore this).

Port forwarding often don't work from the local network, for a very simple reason. Suppose this is your network:

(A)--+
     |                    (           )
     |---(Rpr--R--Rpu)---(  Internet   )---(X)
     |                    (           )
(B)--+

A and B are two computers in your local network, both with private IP addresses, R is your router (which does the NAT and port forwarding), with one public address (Rpu) and one private (Rpr) on your LAN. X is a computer on the Internet, with a public address.

You have configured port forwarding on R so that packets arriving on Rpu:4245 (this means IP address Rpu, port 4245) are forwarded to A:4245.

When X sends a packet to Rpu:4245, it arrives to R, which translates the destination address to A:4245 and routes the packet to A. When A answers, it sends a packet from A:4245 to X. This packet is sent to R as its destination is outside the LAN and R is the gateway. R changes the source from A:4245 to Rpu:4245, and route the packet, which arrives to X as a packet from Rpu:4245 to X, everything is OK.

Now when B sends a packet to Rpu:4245, it sends it to R (because Rpu is outside the LAN and R is the router). Suppose R does the port-forwarding anyway, it sets the destination to A:4245 and routes the packet (from B to A:4245) to A. When A answers, it sends a packet from A:4245 to B. And this time it won't send the packet to R but directly to B, since B is on the LAN. The packet arrives to B as a packet from A:4245 to B, and hence cannot be seen as the answer to the packet from B to Rpu:4245, the source address does not match.

This could work if R also changed the source address to Rpr (or Rpu, or any address outside the LAN), because in that case, A would send the answers to R and R could reverse-translate the addresses, but that's probably not the case.

TL;DR. Run your tests from a computer outside your LAN with: nmap -sP4245 -p 4245 x.x.x.x (-sP4245 instructs Nmap to use a SYN packet to port 4245 during the ping scan). From your LAN, you can only check that the port is open by scanning (with the same options) your private address, but that leaves the port forwarding setting untested.

Improve this answer
0

If nmap is reporting a TCP port a closed this means that it got a response (RST) when it tried to initiate a connection to the service, if it had received no response, you would've got a filtered result which generally means "I got nothing back so I don't know what's going on".

Typically this happens where the port is open but there's nothing running on it (or nothing running on it that will respond to the request received)

A couple of thoughts on your problem

1) Where are you port scanning from? Typically I wouldn't try scanning your external IP address from inside the network, NAT is likely to get confused by that.

2) What are the results if you try to scan the internal IP address (10.0.0.10) from the internal network? Do you get an open response on that port?

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .