This is more of a theory question for more understanding.
In order to do port forwarding we update sshd_config and provide the information of local port(a) and remote port(b) among which we need to perform forwarding. After this forwarding config is done, ssh tunnel will be used to forward packets between a <-> b.
But internally, how does this work? when I do https://localhost:a, how does packet move from port a to ssh tunnel port 22 and on the other side from port 22 to port b?
If you are interested about the internals, openssh is the most popular implementation of SSH protocol and it is open source with code available on GitHub.
To answer a bit your question, it works as every other network communication. If you are not familiar with it, check how network socket works. Port forwarding is doing just proxy between the ends and sends the data inside the encrypted channel, instead of outside as the direct socket would.
Anyway, it is easier to google a bit. Ubuntu has a nice explanation in their documentation:
To get the most out of port forwarding, it's helpful to know a bit about how the Internet works.
The Internet assigns computers virtual "ports", a bit like the USB ports on the back of your computer:
To let a digital camera share pictures with your PC, you connect the USB port on the camera to any USB port on the PC. The computer then talks to the camera about your photos, and shows you the result.
To let a web server share pages with your PC, you connect the web server port on the server to any Internet port on the PC. The computer then talks to the server about your page, and shows you the result.
Unlike a USB port, there is no physical component to an Internet port. There's no actual wire, or actual hole on the back of your computer. It's all just messages being sent over the Internet. Like other "virtual" computer concepts, Internet ports are just an analogy that help to explain what your computer is doing. Sometimes, that analogy breaks down:
There are two types of Internet port: normal "TCP" ports and strange "UDP" ports (which won't be covered here).
Unlike USB ports, every computer has exactly 65,535 numbered TCP ports, some of which have a special purpose. For example, port number 80 is your web server port, so your web browser knows it should connect to port number 80 in order to download a web page.
Connections between Internet ports can be patched together, so a connection from computer A to computer B on port 12,345 could be patched through to port number 80 on computer C. This is known as port forwarding.
Related
I created two Qt apps: one client and one server.
I use them to send some data for handle a remote device.
If I am in localhost I haven't issues about them, but when i search to connect them by internet i don't know how to find correct Ip server to connect Socket Client.
How i can find this ip node?
Is there a class to find It?
you cannot find it automatically, if this is what you're asking about.
In real life you would deploy your server on some publicly accessible host, give it a domain name (important part as your host can change the IP address at any time) and connect the client via the DNS domain.
However if you're just playing around and you want to show to the world that your app works, specifying the IP address of the server in your client code would be perfectly fine (assuming you're running both the server and the client in the same network).
In that case, if you're running mac/linux run the command ifconfig (or just ip depending on the distribution). On Windows you can run the command ipconfig. Both windows and linux will give you a similar output resembling this:
Pay attention to the network adapters. There can potentially be many of them. You may have some emulated adapters if you have docker or VMWare, you may have the wireless adapters if you have a WiFi card, and then the ethernet adapters if your computer can connect to the the internet with an ethernet cable. Each of these adapters specifies a different IPv4 address. You want to pick the one that is connected to the same network as your client. So for instance if both your server machine and your client running machine are connected to the same wifi, you pick the address from the Wireless LAN adapter
I've been investigating networking for use in a two-player game I'm writing, and I'm still not clear on when a device must have a port forwarded in order to communicate with the outside world.
From what I've seen in other games, port forwarding is always required in order to host a server, but is not required on the client. In addition, there are other situations, such as skype (which, to my understanding is ultimately client to client), where neither end must forward a port.
So my question is, in over-the-Internet communication, when is and isn't port forwarding necessary, and what steps can i take as a developer to make it so my users don't have to worry about it? Thanks in advance!
Port forwarding is needed when a machine on the Internet needs to initiate a connection to a machine that's behind a firewall or NAT router. If the connection is initiated by the machine behind the firewall, the firewall/router automatically recognizes the reply traffic and sends it to the machine that opened the connection.
But if a packet arrives on the external interface, and it's not a part of such a connection, the router needs to know what to do with it. By default, it will reject it. But if forwarding is configured for the port, that tells it what internal machine to send it to.
Put another way: you need port forwarding if you want to run a server behind the NAT firewall/router, you don't need it if you're just running a client.
There is reason why Skype don't (not always) need manual setting of port forwarding:
When you install Skype, a port above 1024 is chosen at random as the
port for incoming connections. You can configure Skype to use a
different port for incoming connections if you wish, but if you do,
you must open the alternative port manually.
If the port chosen for incoming connections becomes unavailable, by
default ports 80 and 443 will be used as alternatives. If another
application (such as Apache HTTP server or IIS) uses these ports, you
can either configure the application to use other ports, or you can
configure Skype to not use these ports.
Port forwarding is must if you host a server.
You can use same technique as Skype...
I am not sure if there is any other option...
Port forwarding (occurs) when a NAT, firewall or some other device blocks communication on all or some ports.
To answer your question as an example, most commercial routers use NAT to allow multiple people to use the same IP(As view from the outside world) provided by ISPs. Most ISP's use NAT to allow multiple customers to use the same IP(As viewed from the outside world). To get this to work, the NAT changes the internal IP and the port number of a communication to THE(there is only one for the entire sub network) external IP and a new port number. By doing this, the router/isp/ect can tell which internal IP and port each external communication goes to.
Anytime one of the computers communicating over the internet are behind a NAT, port forwarding is required. I'm sure there are way more situations than this, and the solution to each can be quite complicated. But this covers the vast majority.
I did a test of NFS service over Cisco ASA 5505 firewall.
With normal interface default ACL, which is "permit ip any any" on inside interface (Level 100), "deny ip any any" on outside interface (level 0). NFS server is connected to outside interface. Everything works great. By look at the the packets go through, I can see inside PC call NFS server's 111 port, negotiate a port using portmap. Finished this TCP connection. Then NFS server (outside PC) use the negotiated port to connect to inside PC and transfers data. Cisco ASA firewall keep TCP states very well and "remembered" the negotiated port, thus let outside PC using this port to talk to inside PC even the outside ACL is "deny ip any any". The firewall is fully stateful, every thing is great so far.
However, as long as I connected the NFS server (outside PC) to Cisco ASA firewall using VPN. Everything changed. By look at the packets, NFS can still go through firewall and negotiate a port by portmap. While after this TCP session is over. Firewall FORGET the negotiated port and block the outside PC using negotiated port to talk back to inside PC.
With or without VPN is the only change. There is just one ACL, on inside interface, permit ip any any. The NFS server is set to can be access from any subnet. There is no NAT and no service-policies setup on this firewall.
Can anyone please explain why Cisco Firewall rules is not "stateful" anymore over VPN? Is it designed to be? What is the best way to let NFS working over VPN without open a range of dynamical ports on outside interface?
One of the strong sides on NFSv4.0 is firewall friendly. No port map required. You need only single TCP port 2049 to be opened. All operations which have have a state on the server require client to send a heard bit, which is typically ~ 90 seconds. We you is in your firewalled setup and quite happy with it.
Im not too sure why this wont work. My application works fine if the client and server are ran on the same PC hence the 127.0.0.1 but it wont connect to my other laptop using IP 82.41.108.125 which is the IP of that device.
Any reason why this is happening?
Your firewall could quite possibly be blocking the port assuming all of your coding is working fine - try opening up the port number you're running the application on (in the client/server comptuers' firewall options).
Some additional information that should shed some light on things
Networked devices use ARP (Address Resolution Protocol) and RARP (Reverse Address Resolution Protocol) to map IPs to link layer (MAC) addresses and back. Your network interface card (the thing that plugs into your ethernet cable) will have a unique MAC address on both computers. Each PC has an IP configured for it which is used by higher level protocols (those in the Network Layer).
Computer A will know computer B's IP address (and it will be different from computer A's) if your program works correctly. When computer A goes to send to comptuer B, assuming they're directly connected and not going through a router or something in between, computer A's link layer will need to translate that IP for comptuer B into a MAC address it can use. It does this by sending out a broadcast to all network PCs on the same sub network asking "Hey, is this your IP!?" essentially. The one that has an IP matching the broadcasted one yes, "Yes, it's mine - and here's my MAC address so you can talk directly to me."
So, if two computers have the same IP this all goes to hell :) don't do it - give them unique IPs and make sure that comptuer A transmits to the same UDP port and IP that computer B is listening on as well. communications work in {IP, Port} pairs - its like a telephone number and area code.
Also...
As said by EJP - UDP is a connectionless protocol - computer A just sends to computer B and hopes that computer B is listening correctly. If computer B wasn't listening or was but wasn't in the right state to process the data, the data will simply be dropped and lost. Computer A will not know that this happened. If you want reliable communications where it will keep trying and you will have assurance that compuer B received computer A's data then use TCP instead - it does a 3 way handshake to establish a connection and uses acknowledgements to ensure data is retransmitted when it doesn't reach the other end.
It could be that you're listening on localhost (127.0.0.1) and don't accept other traffic. Use a wildcard address.
Check on the server with netstat -npu.
If that's not the case then it's probably firewall issue, verify with tcpdump or wireshark.
Check firewall on your laptop... Most of the time that acts as spoilsport.
If I understand right, applications sometimes use HTTP to send messages, since using other ports is liable to cause firewall problems. But how does that work without conflicting with other applications such as web-browsers? In fact how do multiple browsers running at once not conflict? Do they all monitor the port and get notified... can you share a port in this way?
I have a feeling this is a dumb question, but not something I ever thought of before, and in other cases I've seen problems when 2 apps are configured to use the same port.
There are 2 ports: a source port (browser) and a destination port (server). The browser asks the OS for an available source port (let's say it receives 33123) then makes a socket connection to the destination port (usually 80/HTTP, 443/HTTPS).
When the web server receives the answer, it sends a response that has 80 as source port and 33123 as destination port.
So if you have 2 browsers concurrently accessing stackoverflow.com, you'd have something like this:
Firefox (localhost:33123) <-----------> stackoverflow.com (69.59.196.211:80)
Chrome (localhost:33124) <-----------> stackoverflow.com (69.59.196.211:80)
Outgoing HTTP requests don't happen on port 80. When an application requests a socket, it usually receives one at random. This is the Source port.
Port 80 is for serving HTTP content (by the server, not the client). This is the Destination port.
Each browser uses a different Source to generate requests. That way, the packets make it back to the correct application.
It is the 5-tuple of (IP protocol, local IP address, local port, remote IP address, remote port) that identifies a connection. Multiple browsers (or in fact a single browser loading multiple pages simultaneously) will each use destination port 80, but the local port (which is allocated by the O/S) is distinct in each case. Therefore there is no conflict.
Clients usually pick a port between 1024 and 65535.
It depends on the operating system how to handle this. I think Windows Clients increment the value for each new connection, Unix Clients pick a random port no.
Some services rely on a static client port like NTP (123 UDP)
A browser is a client application that you use in order to see content on a web server which is usually on a different machine.
The web server is the one listening on port 80, not the browser on the client.
You need to be careful in making the distinction between "listening on port 80" and "connecting to port 80".
When you say "applications sometimes use HTTP to send messages, since using other ports is liable to cause firewall problems", you actually mean "applications sometimes send messages to port 80".
The server is listening on port 80, and can accept multiple connections on that port.
Port 80 you're talking about here is the remote port on the server, locally browser opens high port for each connection established.
Each connection has port numbers on both ends, one is called local port, other remote port.
Firewall will allow traffic to high port for browser, because it knows that connection has been established from you computer.