Jtdylktuy

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

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.

Possible reasons are (1) firewalls (2) wrong routing information (3) NAT somewhere on the path, even if you don't know about it.

Debug the network with traceroute and ping from both sides, see what is in between both computers, and see where the block is.

(As the question is 5 years old, it's unlikely to get more details...)

Just go into both firewalls or advanced firewall settings and create a rule for incoming/outgoing UDP with specific machine info or ips. Can also access via PS but I recommend going directly to the MMC or firewall.