I want to port forward a port for my webserver on a router which i don't have access to. I highly doubt UPNP is enabled.
Actually, you can (sort of)
Its a bit complicated and wont work all the time, but here is the gist of how it works:
Given:
RouterA with public IP 1.2.3.4
PC1 with private ip a.b.c.d (behind router A)
RouterB with public IP 5.6.7.8
PC2 with private ip e.f.g.h (behind router B)
Now, given an IDEAL solution (i.e. no PAT)...
Step A:
Send any message from PC1 on any port (10000 for this example) to the public IP for RouterB (4.5.6.7). This will register a.b.c.d:10000 -> 4.5.6.7:10000 on the NAT and PAT for routerA. RouterB will discard this packet (as expected because it wasn't requested).
Step B:
At the same time, continuously send a packet from PC2 to the public IP of router A (1.2.3.4) on the same port (10000). This will register e.g.f.h:10000 -> 1.2.3.4:10000 on RouterB's NAT and PAT.
Step C:
Now, here is where the magic happens:
PC2 is constantly sending packet to RouterA thus keeping the 'hole' open in RouterB for a response to come back. When PC1 send it's single packet out to RouterB, it will appear to RouterB as a response and therefore will be forwarded to PC2. Once PC2 receives this 'response', make sure one more packet goes out and stop sending continuous packets. This last packet will act as 'response' to PC1 and go through the 'hole' created in Step A. And voila! You now have NAT transversal. You only need to send a single packet every minute or so both directions to keep the 'hole' open.
NOTE: This ONLY works with UDP as it is connectionless (dropped packets are ok).
Now almost ALL routers use PAT, so you have to 'guess' what port to 'respond' to most routers will do an offset of +-10 (i.e. a.b.c.d:10000 -> 5.6.7.8:10010).
Just try a few in that range (-10 to +10 until you get a response)
the rest of the routers are random on their PAT. If so, you're screwed... Try the other direction (i.e init the connection the other direction). If that fails, you cant connect... sorry)
So from what I understand, you have a web server running where things needs to be forwarded, and a router port which you don't have any access to; and you want to connect this two.
I highly doubt there is way to do this, if only you had sudo access to your router, you can use iptables to redirect
Related
I would like to ask a general newbie question. I understand that for a computer in location A to connect to a server in location B, packets of data have to be sent to multiple data centers through multiple gateways and through multiple verification channels to ensure the connection request finds the right destination.
However after the connection is established, when the computer and the server send/receive data, do these data still need to go through [multiple data centers through multiple gateways and through multiple verification channels]?
Every TCP / UDP packet can have a different network path between source to destination. However the connection establishment of a TCP connection being stateful is all about what packet size, compression method etc.
At network layer- Connection is stateless. Please read about OSI model in detail also you can refer to this https://www.ccnahub.com/wp-content/uploads/2013/09/watermarked-pc1-comm.jpg It has good explanation of how OSI works.
A TCP packet being sent from computer A to computer B will be addressed to a particular IP address. If that TCP address is not on the local LAN, it will go first through the local LAN to whatever is designated as the local gateway. That gateway then sends it on over the connection to an external network. At that point, it will be delivered to some router in your ISP. That router will look at the destination IP address and consult a routing table to find where it should next send the packet. That will typically be another router elsewhere in the network. This continues and (assuming good routing tables in each router) the packet will get closer to its end desination on each hop. Eventually, the packet will get to a router that has a routing table that knows about either the actual IP address or the home gateway for that IP address and the packet will be sent to that gateway. That home gateway can then deliver the packet to that actual IP address. In some cases, there may be a private network at either end where private IP addresses/port combinations are converted to public IP addresses and vice versa.
If computer A sends multiple packets to computer B, they do not have to all go the exact same path, though typically they will (assuming no problems or congestion in the network between the two endpoints).
In this scenario where A and B are on different private networks, there is no direct connection between computer A and computer B so each packet has to follow the path from one router to the next until it arrive at the final gateway and then destination address.
However after the connection is established, when the computer and the server send/receive data, do these data still need to go through [multiple data centers through multiple gateways and through multiple verification channels]?
If the routers are doing their job appropriately, the very first packet takes the most efficient path from A to B that the network knows. There is no "better" way to send subsequent packets. Subsequent packets will follow the same process (to a router, router looks up in routing table where to send for next hop and so on). If the two endpoints are a long ways apart (in terms of network topology), then the packet may go through many routers. Routers are highly optimized pieces of equipment capable of passing off millions of packets a second as this is how data moves on any TCP/IP network like the internet.
There is no difference in how the first packet that initiates the TCP connection flows versus subsequent packets. At the network level, they are just packets traveling from a source IP address to a destination IP address. Once the connection is established, a reliability layer will be started to track packets that might get lost, initiate retransmissions, etc... but this doesn't have anything to do with how a given packet gets from A to B.
This could not be the right place, as it's not about pure programming;
nevertheless, as a simple web developer I find myself quite
ignorant on the subject of networking(Wikipedia usually mix
different subjects on the matter), and I feel as it is a "must" to know.
I sort of have an image of what happens when you write google.com
on your browser, and I don't know the whole process(I have a modem,
a router and a few computers connected to it. let's use my case for an example):
You write characters into chrome ->
there is some character encoding done to translate the address(ASCII or else) ->
DNS does something, not sure ->
your router receives a digital request from a computer's internet cable/WIFI, it saves the internal IPV4 address of
the sender in order to know to which computer to respond back. it sends the digital data to the modem ->
your modem receives digital data, and translates it from digital to analog ->
now your network provider does some work - >
the google server receives a request from an IP address - >
not sure how the google server handles the data, nevertheless it sends back data ->
service provider - > router gets translated digital data from the modem and remembers who sent the request, and sends it to the right person.
in order to optimize a web server or maybe to write a better code which involves networking, perhaps each beginner(such as myself) needs to understand this first? Thank you for your time.
EDIT: I did read wikipedia's OSI model, though it's not quite as helpful as I thought it would.
i will try to explain the idea, although its may be much ,more complicate - it depends on how deep you want to go ...
you write "www.stackoverflow.com"
your OS will try to resolve the www.stackoverflow.com to an IP address
since your OS probably cant, it needs to ask a DNS server
assuming you use an external DNS ( say IP=5.5.5.5 and your IP=10.10.10.10 which is on a different networks ), your OS will check if it knows how to reach 5.5.5.5
a default route 0.0.0.0/0 exists on your PC (this is also known as 'default-gw' which includes ALL internet, it points to your local router
an IP packet will be sent to the router MAC address with the DNS IP address in the destination
your router will probably change your private IP address to its own public IP address and will sends it to the ISP
ISP will route it to the internet until it reaches 5.5.5.5 which is the DNS
DNS will reply back resolving stackoverflow.com to an IP address
your PC now knows how to send packets to stackoverflow.com
packet will be sent to stackoverflow ip address (104.16.36.249) to port 80 (http)
stackoverflow web server listen to requests on port 80
once a packet arrives it will generate a response packet
it will send it back to you exactly in the same way
all that traffic can be seen with a network capture utility like wireshark, u can use those commands (windows) to verify...
ping stackoverflow.com
netstat -rn
ipconfig
nslookup
tracert -d
I am trying to achieve double NAT working with UPNP. My PC connection is as follows:
Internet -> Router 1 -> Router 2-> PC
I have successfully done port forwarding on the Router 2, but not able to do on router 1. Due to which packets from the server(which is on Internet) are not able to reach PC.
Gone through few document how to tackle but mostly found manual way like bridge the network or put the lan wire.
I am rather looking for the some recursive solution using UPNP protocol to do the port forward on both routers. I guess torrent, skype does the same.
How to get the network interface related to router 1 and then port forward on that Network ?
Any help would be highly appreciated.
Thanks,
Pawan
There is an IGD-PCP IWF specification that tries to solve similar problem, although it assumes PCP support on your "Router 1", not UPnP. So let's try to approach this issue from a pure theoretical point of view with two plain UPnP routers/NAT devices.
There are several distinct steps of UPnP communication as per UPnP Device Architecture version 2.0:
addressing
discovery
description
control
eventing
presentation
Addressing is of little interest for us, let's assume proper DHCP everywhere and be done with it. Eventing and presentation are also almost useless in our case. So the main things to be concerned about are discovery, description and control.
Discovery works via SSDP message exchange. SSDP uses UDP for its transport with port number 1900 (by default) and well-known multicast address.
Description starts with URL provided by the device at discovery phase, the control point (that is PC in our case) needs to issue an HTTP GET request on this URL and that means it uses TCP as a transport protocol with devices IP address (unicast).
Control starts with URL provided by the device in its description, and it uses SOAP on top of HTTP on top of TCP which in turn also means unicast IP for us.
So, what all of that means for double NAT is that in description and control steps of UPnP interaction we have zero problems communicating from PC to Router 1 as all of that is just standard TCP with unicast IP addresses. But to get to the description step we need to have a URL of Router 1, so let's take a closer look at how this URL is acquired the normal way.
There are two main mechanisms for discovery — advertising (when the device periodically multicasts some information about it) and search (when the control point sends multicast search message and the device answers to that with unicast response). Obviously, by default our PC behind the Router 2 can't get multicast advertisements from Router 1 and the Router 1 can't get multicast search messages from PC, so we have a problem here and the question now is whether there is a possibility for communication without multicast.
Luckily, the same architecture document says:
In addition, a control point is allowed to unicast a discovery message to a specific IP address on port 1900 or on the port specified by the optional SEARCHPORT.UPNP.ORG header field (which supersedes port 1900 for this use), searching for a UPnP device or service at that specific IP address.
...
All devices shall listen to incoming unicast search messages on port 1900 or, if provided, the port number specified in the SEARCHPORT.UPNP.ORG header field and shall respond if any of their root devices, embedded devices or services matches the search criteria in the discovery message.
And this means that if you know the Router 1 IP address (from Router 2 side, of course), you can (and most importantly, allowed by specification to) communicate with it with unicast UDP messages and that is also NAT-friendly, so not an issue to be done from PC behind the Router 2.
The only thing left is getting Router 1 IP address. Unfortunately, there is no easy standard way to do that, but you have at least two options: tracerouting (in whatever fashion you want) and brute force IP scanning (most probably, the potential set of IPs for Router 1 is limited).
Now you can communicate with the Router 1, but there is still one minor thing you should always remember while communicating with it — in any internal UPnP messages you should use Router 2 IP address (as seen from Router 1 side) and its ports. Like in NewInternalClient parameter of AddPortMapping action on Router 1 you should use Router 2 IP. This, BTW, raises a question of Router 2 IP, but you can get that via Router 2 UPnP ExternalIPAddress variable of WANIPConnection service (this service is required for IGDs to implement).
So, to summarize:
this technically can be done, although I doubt that any standard library would do that for you
two things you need are:
Router 2 "external" IP and you get that via ExternalIPAddress variable of WANIPConnection UPnP service
Router 1 "internal" IP (from Router 2 side), that requires tracerouting or scanning
given Router 1 IP you just need to use unicast messaging at discovery step instead of multicast
everything else should just work, with only caveat of using Router 2 "external" IP instead of PCs IP in the UPnP messages
With the upnpc cli tool I've been able to get Double NAT port forwarding working.
For my example, let's say I want port 6667 to be forwarded to my machine, 192.168.50.123, behind a double NAT. The first layer of NAT has the IP range 192.168.1.1-255, and then 2nd layer has IP range 192.168.50.1-255.
On a machine inside the 2nd layer of NAT, just setup port forwarding with upnpc like normal.
$ upnpc -a 192.168.50.123 6667 6667 tcp
...
$ upnpc -l # this will confirm the rule is in place
...
Now for the slightly tricky part. I now issue UPNP requests to the outer layer NAT. Since the usual SSDP discovery won't work, I have to specify the XML root description URL manually. It's often something standard like http://192.168.1.1:5000/rootDesc.xml, though on some hardware the port number is randomized. I find just port scanning the gateway address will eventually reveal it.
Now that I have the rootDesc url, http://192.168.1.1:5000/rootDesc.xml, I then issue UPNP command to the outer layer NAT:
$ upnpc -u "http://192.168.1.1:5000/rootDesc.xml" -a 192.168.1.XX 6667 6667 tcp
...
$ upnpc -u "http://192.168.1.1:5000/rootDesc.xml" -l # this will confirm the rule is in place
...
With the -u option instead of discoverying the rootDesc, it just uses the URL provided.
The address 192.168.1.XX should be the 2nd layer network's IP address on as seen by the 1st network. When running the first set of UPNP commands this will be shown since it's the "external" address from that NAT's perspective.
With that now setup, traffic will go like this:
<INTERNET> --> MY_PUBLIC_IP -> 192.168.1.XX -> 192.168.50.123
I thought I understood the whole thing about NAT etc but now I came to a problem.
First what I assumed:
Because there are not enough IPv4 addresses available we need another system.
The devices of today at home for connecting to the internet are a combination of:
1) A modem at the physical-level to change the type of signals on the wire.
2) A switch at link-level so you can connect multiple computers to the device
3) A router to connect all the computers to the internet and go beyond your home-subnet etc.
4) A NAT to allow all the internal computers to connect to the outside
5) A portforwarder to let connections from the outside to the internal network
What I call a NAT:
When making a request to the outside: the NAT-part of the device changes the source-port and the source-ip of the request coming from an internal computer. The new source-ip will be your public-ip. The NAT-part will hold a record in a table with this mapping: "original-ip, original-port, new-port".
When a reponse comes back, the NAT will check the destination-port and compare this with the new-ports is in his table. If it finds a match the NAT will replace the destination-ip with original-ip and new-port with original-port. As a consequence the response will be forwarded to the internal computer that made the request.
So, the NAT-part is for when a connection is initialized from the inside. When this request traverses the NAT, 2 things are changed: source-ip and source-port.
Then the portforwarder:
This part of the device will accept connections initialized in the outside-world to your network. It will look at the destination-port of the incoming request and by making a rule for that port-number it may change the destination-port and the destination-ip of the request to an internal ip. With these rules a request from the outside can connect to a computer on your internal network and thus the portforwarder changes 2 things: the destination-ip and the destination-port.
A: Before I ask my question, how is this explanation?
Now my problem is with the response after a request came from the outside through the portforwarder. Assume the right rules are made and a request came through portforwarding on an internal computer. So in the portforwarder the destination-ip was changed to the internal-ip of the computer and the destination-port was changed to the port where the service is running on. If this internal-computer is a webserver it will generate a response. So the destination-ip will be the request's source-ip and the destination-port will be the request's source-port. The source-ip will be the internal-ip of the computer and the source-port will be the port of the service.
Now that response has to go to the outside. So I assume it goes through the NAT to the outside?
So after passing the NAT, the source-ip will be the public-ip and the source-port will be random. Now I tested this with wireshark. I contacted a webserver behind a NAT and I saw the reponse was coming from port 80 ?! How is this possible? This indicates that the response of the forwarded request did not pass the NAT?
I rethought the concept and my new hypothesis is that when a connection is initialized from the outside, it will pass the portforwarder and reach the right computer. This will create a response and when this response reaches our "all-in-one"device, this device can recognize it forwarded the request of the response and will not change the source-port.
B: Is this indeed the case or is it done in another way?
Wikipedia says about portforwarding: "The source address and port are, in this case, left unchanged. When used on machines that are not the default gateway of the network, the source address must be changed to be the address of the translating machine, or packets will bypass the translator and the connection will fail." (http://en.wikipedia.org/wiki/Port_forwarding)
This confirms that the response of a forwarded request MUST go through the portforwarder again and not through the NAT so the source-port wont be changed. The portforwarder will change the source-ip to the public-ip.
Can someone verify this or give me another explanation than mine?
Now I tested this with wireshark. I contacted a webserver behind a NAT
and I saw the reponse was coming from port 80 ?! How is this possible?
This indicates that the response of the forwarded request did not pass
the NAT?
The webserver inside the NAT does not have to be running on port 80. It certainly is set up at the NAT to port forward and respond as if it were at port 80, but that doesn't mean much about the port the web server is actually running on.
Here is some ASCII "art" that may help.
**Internal Network** **NAT Router** **External Computer**
Web Server running at IP 9.9.9.9 port 80 IP 20.20.20.20
IP 192.168.1.7 port 4567
Request web page at 9.9.9.9:80
Forwards port 80 traffic
to 192.168.1.7:4567
Replies with the web page
Puts 9.9.9.9:80 in the
source field and sends
the page on
Gets the page from "9.9.9.9:80"
even though it actually came
from 192.168.1.7:4567
What I am asking is if two computers listen to the same port and a packet of information enters the router through the WAN Ip and the same port. Would the packet go to both computers? Neither? One or the other?
IE
computer 1 -(internal IP)-> 192.168.1.3 -(listens to port)-> 4444
computer 2 -(internal IP)-> 192.168.1.2 -(listens to port)-> 4444
computer 3 -(connects and sends)-> 24.157.358.45:4444
packet -> computer 1 AND computer 2
The code in VB6 is:
LAN.LocalPort = 4444
LAN.Protocol = sckTCPProtocol
LAN.Listen
I am using a WinSock object in the Microsoft WinSock Control 6.0 in VB6 Professional
If there is something that needs to be clarified I would be more than happy to.
The router won't send an inbound packet to either machine unless communication has already been established.
If 192.168.1.3 calls out to some other machine (e.g. 4.5.6.7) from its port 4444, the router will assign an arbitrary port on its external address (say 24.157.358.45 [sic] :5555) and pass the packets on to 4.5.6.7. 4.5.6.7 will send reply packets to 24.157.358.45:5555 -- because that's the only address it knows about -- and the router will relay those to 192.168.1.3:4444.
That's the normal course of things, but there are a lot of additional details to this scheme that make it possible to establish communication with a machine behind a router via trickery.
The system of having machines with private IP addresses behind a router with a public address is called network address translation (NAT); it's a pretty deep topic.
From my knowledge of routers, unless port forwarding is setup, the router will discard any packets sent on that port.
If port forwarding is setup, only one of the computers could be setup to receive the packets.
If the packet is an inbound request to establish a new TCP connection with a server that is running behind the router, the router must have an explicit port-forwarding rule configured, either statically in the router's configuration or dynamically via uPNP or SNMP, that tells the router where to route inbound packets on 24.157.358.45:4444 to, either to 192.168.1.2:4444 or to 192.168.1.3:4444, otherwise the packet will be discarded. So no, both of your listening servers will not see the same packet.
Once a TCP connection is established, the router knows which specific LAN machines are associated with which connections and will route incoming packets belonging to those connections accordingly.
The previous answers are correct, you need to enable port forwarding. If it is not enabled port 4444 will be closed on the router.
It sounds like you have multiple servers and want to forward to whatever server is turned on at the moment. This is not possible (*), the router does not care whether or not PC1 or PC2 are listening on port 4444, it will simply forward everything to the address configured in the port forwarding.
(*): Ok it is possible but it takes some extra work.
Solution 1: Trick the router into thinking there is only one server. Give PC1 and PC2 a virtual network interface with the same IP address and forward to that address. Make sure only one of these interfaces is enabled, having duplicate IP addresses in your network can have unintentional behaviour.
Solution 2: Make the router care about which server is on. You will need to write a program to run on the router (or on another server) that can detect which server is on and forward the packets accordingly. If you are using Linux the program iptables can be worth looking at.