where are my udp packets going?

where are my udp packets going?

[sean darcy]

I'm trying to setup port forwarding for a VOIP server that uses IAX 
packets, port 4569:

+ /sbin/iptables -t nat -A PREROUTING -i eth0 -p udp --dport 4569 -j 
DNAT --to 10.10.10.180:4569
+ /sbin/iptables -A FORWARD -p udp -m state --state NEW -d 10.10.10.180 
--dport 4569 -j ACCEPT

but the packets aren't showing up at 10.10.10.180.

I put in a bunch of log statements:

$IPT -t raw -A PREROUTING -i $EXTIF -p udp --dport 4569 -j LOG 
--log-prefix "iax packet RAW:   "
$IPT -t nat -A PREROUTING -i $EXTIF -p udp --dport 4569 -j DNAT --to 
10.10.10.180:4569
$IPT -t nat -A PREROUTING -i $EXTIF -p udp --dport 4569 -j LOG 
--log-prefix "iax packet PRE NAT:   "
$IPT -A FORWARD -p udp -m state --state NEW -d 10.10.10.180 --dport 4569 
-j ACCEPT
$IPT -A FORWARD -p udp  --dport 4569 -d 10.10.10.180    -j LOG 
--log-prefix "iax packet FORWARD:  "
$IPT -t nat -A POSTROUTING  -p udp --dport 4569         -j LOG 
--log-prefix "iax packet POST:   "

So, I would expect each iax packet to show up sequentially as:
iax packet RAW:
iax packet PRE NAT:
iax packet FORWARD:
iax packet POST:

But no:

I get lots of "iax packet RAW:   " , and an "iax packet FORWARD:  " 
every 2 -  10 "iax packet RAW:  " messages. That's it. no postrouting, 
no prerouting nat.

And the voip server sees no iax packets.

Where are they going?

sean

Re: where are my udp packets going?

[sean darcy]

sean darcy wrote:
> I'm trying to setup port forwarding for a VOIP server that uses IAX 
> packets, port 4569:
> 
> + /sbin/iptables -t nat -A PREROUTING -i eth0 -p udp --dport 4569 -j 
> DNAT --to 10.10.10.180:4569
> + /sbin/iptables -A FORWARD -p udp -m state --state NEW -d 10.10.10.180 
> --dport 4569 -j ACCEPT
> 
> but the packets aren't showing up at 10.10.10.180.
> 
> I put in a bunch of log statements:
> 
> $IPT -t raw -A PREROUTING -i $EXTIF -p udp --dport 4569 -j LOG 
> --log-prefix "iax packet RAW:   "
> $IPT -t nat -A PREROUTING -i $EXTIF -p udp --dport 4569 -j DNAT --to 
> 10.10.10.180:4569
> $IPT -t nat -A PREROUTING -i $EXTIF -p udp --dport 4569 -j LOG 
> --log-prefix "iax packet PRE NAT:   "
> $IPT -A FORWARD -p udp -m state --state NEW -d 10.10.10.180 --dport 4569 
> -j ACCEPT
> $IPT -A FORWARD -p udp  --dport 4569 -d 10.10.10.180    -j LOG 
> --log-prefix "iax packet FORWARD:  "
> $IPT -t nat -A POSTROUTING  -p udp --dport 4569         -j LOG 
> --log-prefix "iax packet POST:   "
> 
> So, I would expect each iax packet to show up sequentially as:
> iax packet RAW:
> iax packet PRE NAT:
> iax packet FORWARD:
> iax packet POST:
> 
> But no:
> 
> I get lots of "iax packet RAW:   " , and an "iax packet FORWARD:  " 
> every 2 -  10 "iax packet RAW:  " messages. That's it. no postrouting, 
> no prerouting nat.
> 
> And the voip server sees no iax packets.
> 
> Where are they going?
> 
> sean
> 

Well, they're going to input.


I put in a log statement for INPUT:

$IPT -t raw -A PREROUTING -i $EXTIF -p udp --dport 4569 -j LOG 
--log-prefix "iax packet RAW:   "
$IPT -t nat -A PREROUTING -i $EXTIF -p udp --dport 4569 -j DNAT --to 
10.10.10.180:4569
$IPT -t nat -A PREROUTING -i $EXTIF -p udp --dport 4569 -j LOG 
--log-prefix "iax packet PRE NAT:   "
$IPT -A INPUT   -p udp  --dport 4569                    -j LOG 
--log-prefix "iax packet INPUT:  "
$IPT -A FORWARD -p udp  --dport 4569 -d 10.10.10.180    -j LOG 
--log-prefix "iax packet FORWARD:  "

and look:

kernel: iax packet RAW:   IN=eth0 OUT= 
MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=76.zzz.xxx.yyy 
DST=64.61.167.178 LEN=53 TOS=0x04 PREC=0x00 TTL=49 ID=19483 PROTO=UDP 
SPT=4569 DPT=4569 LEN=33
kernel: iax packet INPUT:  IN=eth0 OUT= 
MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=76.zzz.xxx.yyy 
DST=64.61.167.178 LEN=53 TOS=0x04 PREC=0x00 TTL=49 ID=19483 PROTO=UDP 
SPT=4569 DPT=4569 LEN=33
kernel: iax packet RAW:   IN=eth0 OUT= 
MAC=00:48:54:8b:ab:29:00:1a:e2:84:bf:3b:08:00 SRC=66.zzz.xxx.yyy 
DST=64.61.167.178 LEN=69 TOS=0x00 PREC=0x00 TTL=55 ID=16258 DF PROTO=UDP 
SPT=4569 DPT=4569 LEN=49
kernel: iax packet FORWARD:  IN=eth0 OUT=eth1 SRC=66.zzz.xxx.yyy 
DST=10.10.10.180 LEN=69 TOS=0x00 PREC=0xA0 TTL=54 ID=16258 DF PROTO=UDP 
SPT=4569 DPT=4569 LEN=49

In other words, it's port forwarding all iax except from 76.

So then I put in:

$IPT -t nat -A PREROUTING -s 76.zzz.xxx.yyy -p udp --dport 4569 -j DNAT 
--to 10.10.10.180:4569

And that made no difference!

Any help really appreciated.

sean

Re: where are my udp packets going?

[Pascal Hambourg]

Hello,

sean darcy a écrit :
> sean darcy wrote:
>> I'm trying to setup port forwarding for a VOIP server that uses IAX 
>> packets, port 4569:
>>
>> + /sbin/iptables -t nat -A PREROUTING -i eth0 -p udp --dport 4569 -j 
>> DNAT --to 10.10.10.180:4569
>> + /sbin/iptables -A FORWARD -p udp -m state --state NEW -d 
>> 10.10.10.180 --dport 4569 -j ACCEPT
>>
>> but the packets aren't showing up at 10.10.10.180.
[...]
> Well, they're going to input.
[...]
> In other words, it's port forwarding all iax except from 76.

This happens probably because your NAT box started to receive UDP/4569 
packets from 76.zzz.xxx.yyy before the DNAT rule was created and 
continually receives packets since then. The netfilter connection 
tracking created a conntrack entry without any NAT operation so 
subsequent UDP/4569 packets from 76.zzz.xxx.yyy use that same conntrack 
entry and skip the nat chains, until the entry expires. If the box 
continally sees UDP/4569 packets from 76.zzz.xxx.yyy, then the entry 
never expires. If you pull the ethernet wire off eth0 for a couple of 
minutes, the conntrack entry should expire.

Rationale : don't allow any traffic before all rules are created. A 
simple way to achieve it is to create the rules before network 
interfaces are UP.

Re: where are my udp packets going?

[sean darcy]

Pascal Hambourg wrote:
> Hello,
> 
> sean darcy a écrit :
>> sean darcy wrote:
>>> I'm trying to setup port forwarding for a VOIP server that uses IAX 
>>> packets, port 4569:
>>>
>>> + /sbin/iptables -t nat -A PREROUTING -i eth0 -p udp --dport 4569 -j 
>>> DNAT --to 10.10.10.180:4569
>>> + /sbin/iptables -A FORWARD -p udp -m state --state NEW -d 
>>> 10.10.10.180 --dport 4569 -j ACCEPT
>>>
>>> but the packets aren't showing up at 10.10.10.180.
> [...]
>> Well, they're going to input.
> [...]
>> In other words, it's port forwarding all iax except from 76.
> 
> This happens probably because your NAT box started to receive UDP/4569 
> packets from 76.zzz.xxx.yyy before the DNAT rule was created and 
> continually receives packets since then. The netfilter connection 
> tracking created a conntrack entry without any NAT operation so 
> subsequent UDP/4569 packets from 76.zzz.xxx.yyy use that same conntrack 
> entry and skip the nat chains, until the entry expires. If the box 
> continally sees UDP/4569 packets from 76.zzz.xxx.yyy, then the entry 
> never expires. If you pull the ethernet wire off eth0 for a couple of 
> minutes, the conntrack entry should expire.
> 
> Rationale : don't allow any traffic before all rules are created. A 
> simple way to achieve it is to create the rules before network 
> interfaces are UP.
> -- 

I was able to shut down the 76. machine, reboot the server, and it 
worked. So, thanks.

But all this leaves me puzzled.

My server does NOT generate 4569 packets, and iptables INPUT drops all 
from eth0, except for ssh and ESTABLISHED. So how could there be a 
conntrack entry?

Is there a way to DNAT traffic before it reaches the conntrack entry? 
Can I change the destination in raw/PREROUTING?

Is there a way to flush the conntrack entry? I'd reallly like not to 
take the network down if this happens again. It's a very remote machine, 
and if ssh didn't come up again, I'd need a new job.

Thanks for the help.

sean

Re: where are my udp packets going?

[Pascal Hambourg]

sean darcy a écrit :
>
> I was able to shut down the 76. machine, reboot the server, and it worked.

Hmm, shut down or reboot was a bit overkill.

> My server does NOT generate 4569 packets, and iptables INPUT drops all 
> from eth0, except for ssh and ESTABLISHED. So how could there be a 
> conntrack entry?

The DROP target prevents a packet from creating a new conntrack entry. 
However I suppose there was a sort of race condition with incoming 
packets, conntrack activation, default policy definition and rule creation.

If the conntrack module is loaded before a DROP rule is created in the 
filter/INPUT chain or its policy is set to DROP, then an incoming packet 
  could create the bogus conntrack entry. The conntrack module can be 
autoloaded by many ways including :
- loading a conntrack or NAT helper module,
- creating a rule using a match or target that requires conntrack 
(state, conntrack, connmark, CONNMARK...)
- loading the nat table, which may be caused by creating a rule in one 
of its chains, defining the default policy of one of its chains or just 
flushing one of its chains.
So conntrack may be enabled sooner that you think.

Check the order in which the following operations happen at startup :
- load conntrack/NAT modules {ip,nf}_{conntrack,nat}*
- define iptables default policies in the nat and filter tables
- create or flush iptables rules in the nat and filter tables
- enable network interfaces

> Is there a way to DNAT traffic before it reaches the conntrack entry? 

No, because NAT requires conntrack.

> Can I change the destination in raw/PREROUTING?

No. All you can do in raw/PREROUTING is DROP or mark packets in the 
UNTRACKED state with the NOTRACK target so the conntrack won't see them. 
By the way I guess that adding a temporary rule matching the IAX traffic 
from 76.x.x.x in this chain until the related conntrack entry expires 
would have done the trick too, without having to put machines offline.

> Is there a way to flush the conntrack entry?

Yes, with the conntrack utility from the conntrack-tools package. If you 
distro does not ship it, you can get it from the netfilter site.
<http://www.netfilter.org/projects/conntrack-tools/index.html>

Re: where are my udp packets going?

[sean darcy]

Pascal Hambourg wrote:
> sean darcy a écrit :
>>
>> I was able to shut down the 76. machine, reboot the server, and it 
>> worked.
> 
> Hmm, shut down or reboot was a bit overkill.
> 
>> My server does NOT generate 4569 packets, and iptables INPUT drops all 
>> from eth0, except for ssh and ESTABLISHED. So how could there be a 
>> conntrack entry?
> 
> The DROP target prevents a packet from creating a new conntrack entry. 
> However I suppose there was a sort of race condition with incoming 
> packets, conntrack activation, default policy definition and rule creation.
> 
> If the conntrack module is loaded before a DROP rule is created in the 
> filter/INPUT chain or its policy is set to DROP, then an incoming packet 
>  could create the bogus conntrack entry. The conntrack module can be 
> autoloaded by many ways including :
> - loading a conntrack or NAT helper module,
> - creating a rule using a match or target that requires conntrack 
> (state, conntrack, connmark, CONNMARK...)
> - loading the nat table, which may be caused by creating a rule in one 
> of its chains, defining the default policy of one of its chains or just 
> flushing one of its chains.
> So conntrack may be enabled sooner that you think.
> 
> Check the order in which the following operations happen at startup :
> - load conntrack/NAT modules {ip,nf}_{conntrack,nat}*
> - define iptables default policies in the nat and filter tables
> - create or flush iptables rules in the nat and filter tables
> - enable network interfaces
> 
>> Is there a way to DNAT traffic before it reaches the conntrack entry? 
> 
> No, because NAT requires conntrack.
> 
>> Can I change the destination in raw/PREROUTING?
> 
> No. All you can do in raw/PREROUTING is DROP or mark packets in the 
> UNTRACKED state with the NOTRACK target so the conntrack won't see them. 
> By the way I guess that adding a temporary rule matching the IAX traffic 
> from 76.x.x.x in this chain until the related conntrack entry expires 
> would have done the trick too, without having to put machines offline.
> 
>> Is there a way to flush the conntrack entry?
> 
> Yes, with the conntrack utility from the conntrack-tools package. If you 
> distro does not ship it, you can get it from the netfilter site.
> <http://www.netfilter.org/projects/conntrack-tools/index.html>
>

Great. I've installed conntrack-tools from fedora.

Now I'm trying to figure out the correct command that flushes the 
conntrack entry but allows it to start again. I started a new thread 
since it's getting OT for this one.

Thanks for all your help. I never would've figured this out.

sean