# iptables ignoring UDP? [SOLVED]

## nixscripter

I am running a firewall, and it seems to be dropping my UDP packets. I presumed my hand-configured iptables was the problem. During my debugging, however, I was quite surprised by a result.

I decided to make sure the UDP packets were getting somewhere at all. So, I put in this rule on the firewall:

```
server# iptables -t raw -I PREROUTING 1 -p udp -j LOG
```

The raw table's PREROUTING chain should be the first to capture anything that touches the server, before any other rules are processed.

And then, on a client behind the firewall, did this:

```
client$ stunc server -b -r
```

I didn't expect anything, I just picked a number.

And after a few:

```
stun_sendto_timer_cb: Timeout no. 1, retransmitting.

stun_sendto_timer_cb: Timeout no. 2, retransmitting.

stun_sendto_timer_cb: Timeout no. 3, retransmitting.
```

I checked the server. No messages. I am certain of my configuration for message logging (warnings go to the right place).

Apparently, the packets are not getting in there, or not getting processed. The only thing in between them is a switch, and that and shouldn't affect this. I saw the packets go by as the data lights flickered

The nf_proto_udplite modules were not loaded by default. Is that a clue? Did I somehow fail to include UDP support in the kernel or something?

What piece of the puzzle am I missing?Last edited by nixscripter on Thu Oct 01, 2009 4:10 am; edited 1 time in total

----------

## barophobia

Does tcp connection work?  Does ping work?  Does udp stuff work with another machine?

output of iptables -L -v?

turn iptables off completely?

----------

## nixscripter

This morning, it works. The UDP packet logging, that is. So they are getting there, but not being routed, as I suspected.

So, for the configuration, the basics

1. Pinging the server and any other server on the internet works.

2. All TCP services work.

3. DNS works -- but only to the firewall. The firewall is running dnsmasq.

4. DHCP works -- the firewall issues all addresses on the private network.

I have tried a lot, but here is the configuration that is failing. eth0 is the external NIC, eth1 is the internal NIC. I have also tried the RELATED,ESTABLISHED state in the FORWARD chain, but it didn't work.

```
# Generated by iptables-save v1.4.2 on Wed Sep 30 07:14:14 2009

*mangle

:PREROUTING ACCEPT [311713:450234482]

:INPUT ACCEPT [299077:442201696]

:FORWARD ACCEPT [10524:7210578]

:OUTPUT ACCEPT [151435:8587098]

:POSTROUTING ACCEPT [161959:15797676]

[2328:841915] -A PREROUTING -p udp -j LOG 

COMMIT

# Completed on Wed Sep 30 07:14:14 2009

# Generated by iptables-save v1.4.2 on Wed Sep 30 07:14:14 2009

*filter

:INPUT DROP [2238959:279238555]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [524193444:102838071615]

:remotesvcs - [0:0]

[69303:149492697] -A INPUT -i lo -j ACCEPT 

[365218169:530986781641] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

[67755:4829239] -A INPUT -i eth1 -j ACCEPT 

[495:29194] -A INPUT -i eth0 -j remotesvcs 

[8827305:1550753694] -A FORWARD -s 192.168.0.0/16 -i eth1 -j ACCEPT 

[0:0] -A FORWARD -s 192.168.0.0/16 -i eth1 -j ACCEPT 

[12678004:15112053501] -A FORWARD -d 192.168.0.0/16 -i eth0 -j ACCEPT 

[85:4208] -A remotesvcs -p tcp -m tcp --dport XXXX -j ACCEPT 

[134:7792] -A remotesvcs -p tcp -m tcp --dport XXXX -j ACCEPT 

[0:0] -A remotesvcs -p tcp -m tcp --dport XXXX -j ACCEPT 

[0:0] -A remotesvcs -p tcp -m tcp --dport XXXX -j ACCEPT 

[0:0] -A remotesvcs -p tcp -m tcp --dport XXXX -j ACCEPT 

[0:0] -A remotesvcs -p tcp -m tcp --dport XXXX -j ACCEPT 

[265:13939] -A remotesvcs -p tcp -j REJECT --reject-with tcp-reset 

COMMIT

# Completed on Wed Sep 30 07:14:14 2009

# Generated by iptables-save v1.4.2 on Wed Sep 30 07:14:14 2009

*nat

:PREROUTING ACCEPT [3381770:634798686]

:POSTROUTING ACCEPT [140902:15092201]

:OUTPUT ACCEPT [94790:6608887]

[182465:11629606] -A POSTROUTING -o eth0 -j MASQUERADE 

COMMIT

# Completed on Wed Sep 30 07:14:14 2009

# Generated by iptables-save v1.4.2 on Wed Sep 30 07:14:14 2009

*raw

:PREROUTING ACCEPT [984148650:1376117964767]

:OUTPUT ACCEPT [522580166:101469327465]

[300650:443388737] -A PREROUTING -j LOG 

[2165:802185] -A PREROUTING -p udp -j LOG 

COMMIT

# Completed on Wed Sep 30 07:14:14 2009
```

----------

## barophobia

Add a line at the end of the input table to log what is being dropped.  might want to prefix it with something identifiable.

If you are doing something like below I really don't see why your udp packets are being dropped since you have it set to accept anything from eth1.

```

-----------                eth1      eth0

| client  +-----+switch+------+server+----+internet

-----------

```

----------

## nixscripter

You got the diagram right.

I don't understand why these two rules don't match it, but they not only drop client traffic, but other UDP things on my network, too:

```
[13:636] -A FORWARD -s 192.168.0.0/16 -i eth1 -j ACCEPT 

[12679282:15112827120] -A FORWARD -d 192.168.0.0/16 -i eth0 -j ACCEPT
```

There is one thing curious: when I log UDP specifically, I get all the packets. When I log all protocols, I get nothing, despite continued drops.

That's why I'm convinced it must be some sort of kernel module not looking for UDP.

----------

## nixscripter

Hmm.

One thing occurred to me when I cleaned up all the print statements, and looked at the NAT rules again:

```
[183102:11669949] -A POSTROUTING -o eth0 -j MASQUERADE
```

Could masquerading be manipulating UDP packets on the same connection, making it fail to notice the RELATED,ESTABLISHED rule? Maybe it's not dropping them after all, but just dropping the replies?

----------

## Hu

It is good that you provided the output of iptables-save, but you need to be a bit more precise before we can help you.  Am I correct that your problem is that a privately addressed client in the LAN is unable to establish a bidirectional UDP session with a publicly addressed server on the Internet?  Is the client able to use ICMP and TCP with machines on the Internet?  Does tcpdump show the NAT'd packets leaving the firewall's public interface and proceeding outbound?  Does it show response packets arriving on the public interface?  These answers will tell us whether the problem is inappropriate NAT, a problem with the server, or a filtering problem.  If it is a filtering problem, we can identify whether it occurs on the requests or on the responses.

----------

## nixscripter

Yes you would be correct. However, I just solved the problem.

I just re-wrote the same rules for the FORWARD chain different ways until I came up with this:

```
[463048:43513752] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 

[750:32435] -A FORWARD -i eth1 -j ACCEPT 

[0:0] -A FORWARD -s 192.168.0.0/16 -i eth0 -j ACCEPT
```

It may be slightly less secure than the other way, but UDP does work.

I'm also sure part of the trouble was my initial UDP testing was a STUN protocol client, which should be broken by IP masquerading (because the new connection is not RELATED).

Staying up too late has its consequences. Thanks anyway, guys.

----------

