What is TCP response packets?
How to meet this requirement in access-list on a router?
You probably want to look up stateful firewalling for whatever router you're using.
TCP response packets are basically any related TCP packets that come back after an initial SYN has been sent. Typically this would be either a packet with SYN+ACK set, or one with RST if the connection was refused.
Stateful firewalls keep track of not just the source and destination of individual packets, but what connection the packets belong to. By doing this they are able to distinguish between expected, legitimate replies to SYN packets (and others) and random or malicious unrequested "replies".
Related
When a firewall lets packets sent in response to a request pass, how does it know that certain packets are associated with a request sent from inside the network?
Does it keep track of TCP connections or does it use some kind of a session?
For example, my browser makes a request that goes through the firewall in the router and the firewall knows to let response packets through. On the other hand, if someone from outside makes a request to any computer inside my network, they will get blocked.
For TCP, it does keep track of connections.
For UDP, each outgoing packet creates (or refreshes) a temporary rule to forward inbound packets back to the local source of the outgoing UDP packet.
Which software libraries does exist for such task for Linux, Windows OS?
Does it exist some info in RFC how people should do it?
I'm interesting how can I create functionality for my C++ project like presented here in that software: https://secure.logmein.com/ru/products/hamachi/download.aspx
There is not much difference if you want to make a connection through TURN relay server. The only difference is how TCP and UDP creates connection and nothing else.
There are some big differences if you want to make P2P connection.
If you are in same network(behind same NAT): In UDP you send a stun binding request to your peer candidate and then if you get a response back then you know you are connected. Same in TCP you have to create one active socket on one side and one passive socket on another. And then send syn from active socket and receive it from passive socket and then send syn ack to the active socket. And then active socket send an ack and the connection is established.
If you are in different Network(behind different NAT): You have to employ TCP hole punching technique for making a connection. Because your NAT won't allow a TCP syn packet through if previously no packet was sent to the address the syn is coming from.
TCP hole punching in details:
You have to use a TCP simultaneous open socket. This socket acts in both active and passive mode. Both end needs to know each others private and public IP:Port.
TCP simultaneous open will happen as follows:
Peer A keeps sending SYN to Peer B
Peer B keeps sending SYN to Peer A
When NAT-a receives the outgoing SYN from Peer A, it creates a mapping in its state machine.
When NAT-b receives the outgoing SYN from Peer B, it creates a mapping in its state machine.
Both SYN cross somewhere along the network path, then:
SYN from Peer A reaches NAT-b, SYN from Peer B reaches NAT-a
Depending on the timing of these events (where in the network the SYN cross),
at least one of the NAT will let the incoming SYN through, and map it to the internal destination peer
Upon receipt of the SYN, the peer sends a SYN+ACK back and the connection is established.
From WIKI.
Also to learn about TCP simultaneous open connection read from here. To learn about NAT filtering behavior see this answer.
I started to learn Linux Networking and packets filtering. In the iptables documentation it is stated that:
If a packet is destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.
So, suppose there're 3 server apps on a host. Servers A and B are TCP servers, and C is UDP server.
Is it true, that if we receive an UDP packet, at IP level this packet is to be delivered for apps A, B, C? Or sockets of apps A & B wouldn't receive this packet at all?
TCP servers and UDP servers operate in very different ways.
At most one TCP server will listen on a given TCP port (corner cases ignored for the sake of simplicity). Connection requests (encapsulated in IP packets) destined for that port are "accepted" by exactly one process (more accurately, accepted by a process that has a file descriptor corresponding to exactly one listening endpoint). The combination of [remote_address,remote_port] and [local_address,local_port] is unique. A TCP server doesn't really receive "packets", it receives a stream of data that doesn't have any specific relationship to the underlying packets that carry the data (packet "boundaries" are not directly visible to the receiving process). And a TCP packet that is neither a connection request nor associated with any existing connection would simply be discarded.
With UDP, each UDP datagram is logically independent and may be received by multiple listening processes. That is, more than one process can bind to the same UDP endpoint and receive datagrams sent to it. Typically, each datagram corresponds to a single IP packet though it is possible for a datagram to be broken into multiple packets for transmission.
So, in your example: no, a server that is listening for TCP requests (a "TCP server") will never receive a UDP packet. The port namespaces for TCP and UDP are completely separate.
The delivery of the packet will depend on its destination port.
Lets assume that the servers A, B and C are listening on port 1111, 2222 and 3333 respectively, so when a packet with destination port 2222 is arrived, it will be delivered to server B.
My question wasn't well formulated, unfortunatelly. I understood it when I had seen the answers. Here is an explanation which I was looking for, it's from http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html#tth_chAp6: > When the process scheduler sees that there are networking tasks to do it runs the network bottom-half. This function pops packets off of the backlog queue, matches them to a known protocol (typically IP), and passes them to that protocol's receive function. The IP layer examines the packet for errors and routes it; the packet will go into an outgoing queue (if it is for another host) or up to the transport layer (such as TCP or UDP). This layer again checks for errors, looks up the socket associated with the port specified in the packet, and puts the packet at the end of that socket's receive queue.
When a host needs to resend a packet (whatever the payload), is there any field in the header that gets modified, so that you can tell that it is a duplicate packet?
No. IP packet are not resent, that's a function of the higher protocol layers.
Some transport protocols, e.g. TCP or SCTP have retransmission built into them that re-sends packets at that protocol layer, some application protocols, e.g. DNS, applies retransmission at the application protocol layer.
The IP layer does not know or care about this, there is no protocol fields that identifies a retransmission from a higher layer.
The SYN packet has the same source dest IP address & port with the established connection, so what will happen in this case?
The server will silently drop the packet since it already has a connection in the ESTABLISHED state, one of the four values from (client-ip, src-port, server-ip, dest-port) must be different for the new SYN to be accepted.
The server will attempt a new connection.
in tech terms it will send a syn,ack packet and wait for the client to finish the tcp handshake
and open the connection.
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
will explain the process alot better than me.
the server will send some information to identify the connection in its syn,ack packet.
and that information is used to keep that connection seperate from others.
Most the time, the ports will not be the same
but when it is, it can cause problems with low grade nat routers,
They try to rewrite that ports that are used, and can get the connections confused.