I have a TCP server which runs in localhost (127.0.0.1), I am trying to connect to the server by injecting SYN packets to the loopback interface, but the server doesn't answer them. These packets have the source IP of the Ethernet interface of my internet adapter (and not localhost IP).
I watch the SYN packet that goes to my loopback server in Wireshark, but the server does not answer it with a SYN/ACK. I think it is because the IP source is not 127.0.0.1, which for example is 192.168.1.24.
If I go to the browser and I connect to my localhost server it works fine, but the source IP that I am using is 127.0.0.1 and the destination IP is 127.0.0.1 too; the only difference between the packets is the source IP.
I want to establish a TCP connection with my loopback server (localhost) by using different IP source addresses than 127.0.0.1. Is that possible?
For example, a Loopback TCP SYN packet which comes from 192.168.1.24 to 127.0.0.1 should be answered by the loopbackserver?
Thanks and regards!
You can send packets to localhost via Npcap Loopback Adapter and get response from the counterpart (e.g. a process on the same machine). An example is Nmap, Nmap uses Npcap Loopback Adapter to scan the ports of localhost. The command is: nmap -v -A 127.0.0.1. Nmap is open-sourced here, so you can see its code about the implementation. If you think Nmap is too complicated, you can see the source code of Nping here, a ping tool shipped by Nmap. Nping also uses Npcap Loopback Adapter when pinging localhost, which works differently with the original ping shipped by Windows.
Using IP of one of local adapters or using 127.0.0.1 should be the same. You can run Nmap to test it. Whatever, using 127.0.0.1 is the best and recommended by Npcap when talking to localhost.
So I think the issue still relates to your own implementation.
Does the server bind() using INADDR_LOOPBACK? If so, you could try changing it to INADDR_ANY to see if that helps. See also man 7 ip.
(These links are obviously Linux-specific; if your platform is something else, then refer to the documentation applicable to your system. For example, if you're on Windows, then maybe refer to https://msdn.microsoft.com/en-us/library/windows/desktop/ms737550(v=vs.85).aspx.)
I solved the problem, thank you very much for your answers.
The problem was a bit stupid, I was trying to establish a TCP connection with the loopback server (localhost) with IP source addresses that were not in the range of the loopback, loopback gateway: 127.0.0.1, loopback netmask: 255.255.0.0; It cant accept packets from IP source addresses that are not in the range of 127.0.X.X ; if I do NAT and I translate the packet from for example 192.168.1.154 to 127.0.1.154 the packet is received by the server and I can establish the server connection, I do not know how I did not realize it before.
Thank you for the time, regards!.
I think too that maybe it is better to bind the server to other virtual network adapter and not to the loopback, I am studing this: https://github.com/Microsoft/Windows-driver-samples/tree/master/network/ndis/netvmini/6x
It would be fine to create a miniport driver and bind the server there, we would have the advantage of having our own gateway and netmask and the layer would be ethernet and not BSD loopback. Your opinions will be interesting for me.
Related
According to native GRPC implementation, here: https://github.com/grpc/grpc/blob/master/src/core/lib/iomgr/tcp_server_custom.cc#L381
all ipv4 addresses are changed into ipv6 before the socket is opened here:
https://github.com/grpc/grpc/blob/master/src/core/lib/iomgr/tcp_uv.cc#L191
At least on CentOS this leads to grpc server being unable to start listening.
Can anyone please clarify why was this conversion made, why not just forward all ipv4 and ipv6 addresses straight into the socket and let them be managed by their original addresses?
Right now I am considering commenting this conversion out because I need this server on the environment without ipv6, but I am not sure if I am going to break anything by doing this...maybe there is some hidden dependency on the fact that we are always listening on ipv6 address?
I am attempting to set up an apache2 web server on my raspberry pi. I am able to connect to it by doing http://localhost:8080 (8080 because my router blocks port 80). Although when I do http://my.pub.lic.ip:8080 the connection times out. I set up port forwarding so that requests going to my router on port 8080 go to my raspberry pi on port 8080. This does not seem to work but I'm also not sure if the port forwarding is the cause or if it is something else. Any suggestions?
Is your web server configured to listen on the network interface besides localhost?
https://httpd.apache.org/docs/2.4/bind.html
For example, to make the server accept connections on both port 80 and port 8000, on all interfaces, use:
Listen 80
Listen 8000
To make the server accept connections on port 80 for one interface, and port 8000 on another, use
Listen 192.0.2.1:80
Listen 192.0.2.5:8000
You can try using nmap by finding your router's public IP and on the raspberry pi type nmap my.pub.lic.ip This will show you what services are actually being published to the world. This gives more insight to the problem.
I got the web server up and running although for some reason it appears that my isp would only allow it to be hosted securely (as an https page)(I'm not sure if that's the right way to phrase it). To achieve this for free, I used cloudflare's ssl service. A tutorial to set it up for apache2 can be found here
I am forwarding some outgoing TCP traffic on LAN (eventually UDP as well) to a local (transparent) proxy server before sending them out on the internet. The packets are forwared correctly it seems, I can see the SYN's in Wireshark.
The problem is that accept() bound to a port X doesn't accept a connection with destination port X and a destination IP different from the proxy server's own IP it seems, which was something I expected.
Is there a way around this in Winsock or in Linux sockets? How can I achieve the accept() or similar?
Linux sockets have the option IP_TRANSPARENT. See the linux man page ip:
IP_TRANSPARENT (since Linux 2.6.24)
Setting this boolean option enables transparent proxying on
this socket. This socket option allows the calling
application to bind to a nonlocal IP address and operate both
as a client and a server with the foreign address as the local
endpoint. ...
As far as I know the option is not available for windows sockets.
I don't understand what it means to bind a socket to any address other than 127.0.0.1 (or ::1, etc.).
Am I not -- by definition -- binding the socket to a port on my own machine.. which is localhost?
What sense does it make to bind or listen to another machine or IP address's port?
Conceptually, it just doesn't make sense to me!
(This has proven surprisingly hard to Google... possibly because I'm not Googling the right terms.)
Binding of a socket is done to address and port in order to receive data on this socket (most cases) or to use this address/port as the source of the data when sending data (for example used with data connections in FTP server).
Usually there are several interfaces on a specific machine, i.e. the pseudo-interface loopback where the machine can reach itself, ethernet, WLAN, VPN... . Each of these interfaces can have multiple IP addresses assigned. For example, loopback usually has 127.0.0.1 and with IPv6 also ::1, but you can assign others too. Ethernet or WLAN have the IP addresses on the local network, i.e. 172.16.0.34 or whatever.
If you bind a socket for receiving data to a specific address you can only receive data sent to this specific IP address. For example, if you bind to 127.0.0.1 you will be able to receive data from your own system but not from some other system on the local network, because they cannot send data to your 127.0.0.1: for one any data to 127.0.0.1 will be sent to their own 127.0.0.1 and second your 127.0.0.1 is an address on your internal loopback interface which is not reachable from outside.
You can also bind a socket to a catch-all address like 0.0.0.0 (Ipv4) and :: (Ipv6). In this case it is not bound to a specific IP address but will be able to receive data send to any IP address of the machine.
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.