UDP traffic not being allowed out

How have you been testing this? What type of UDP traffic is this?

There's nothing turned on by default that would prohibit UDP traffic that I know of.

I'm using a 3rd party MailServer product that has an Administration Client that uses TCP and UDP port 44337. It transmits the log data over UDP, and based on some tests here it would seem to indicate that the UDP traffic is not getting back to me.

I tested on the same scenario on another machine (not a linode) and had no issues, which makes me think there is some issue with the UDP traffic going out from my linode.

I can confirm that UDP services work on linode with a default install. I have OpenVPN in UDP mode with several remote clients and no problems.

Was your test machine on the same LAN as your client, perhaps? If that's the case, maybe your ISP or firewall is filtering? For testing, perhaps you could set up X/VNC on your linode and try to run your client from the same machine to see if UDP packets even make it to localhost.

Since UDP works for me, it's likely your packets are either getting dropped at your server before making it to the (virtual) NIC or in your ISP/client LAN. If you run the test client from your linode and it also fails, the packets are probably not leaving your linode. If it works, and if your other test machine is also remote relative to your current client, perhaps a linode support ticket is in order.

Unfortunately I do not have any X windows stuff installed on my linode.

I know that the issue is not my ISP or my Firewall here at my location. I tested the exact same setup to a friend's server, and did not have the issue.

Oh, I also had somebody in a seperate location connect to my linode with the admin client, and he observed the same thing as I did from my location, so everything is pointing to an issue with my linode, but I have no idea what it might be.

Is there a command line utility that I can use to test this? Is there some configuration I need to check on my linode?

@chapterthree:

Is there a command line utility that I can use to test this? Is there some configuration I need to check on my linode?

You can start by running:

$ iptables --flush

Just to make sure that you don't have any iptables rules in there that would be preventing UDP traffic.

I don't think I have any iptables setup, as I ran iptables -L yesterday and it displayed the same info as today:

root@g [/etc]# iptables --flush

root@g [/etc]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Well if that's the case, I'm not sure what else to suggest. My suspicion still points to a routing/firewalling issue, but you seem pretty adamant that that's not the issue.

I run UDP-intensive apps daily on my linode and have never had to do anything special to get them working.

Maybe it would be worth trying another UDP app just to make sure it's not a problem specific to your mail server app.

@anderiv:

Maybe it would be worth trying another UDP app just to make sure it's not a problem specific to your mail server app.
This is exactly what I want to do to help isolate the issue, but I'm clueless as to what tools or programs I can use to test to see if UDP packets are travelling from my linode to me. Any suggestions?

Would traceroute do it? I think traceroute is UDP based.

Well I found a UDP ping tool, hping3. After some testing I determined this was in fact a firewall issue. My firewall at home and work was not allowing UDP traffic in. Yeah I know, I'm a tard :)

Thanks for all the help

Also, btw, for future reference, you can test easily with nmap, too.

Example:

# nmap -sU -P0 -p <portnum> <hostname or="" ip=""></hostname></portnum>

The -sU says to do UDP only, -P0 disables an initial ping check for host up or down, -p says to send a query to a specific port, and is self explanatory. :)

Good stuff. I use it all the time for TCP or UDP (or both) scans or specific ports to see how things looks for a response if debugging ACLs.