Connection failing to SNAT

Connection failing to SNAT

[Gavin Carr]

Hi netfilter gurus,

I've got a very weird problem I need some help with. I have a very 
boring Debian Woody-based router/firewall doing SNAT between my 
internal network and the outside. Has been working fine for months.

The problem is I've got one app (asterisk) on an internal server
that is connecting via UDP to a particular host, and the connection
is failing. Same app connects fine to other hosts, and network
connectivity to the host in question from the same box looks fine - 
I can ping, I can netcat to the udp port, etc.

Debugging this, it looks like the bad outward connection is
not getting masqueraded properly - on the external interface on 
the firewall a tcpdump shows:

  04:35:18.203836 10.10.10.1.4569 > 202.125.42.141.4569:  udp 12 (DF) [tos 0x10]
  04:35:18.706606 10.10.10.1.4569 > 202.125.42.141.4569:  udp 12 (DF) [tos 0x10]
  04:35:18.707008 10.10.10.1.4569 > 202.125.42.141.4569:  udp 26 (DF) [tos 0x10]
  04:35:19.344564 203.213.47.14.4569 > 216.118.117.46.4569:  udp 12 (DF) [tos 0x10]
  04:35:19.586808 216.118.117.46.4569 > 203.213.47.14.4569:  udp 12 (DF) [tos 0x10]
  04:35:19.587876 203.213.47.14.4569 > 216.118.117.46.4569:  udp 12 (DF) [tos 0x10]

The first three lines are bad, where the 10.10.10.1 is my internal
address that isn't masqueraded. The next three lines are good to
a different host (216.118.117.46), where 203.213.47.14 is my
external (SNATed) address. 

Added some logging like so:

  # Log mangle POSTROUTING
  $IPT -t mangle -A POSTROUTING -o $EXT -j LOG --log-prefix 'MANGLE POST: '

  # Turn on SNAT
  $IPT -t nat -A POSTROUTING -o $EXT -j LOG --log-prefix 'POSTROUTING1: '
  $IPT -t nat -A POSTROUTING -o $EXT -j SNAT --to-source 203.213.47.14
  $IPT -t nat -A POSTROUTING -o $EXT -j LOG --log-prefix 'POSTROUTING2: '

and all I see in the logs for the bad connection is the 'MANGLE POST'
packets - no 'POSTROUTING1' shows up at all. So it looks like the packets
are just skipping the nat table altogether somehow?

Anyone got any idea what might be going on here, or where to look next
to try and debug this further? Same behaviour with both current woody
iptables (1.2.6a-5.0) and the backports one (1.2.11?), BTW. Nothing in
the routing table other than the two connected segments and the default
gateway.

Thanks for any suggestions.

Cheers,
Gavin

Re: Connection failing to SNAT

[George Alexandru Dragoi]

I'm not sure what is happening, i also had some problems, the SNAT-ed
packets used same source-port like original ones (all connection
attempt were made to same ip, so there should not be duplicates). I
got that problem after i rebooted a machine, swapped eth0 and eth1. I
had to clear the nat setup, and re-run the firewall script to have it
working. To mension i like to use realm 6 to the default route,
because it is the only one i want to use nat (all others are local
"peers" on same outgoing interface).


On Tue, 25 Jan 2005 22:18:02 +1100, Gavin Carr <gavin@openfusion.com.au> wrote:
> Hi netfilter gurus,
> 
> I've got a very weird problem I need some help with. I have a very
> boring Debian Woody-based router/firewall doing SNAT between my
> internal network and the outside. Has been working fine for months.
> 
> The problem is I've got one app (asterisk) on an internal server
> that is connecting via UDP to a particular host, and the connection
> is failing. Same app connects fine to other hosts, and network
> connectivity to the host in question from the same box looks fine -
> I can ping, I can netcat to the udp port, etc.
> 
> Debugging this, it looks like the bad outward connection is
> not getting masqueraded properly - on the external interface on
> the firewall a tcpdump shows:
> 
>   04:35:18.203836 10.10.10.1.4569 > 202.125.42.141.4569:  udp 12 (DF) [tos 0x10]
>   04:35:18.706606 10.10.10.1.4569 > 202.125.42.141.4569:  udp 12 (DF) [tos 0x10]
>   04:35:18.707008 10.10.10.1.4569 > 202.125.42.141.4569:  udp 26 (DF) [tos 0x10]
>   04:35:19.344564 203.213.47.14.4569 > 216.118.117.46.4569:  udp 12 (DF) [tos 0x10]
>   04:35:19.586808 216.118.117.46.4569 > 203.213.47.14.4569:  udp 12 (DF) [tos 0x10]
>   04:35:19.587876 203.213.47.14.4569 > 216.118.117.46.4569:  udp 12 (DF) [tos 0x10]
> 
> The first three lines are bad, where the 10.10.10.1 is my internal
> address that isn't masqueraded. The next three lines are good to
> a different host (216.118.117.46), where 203.213.47.14 is my
> external (SNATed) address.
> 
> Added some logging like so:
> 
>   # Log mangle POSTROUTING
>   $IPT -t mangle -A POSTROUTING -o $EXT -j LOG --log-prefix 'MANGLE POST: '
> 
>   # Turn on SNAT
>   $IPT -t nat -A POSTROUTING -o $EXT -j LOG --log-prefix 'POSTROUTING1: '
>   $IPT -t nat -A POSTROUTING -o $EXT -j SNAT --to-source 203.213.47.14
>   $IPT -t nat -A POSTROUTING -o $EXT -j LOG --log-prefix 'POSTROUTING2: '
> 
> and all I see in the logs for the bad connection is the 'MANGLE POST'
> packets - no 'POSTROUTING1' shows up at all. So it looks like the packets
> are just skipping the nat table altogether somehow?
> 
> Anyone got any idea what might be going on here, or where to look next
> to try and debug this further? Same behaviour with both current woody
> iptables (1.2.6a-5.0) and the backports one (1.2.11?), BTW. Nothing in
> the routing table other than the two connected segments and the default
> gateway.
> 
> Thanks for any suggestions.
> 
> Cheers,
> Gavin
> 
> 


-- 
Bla bla

Re: Connection failing to SNAT

[Gavin Carr]

On Tue, Jan 25, 2005 at 10:18:02PM +1100, Gavin Carr wrote:
> Added some logging like so:
> 
>   # Log mangle POSTROUTING
>   $IPT -t mangle -A POSTROUTING -o $EXT -j LOG --log-prefix 'MANGLE POST: '
> 
>   # Turn on SNAT
>   $IPT -t nat -A POSTROUTING -o $EXT -j LOG --log-prefix 'POSTROUTING1: '
>   $IPT -t nat -A POSTROUTING -o $EXT -j SNAT --to-source 203.213.47.14
>   $IPT -t nat -A POSTROUTING -o $EXT -j LOG --log-prefix 'POSTROUTING2: '
> 
> and all I see in the logs for the bad connection is the 'MANGLE POST'
> packets - no 'POSTROUTING1' shows up at all. So it looks like the packets
> are just skipping the nat table altogether somehow?

This does seem to be the core problem - packets are being logged in the 
mangle POSTROUTING table, but then not showing up in the nat POSTROUTING 
table. Not all packets, though - just these problem ones. Anyone have
any idea how this can happen? All the diagrams I've seen seem to indicate
that mangle and nat postrouting are strictly sequential?

All suggestions gratefully received.

Cheers,
Gavin