I'm connecting an embedded device to a remote server via TCP/IP using HTTP. I have two layers of routers, and am having issues connecting to the remote server if both layers are in place. My upper most router is 10.0.0.X, and my lower (local) router is 192.168.1.X.
If I bypass the 192.168.1.X router, and put my device and laptop on a hub connected to the 10.0.0.X router, my device completes the handshaking sequence to the server correctly. I see my SYN go out, the server responds with a SYN/ACK, to which I respond with an ACK. HTTP takes over from there.
If I plug my device and laptop into the 192.168.1.X router, and plug this router into the 10.0.0.X router, then I still see my SYN request go out, but I get no response from the server.
It seems to me that my 192.168.1.X router is blocking either my request from leaving, or the response from getting back in. I checked the (192) router settings, and the firewall is off (wide open).
I have Wireshark available on my laptop, and have considered sniffing the other side of the 192 router, but I don't know if I can the traffic, since I would expect the 10.0.0.X router won't pass them back down to other ports, even if they're there.
My questions:
Any ideas how I can debug this to see where the breakdown is occurring? Will Wireshark pick up those packets if the laptop is connected to another port on the router?
Why would one router pass the packets in both directions, while the other is blocking them one way or the other? It seems if I can answer this philosophical question, I might be able to deduce the real problem.
Thanks,
Chris
Related
The goal is to make an http request from the client browser to my server. Simple stuff; however I'm hitting a wall with the networking portion. In order to expose my server to WAN I have used one of my public IPs and NAT to translate to the private ip of my server on inbound traffic and to my public IP on outbound traffic.
The issue is that I can't make a connection. Specifically I can't get the last part of the TCP handshake. Using a test setup with Wireshark on the client and server I can see that the client send the SYN -> the server receives the SYN -> the server sends a SYN/ACK -> the client receives a SYN/ACK -> the the client send an ACK -> the server DOES NOT receive the ACK. It waits for a moment then does a retransmission. Eventually resetting.
I have tried adding various firewall rules even though I don't think it could be the firewall because the first packets make a successful round trip.
I've turned windows firewall off(the server)
I've tried disabling TCP checksum offloading
I've looked for network anti virus settings on the server and on the sonic wall(the router)
I would expect the the tcp connection to complete. I can't for the life of me think of a reason why the ACK would consistently go missing.
That is another thing. The behavior is consistent.
pings also work just fine.
NOTE: The server is actually a VM and the physical server that manages it is in my network.
Any guidance on what to try and where to look would be very much appreciated. Thanks.
UPDATE: I can make connection using port 5000(It's another port I have opened on the firewall). Port 80 still doesn't work though.
In my case this was caused by COX not allowing inbound traffic to port 80. I'm not sure why the first portions of the tcp handshake were getting through. If anyone can explain that part leave a comment.
Suppose I run Wireshark on my PC, and I'm connected to a router, how can Wireshark know about all the traffic from that router?
Isn't the router supposed to isolate each client and route only their own data to and from themselves? What actually happens behind the scenes?
Suppose I run Wireshark on my PC, and I'm connected to a router, how can Wireshark know about all the traffic from that router?
If you have a router that's connected to multiple LANs, then Wireshark, running on a machine connected to one of those LANs, can't know about all the traffic from the router unless the router has been configured to, for traffic that would otherwise not be routed to that LAN, send a copy of the packet on that LAN.
If you're talking about a LAN switch, so that everything plugged into the switch is on the same LAN, the situation is similar - the switch would have to be configured to send copies of traffic to the switch port into which the machine running Wireshark is plugged.
The ability to do that is a common feature in higher-end switches; a port can be configured to be a "mirror port". See the Wireshark Wiki page on Ethernet capture setup for details. I don't know whether any routers provide an equivalent of "port mirroring".
The isolation of packets to ports is the functionality of a switch.
A hub sends the packets to all ports.
But your router acts also as a switch. You can place a device in front of the router and sniff from there. This device needs to be a hub, a switch with a monitor port or a splitter.
Or you can use arp spoofing to manipulate the arp tables of the computers in the network. But that is mostly considered as an attack.
Cheers,
Chris
I'm trying to learn the basics of ARP/TCP/HTTP (in sort of a scatter-shot way).
As an example, what happens when I go to google.com and do a search?
My understanding so far:
For my machine to communicate with others (the gateway in this case),
it may need to do an ARP Broadcast (if it doesn't already have the
MAC address in the ARP cache)
It then needs to resolve google.com's IP address. It does this by
contacting the DNS server. (I'm not completely sure how it knows
where the DNS server is? Or is it the gateway that knows?)
This involves communication through the TCP protocol since HTTP is
built on it (TCP handshake: SYN, SYN/ACK, ACK, then requests for
content, then RST, RST/ACK, ACK)
To actually load a webpage, the browser gets the index.html, parses
it, then sends more requests based on what it needs? (images,etc)
And finally, to do the actual google search, I don't understand how
the browser knows to communicate "I typed something in the search box
and hit Enter".
Does this seem about right? / Did I get anything wrong or leave out anything crucial?
Firstly try to understand that your home router is two devices: a switch and a router.
Focus on these facts:
The switch connects all the devices in your LAN together(including the router).
The router merely connects your switch(LAN) with the ISP(WAN).
Your LAN is essentially an Ethernet network which works with MAC addresses.
For my machine to communicate with others (the gateway in this case),
it may need to do an ARP Broadcast (if it doesn't already have the MAC
address in the ARP cache)
Correct.
When you want to send a file from your dekstop to your laptop, you do not want to go through the router. You want to go through the switch, as that is faster(lower layer). However you only know the IP of the laptop in your network. For that reason you need to get its MAC address. That's where ARP kicks in.
In this case you would broadcast the ARP request in the LAN until someone responds to you. This could be the router or any other device connected to the switch.
It then needs to resolve google.com's IP address. It does this by
contacting the DNS server. (I'm not completely sure how it knows where
the DNS server is? Or is it the gateway that knows?)
If you use DHCP, then that has already provided you with the IP of the DNS server. If not, then it means that you manually provided the IP of the DNS. So the IP of the DNS server is stored locally on your computer.
Making a DNS request is just about putting its IP in the packet with the request and forwarding the packet to the network.
Sidenote: DHCP also provides the IP address of the router.
This involves communication through the TCP protocol since HTTP is
built on it (TCP handshake: SYN, SYN/ACK, ACK, then requests for
content, then RST, RST/ACK, ACK)
Yes. To clarify things: When your computer sends the request
FRAME[IP[TCP[GET www.google.com]]]
The frame is being sent to your LAN's switch which forwards it to the MAC of the router. Your router will open the frame to check the destination IP and route it accordingly(in this case to the WAN). Finally when the frame arrives at the server, the server will open the TCP segment and read the payload, which is the HTTP message. The ACK/SYN etc. messages are being processed just by your computer and the server and not any router or switch.
To actually load a webpage, the browser gets the index.html, parses
it, then sends more requests based on what it needs? (images,etc)
Yes. An HTML file is essentially a tree structure which can have embedded resources like images, javafiles, CSS etc. For each such resource a new request has to be sent.
Once your browser gets all these recourses, it will render the webpage.
And finally, to do the actual google search, I don't understand how
the browser knows to communicate "I typed something in the search box
and hit Enter".
When you type a single character, it is being sent to the server. The server then responds with its suggestions. Easy as that.
References(good reads):
http://www.tcpipguide.com/free/t_TheNeedForAddressResolution.htm
http://www.howtogeek.com/99001/htg-explains-routers-and-switches/
http://www.eventhelix.com/realtimemantra/networking/ip_routing.htm#.UsrYAvim3yO
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
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.
So right now I'm using only TCP for my clients - they connect to the server, open socket and freely getting packets.
But what if I will decide to use also UDP in my game? Will they gonna have to open ports? For example, if they are using a regular WiFi, can I send UDP to the client without having opening ports problem?
Thanks.
TCP and UDP are just two examples of transport layer implementations. Both of them are using term 'port' to determine which app should receive incoming packet, but they could be routed/filtered differently by routers/switches/firewalls/etc.
So the answer is no. You will have similar problems with opening ports. Just except 'TCP port xxx should be opened' you have to demand 'UDP port xxx should be opened'.
In most home networks firewall rules allow outgoing packets (requests) to any remote port (on your server for example, where this port should be opened). And when such a packet goes through a router - it creates temporary rule to allow answers come back to the local port from which request packet.
So, normal scenario is like that:
Packet originated from home computer with IP 5.5.5.5. Lets say it has source UDP port 55555, source IP address 5.5.5.5 and destination port 8888.
Packet reaches home router. As it is going from inside - router allows it to pass through and creates rule say for 2 minutes to allow packets targeted to 5.5.5.5 to UDP port 55555.
Packet reaches corporate router before your server. It has rule to pass packets for port 8888 so packet is allowed to go.
Your server receives the packet and processes it. In response it creates packet for IP 5.5.5.5 and UDP port 55555.
Corporate router allows response to go.
Home router allows response to go according to temporary rule.
Your computer receives the response.
Corporate computers and routers often more restrictive to ensure security, so second point could restrict packet if your user (IP 5.5.5.5) is in corporate network.
It is very simplified as in reality there's almost always things like NAT and rules are more complex... But in general it gives the idea how it works internally.