All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordan Russell <jr-list-2007@quo.to>
To: Jordan Russell <jr-list-2007@quo.to>
Cc: netfilter-devel@lists.netfilter.org, netfilter@lists.netfilter.org
Subject: Re: ICMP packets associated with NAT connections sent out wrong  interface?
Date: Fri, 06 Jul 2007 12:42:24 -0500	[thread overview]
Message-ID: <468E7F00.5070307@quo.to> (raw)
In-Reply-To: <468C86C9.7050204@quo.to>

Jordan Russell wrote:
> BTW: does the LOG output indicate that netfilter translated the source
> address of 70.243.226.250 to 192.168.0.133? If so, shouldn't it have
> instead translated the *destination* address of 123.23.23.23 (=eth1) to
> 192.168.0.133? Could this be why the ICMP packet was generated in the
> first place?

To clarify my question:

If tcpdump on eth1 reports:

  70.243.226.250.1703 > 123.23.23.23.25000

while my LOG rule reports for the same packet:

  ... [SRC=192.168.0.133 DST=123.23.23.23 ... SPT=25000 DPT=25000

isn't this saying that netfilter translated the *source* address of the
packet?

Since port 25000 is covered by a DNAT rule:

-A PREROUTING -i eth1 -p tcp -m tcp --dport 25000 -j DNAT
--to-destination 192.168.0.133

shouldn't it have set the *destination* address of the packet to
192.168.0.133, while leaving the source address unchanged?

So: It appears as though netfilter is (in rare cases) translating the
source address of packets when it should be translating the destination
address. Or am I misinterpreting the log output?

-- 
Jordan Russell


WARNING: multiple messages have this Message-ID (diff)
From: Jordan Russell <jr-list-2007@quo.to>
To: Jordan Russell <jr-list-2007@quo.to>
Cc: netfilter-devel@lists.netfilter.org, netfilter@lists.netfilter.org
Subject: Re: ICMP packets associated with NAT connections sent out wrong interface?
Date: Fri, 06 Jul 2007 12:42:24 -0500	[thread overview]
Message-ID: <468E7F00.5070307@quo.to> (raw)
In-Reply-To: <468C86C9.7050204@quo.to>

Jordan Russell wrote:
> BTW: does the LOG output indicate that netfilter translated the source
> address of 70.243.226.250 to 192.168.0.133? If so, shouldn't it have
> instead translated the *destination* address of 123.23.23.23 (=eth1) to
> 192.168.0.133? Could this be why the ICMP packet was generated in the
> first place?

To clarify my question:

If tcpdump on eth1 reports:

  70.243.226.250.1703 > 123.23.23.23.25000

while my LOG rule reports for the same packet:

  ... [SRC=192.168.0.133 DST=123.23.23.23 ... SPT=25000 DPT=25000

isn't this saying that netfilter translated the *source* address of the
packet?

Since port 25000 is covered by a DNAT rule:

-A PREROUTING -i eth1 -p tcp -m tcp --dport 25000 -j DNAT
--to-destination 192.168.0.133

shouldn't it have set the *destination* address of the packet to
192.168.0.133, while leaving the source address unchanged?

So: It appears as though netfilter is (in rare cases) translating the
source address of packets when it should be translating the destination
address. Or am I misinterpreting the log output?

-- 
Jordan Russell

  parent reply	other threads:[~2007-07-06 17:42 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-16 16:43 ICMP packets associated with NAT connections sent out wrong interface? Jordan Russell
2007-06-26 22:22 ` Martijn Lievaart
2007-06-27 11:44   ` Ray Leach
2007-06-27 18:16     ` Jordan Russell
2007-06-28  6:56     ` Martijn Lievaart
2007-06-28 16:26       ` Jordan Russell
2007-06-28 19:10         ` Martijn Lievaart
2007-06-29  1:00 ` Yasuyuki KOZAKAI
     [not found] ` <200706290100.l5T1028w016087@toshiba.co.jp>
2007-07-04 23:25   ` Jordan Russell
     [not found]   ` <468C15EE.9060806@quo.to>
2007-07-05  1:11     ` Yasuyuki KOZAKAI
2007-07-05  1:16       ` Yasuyuki KOZAKAI
2007-07-05  5:51       ` Jordan Russell
2007-07-05  5:51         ` Jordan Russell
2007-07-05 11:17         ` Yasuyuki KOZAKAI
2007-07-05 12:21           ` Patrick McHardy
2007-07-05 12:33             ` Krzysztof Oledzki
2007-07-05 17:05             ` Jordan Russell
     [not found]             ` <200707050111.l651Bu2w016010@toshiba.co.jp>
2007-07-06  0:14               ` Yasuyuki KOZAKAI
2007-07-06  0:50                 ` Jordan Russell
2007-07-06 17:42         ` Jordan Russell [this message]
2007-07-06 17:42           ` Jordan Russell
2007-07-07  6:27           ` Yasuyuki KOZAKAI
2007-07-07 12:24             ` Yasuyuki KOZAKAI
2007-07-07 12:24               ` Yasuyuki KOZAKAI
2007-07-07 15:34               ` Patrick McHardy
2007-07-07 17:28                 ` Yasuyuki KOZAKAI
2007-07-07 17:48                   ` Yasuyuki KOZAKAI
2007-07-08  6:31                     ` Yasuyuki KOZAKAI
     [not found]                   ` <200707071748.l67HmfE2005051@toshiba.co.jp>
2007-07-09 13:34                     ` Patrick McHardy
2007-07-13 14:25                       ` Yasuyuki KOZAKAI
     [not found]                       ` <200707131425.l6DEPBYv013659@toshiba.co.jp>
2007-07-13 14:50                         ` Patrick McHardy
2007-07-13 15:49                           ` Yasuyuki KOZAKAI
2007-07-07 21:04               ` Jordan Russell
2007-07-09  7:03                 ` Yasuyuki KOZAKAI

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=468E7F00.5070307@quo.to \
    --to=jr-list-2007@quo.to \
    --cc=netfilter-devel@lists.netfilter.org \
    --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.