There are two Windows10 PCs.
Both PCs are connected VPN even being connected phisical LAN.
I'm trying to have RDP connection between PC-A and PC-B for each direction as VPN connection is estblished.
However,RDP is allowed only one direction.
PC-A >>> PC-B is OK
PC-A <<< PC-B isn't OK
I captured packet each PC and each direction for the VPN interface.
The packet at PC-B in succeeded case shows client Hello after TCP's SYN and SYN+ACK.
However,the packet at PC-A in failure case doesn't show client Hello and even doesn't respond SYN+ACK.
So TCP Retransmission is sent three times from PC-B.
Does anyone know why PC-A doesn't respond SYN+ACK ?
PC-A can respond SYN+ACK When they are disconnected from VPN ,the phisical LAN alternatively works.
It't doesn't seem it is coused by VPN itself.I can have one direction of RDP even VPN is estblished.
Include public peer IP to the ACLs. Due to the natting, the return leg of the handshake was being sent using the public peer IP, hence after adding the public peer IP to the ACLs it should work.
I guess PC-A Firewall is blocking the incoming connections.
Have you checked the rules ?
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.
I have been analyzing packets sent out from my IP to a game server.
The connection to the server was getting reset for some reason and after packet capture, I could see that there are TCP RST packets sent at the time of the disconnection.
I have tried to use advance firewall to specifically only restrict the TCP RST packets to the game server to see if that will prevent this disconnection. However I am unable to specify the flag level details in the rules.
How can I accomplish this configuration?
Is there any third party firewall that can do this?
Thank you
Browser can send a request to web server and get response, it is easy to understand because every domain does resolve to one or more public network IP, browser can find web servers via public network IP.
Some clients have public IP like PPPOE, so, when I establish a Websocket connection between browser and server, server can send data to browser on a device that owns a public network IP device, but not every client has public network IP.
My question is how does server find browser without public IP in a lan via Websocket?
Part of the magic is Network Address Translation and is performed by the routers between the server and the web browser's computer.
The simple answer is the server never has to find the client because once a browser sends a request to the server and a TCP connection is established, that connection can be maintained for as long as necessary.
The TCP protocol has the keepalive concept where every so often a peer sends a probe packet to the client with no data expecting and ACK packet in response. This way the connection remains alive despite network inactivity and can be terminated where peer does not reply.
The WebSocket Protocol, a TCP-based protocol also defines a similar concept Ping/Pong in which either of the peers can send a Ping probe on demand once a connection is established. The peer must respond to a Ping frame with a Pong frame as soon as is practical. This checks for dead peers, in which case the connection would be dead.
I'm trying to send UPD packets from node A to node B, both are connected to internet through different routers.
I am able to send (and receive) UDP packets between them when they connected on the same network by giving the local destination ip adddress (192.168..) and port number.
Now I'm finding the dynamic ip address of node B using www.whatismyip.com and consider it as w.x.y.z
When I send the packets from A to this destination, I'm unable to receive them at B. I've also setup port forwarding on both the routers.
This is completely new to me. Is there is something else that needs to be done when I want to send packets to a node connected on another network? Please help!!
I can suggest something to check:
Port Forwarding in both the router are configured for the UDP protocol?
If you ping the remote address w.x.y.z, you receive a response? (check if the routers are configured to do so)
Verify also if there are firewall that block the UDP packet that arrives from the Internet (on the routers or on the target machine).
The thing that you can not receive them at B is because NAT will filter all the messages if you haven't build a connection in the netfilter's table. The way to solve the problem is to use a port mapping like UPNP or NAT-PMP. In this way, the destination node's specific port will receive any message from WLAN and send it to this node. But this needs your router support these protocols, if not, maybe you need to use ICE as a realy server to realize it.
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.