All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gavin Carr <gavin@openfusion.com.au>
To: netfilter@lists.netfilter.org
Subject: Connection failing to SNAT
Date: Tue, 25 Jan 2005 22:18:02 +1100	[thread overview]
Message-ID: <20050125111802.GA19384@openfusion.com.au> (raw)

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




             reply	other threads:[~2005-01-25 11:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-25 11:18 Gavin Carr [this message]
2005-01-25 12:16 ` Connection failing to SNAT George Alexandru Dragoi
2005-01-25 23:29 ` Gavin Carr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050125111802.GA19384@openfusion.com.au \
    --to=gavin@openfusion.com.au \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.