Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I notice when I send udp packets from computer A to computer B, B can receive the upd packets correctly but if I send udp packets from computer B to computer A the udp packets are not received

A and B are not in the same network, and they are all with public IP, they are not behind NAT.

does this mean there is a firewall in between which prevents A from receiving udp packets from B? if A sends some udp packets to B before B sends udp packets to A, will the firewall remember this and then allow the udp packets from B to A ?

I know TCP is stateful and so firewall have a lot of measures to block some malicious TCP packets, like TCP SYN flooding, but how firewall block UDP packets? are there any good articles about this?

because A is my computer in a office. I want to build a system so that a UDP program on A can receive packets from outside. But it seems the firewall filters all the incoming udp packets. I'm wondering, if I use a commercial UDP-based program, like UDP-based video streaming tool or website, can I watch videos?

thanks

share|improve this question

1 Answer 1

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.

share|improve this answer
    
A and B are not in the same network, and they are all with public IP, they are not behind NAT. –  user1944267 Mar 28 '13 at 11:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.