UDP packet and firewall-Collection of common programming errors

Sounds like computer B is behind a NAT router. If this is true, then every machine behind that router will look like it has the same IP address from computer A’s point of view.

When NAT is involved, outgoing traffic causes the NAT router to remember the originator of that traffic for that destination IP for a while, so that when traffic is received from that same destination IP address, the NAT router knows who to “give the traffic back to.”

When the NAT router receives unexpected traffic from the “outside”, it doesn’t know who to “give the traffic back to” unless you tell it with port forwarding rules.

NAT isn’t really concerned with the type of traffic, except that some protocols don’t work well with NAT by default because IP addresses are coded into the payload of the protocols. NAT typically only modifies the source IP field of packets, but in the case of things like FTP a “helper” may be needed that modifies the actual payload of the packet.

A firewall can “block” a packet, of any type by:

• sending an ICMP message back saying the packet is rejected for a specific reason
• simply not responding at all
• then there’s hacky stuff like tarpits.

The only way “statefulness” affects that is that a firewall is going to usually treat new TCP connections very differently from existing ones – there will be “new” and “established” traffic.

UDP by definition is NOT a connection-oriented protocol, so there is no state to keep track of as far as OSI layers 2-4 are concerned. All incoming UDP connections are treated as “new” or the same.

The server or client that uses UDP to communicate may keep track of some state (a teensy bit of state is needed for things like TFTP to work – the TFTP client/server keep track of that on their own). But the TCP/IP stack isn’t supposed to.