Why your should never forward UDP out of your firewall
UDP is a connectionless protocol. As such, that means your firewall won't be able to tell so easily what UDP packets it should, and shouldn't, let into your network. For instance, its a trivial matter to create a bi-directional tunnel through any firewall, even a set of firewalls, using just UDP, unprivilged accounts, and fully NAT boxes on both ends. Impossible you say? Well, not with UDP it isn't. Read on for more about this.
Basically, it works like this:
A -> NAT_A -> inet -> NAT_B -> B
A sends packets to NAT_B on some UDP port, preferably a high port so B can setup a listener with no priviliges on that high port, but it doesn't have to be, the port could be anything. Lets say port 10000.
NAT_B will drop those packets, because its not listening for anything on that port. Just let A happily hammer away on that port. Meanwhile, have B send packets to NAT_A with a source port of 10000. NAT_A will accept those packets in and send them on A, because its already waiting for packets on that port, meanwhile, NAT_B, seeing UDP packets go out on its port 10000 will now allow in that steady stream from A. NAT_B will then send the packets on to B, and bingo! We have a bi-directional tunnel thru two NAT firewalls, from two NATed hosts.
So, what we have now is A and B talking directly to one another, with two firewalls doing all the heavy lifting and getting the packets to each other. Since we're using UDP, we can route an protocol we want over UDP, such as IP, or TCP. UDP is the protocol of choice for this sort of tunneling as it won't choke or stall trying to do all that nifty traffic management tricks that TCP would - and TCP is a terrible protocol to build tunnels over. You can do it, but things can go horribly wrong (we'll cover that in another article).
So, what can you do now? Anything you like. Which is why you don't want to let UDP out of your network. Tis a frightfully easy protocol to open your network up with.
