Linux Netfilter discussions
 help / color / mirror / Atom feed
* Packets not traversing the POSTROUTING table?
@ 2008-04-08  3:27 Eric B.
  2008-04-08  9:26 ` Jan Engelhardt
  0 siblings, 1 reply; 9+ messages in thread
From: Eric B. @ 2008-04-08  3:27 UTC (permalink / raw)
  To: netfilter

Hi,

I'm running into a strange issue here.  I'm not sure if I have done
something wrong, or if am simply misunderstanding things.

I have added a very simple rule in my POSTROUTING nat table to log all
packets, but the packets I am looking to find don't show up in my log file.
If I initiate the packets from the machine itself, (eg: ping www.yahoo.com),
then I see those packets show up.  However, if the machine is simply
responding to packets from another machine (ex: ping 192.168.101.64 from
another computer), they don't show up in the POSTROUTING table.  I'll see
the packets show up in the log statement from the OUTPUT filter table, but
not in the POSTROUTING nat table.

I was under the impression/understanding that all packets travel through the
POSTROUTING nat table.  Is this incorrect?  Do they only traverse that table
under special circumstances?  Do response packets not traverse the
POSTROUTING table?

# iptables -F
# iptables -t nat -I POSTROUTING -j LOG --log-prefix "POSTROUTE"
# iptables -I OUTPUT -j LOG --log-prefix "OUTPUT"

I've taken a look at http://www.docum.org/docum.org/kptd/ and from what I
can tell, all packets are supposed to traverse the POSTROUTING table...   Am
I missing something obvious here?

From what someone on the comp.os.linux.networking group told me, only the 
nat tables only see the first new packet of every connection, but since ICMP 
is connectionless, does that not mean that every new ping would have to 
travel through the nat table chains?  I added a log rule in the PREROUTE nat 
table and see all the incoming ICMP ping requests; just absolutely nothing 
in the POSTROUTE nat table....

I'm running RHEL 4.2, kernel 2.6.9-67.0.4.ELsmp.

Any help would greatly be appreciated!

Thanks!

Eric




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08  3:27 Packets not traversing the POSTROUTING table? Eric B.
@ 2008-04-08  9:26 ` Jan Engelhardt
  2008-04-08 11:42   ` Eric B.
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Engelhardt @ 2008-04-08  9:26 UTC (permalink / raw)
  To: Eric B.; +Cc: netfilter


On Tuesday 2008-04-08 05:27, Eric B. wrote:
>
>I have added a very simple rule in my POSTROUTING nat table to log all
>packets, but the packets I am looking to find don't show up in my log file.
>If I initiate the packets from the machine itself, (eg: ping www.yahoo.com),
>then I see those packets show up.  However, if the machine is simply
>responding to packets[...], they don't show up in the POSTROUTING table.  I'll see
>the packets show up in the log statement from the OUTPUT filter table, but
>not in the POSTROUTING nat table.
[...]
From what someone on the comp.os.linux.networking group told me, only the 
>nat tables only see the first new packet of every connection,[...]

Yes, the _first_ packet. But an ICMP reply (it also applies to TCP SYN ACK)
is not the first(*). See the output of the LOGMARK target on
-t mangle -A POSTROUTING -p icmp -d <desktop>:

Apr  8 11:15:31 sovereign kernel: [1415558.389017] hook=POSTROUTING nfmark=0x0
secmark=0x0 classify=0x0 ctdir=REPLY ct=0xffff81007674c380 ctmark=0x0
ctstate=ESTABLISHED ctstatus=SEEN_REPLY,CONFIRMED

Do you see "ctstate=NEW" anywhere? I don't! :-)




(*) That is, unless you manage to flush the conntrack tables between
reception of the packet and the kernel generating the reply.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08  9:26 ` Jan Engelhardt
@ 2008-04-08 11:42   ` Eric B.
  2008-04-08 12:17     ` Jan Engelhardt
  0 siblings, 1 reply; 9+ messages in thread
From: Eric B. @ 2008-04-08 11:42 UTC (permalink / raw)
  To: netfilter

"Jan Engelhardt" <jengelh@computergmbh.de> wrote in message
news:alpine.LNX.1.10.0804081121460.17722@fbirervta.pbzchgretzou.qr...
>
>>From what someone on the comp.os.linux.networking group told me, only the
>>nat tables only see the first new packet of every connection,[...]
>
> Yes, the _first_ packet. But an ICMP reply (it also applies to TCP SYN
> ACK)
> is not the first(*). See the output of the LOGMARK target on
> -t mangle -A POSTROUTING -p icmp -d <desktop>:
>
> Apr  8 11:15:31 sovereign kernel: [1415558.389017] hook=POSTROUTING
> nfmark=0x0
> secmark=0x0 classify=0x0 ctdir=REPLY ct=0xffff81007674c380 ctmark=0x0
> ctstate=ESTABLISHED ctstatus=SEEN_REPLY,CONFIRMED
>
> Do you see "ctstate=NEW" anywhere? I don't! :-)

Sorry, but what is the LOGMARK target?  I can't seem to find that target
anywhere in the docs or the man pages.  I've seen the LOG target and the
MARK target, but not sure what the LOGMARK target is.  Furthermore, how did
you manage to get that log output from the POSTROUTING table, if the
response packet doesn't traverse it?

I'm assuming you are using some advanced debugging features?  Where can I
find out more about those?

Thanks!

Eric







^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08 11:42   ` Eric B.
@ 2008-04-08 12:17     ` Jan Engelhardt
  2008-04-08 18:15       ` Eric B.
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Engelhardt @ 2008-04-08 12:17 UTC (permalink / raw)
  To: Eric B.; +Cc: netfilter


On Tuesday 2008-04-08 13:42, Eric B. wrote:
>>
>>>From what someone on the comp.os.linux.networking group told me, only the
>>>nat tables only see the first new packet of every connection,[...]
>>
>> Yes, the _first_ packet. But an ICMP reply (it also applies to TCP SYN
>> ACK)
>> is not the first(*). See the output of the LOGMARK target on
>> -t mangle -A POSTROUTING -p icmp -d <desktop>:
>>
>> Apr  8 11:15:31 sovereign kernel: [1415558.389017] hook=POSTROUTING
>> nfmark=0x0
>> secmark=0x0 classify=0x0 ctdir=REPLY ct=0xffff81007674c380 ctmark=0x0
>> ctstate=ESTABLISHED ctstatus=SEEN_REPLY,CONFIRMED
>>
>> Do you see "ctstate=NEW" anywhere? I don't! :-)
>
>Sorry, but what is the LOGMARK target?  I can't seem to find that target
>anywhere in the docs or the man pages.  I've seen the LOG target and the
>MARK target, but not sure what the LOGMARK target is.

Similar to LOG but instead of dumping the packet data, it dumps the
associated Netfilter metastructures.

>  Furthermore, how did
>you manage to get that log output from the POSTROUTING table, if the
>response packet doesn't traverse it?

It's from the mangle table, the table directly traversed before.
(as packets from ESTABLISHED connections do not traverse nat)

>I'm assuming you are using some advanced debugging features?  Where can I
>find out more about those?

http://jengelh.hopto.org/projects/xtables/


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08 12:17     ` Jan Engelhardt
@ 2008-04-08 18:15       ` Eric B.
  2008-04-08 19:14         ` Jan Engelhardt
  0 siblings, 1 reply; 9+ messages in thread
From: Eric B. @ 2008-04-08 18:15 UTC (permalink / raw)
  To: netfilter

"Jan Engelhardt" <jengelh@computergmbh.de> wrote in message
news:alpine.LNX.1.10.0804081359450.17722@fbirervta.pbzchgretzou.qr...
>
> On Tuesday 2008-04-08 13:42, Eric B. wrote:
>>>
>>>>From what someone on the comp.os.linux.networking group told me, only
>>>>the
>>>>nat tables only see the first new packet of every connection,[...]
>>>
>>> Yes, the _first_ packet. But an ICMP reply (it also applies to TCP SYN
>>> ACK)
>>> is not the first(*). See the output of the LOGMARK target on
>>> -t mangle -A POSTROUTING -p icmp -d <desktop>:
>>>
>>> Apr  8 11:15:31 sovereign kernel: [1415558.389017] hook=POSTROUTING
>>> nfmark=0x0
>>> secmark=0x0 classify=0x0 ctdir=REPLY ct=0xffff81007674c380 ctmark=0x0
>>> ctstate=ESTABLISHED ctstatus=SEEN_REPLY,CONFIRMED
>>>
>>> Do you see "ctstate=NEW" anywhere? I don't! :-)
>>
>>Sorry, but what is the LOGMARK target?  I can't seem to find that target
>>anywhere in the docs or the man pages.  I've seen the LOG target and the
>>MARK target, but not sure what the LOGMARK target is.
>
> Similar to LOG but instead of dumping the packet data, it dumps the
> associated Netfilter metastructures.

I'm not sure I follow.  I'm using iptables v1.2.11, and I've tried the
following command, but as I feared, LOGMARK is an unknown target for my 
version.  Is there a way to get the logmark target for my version, or do I 
need to update the entire package?

I'm running RHEL4.2 with kernel 2.6.9-67.0.4.ELsmp

# iptables -t mangle -I POSTROUTING -p icmp -j LOGMARK
iptables v1.2.11: Couldn't load target
`LOGMARK':/lib/iptables/libipt_LOGMARK.so: cannot open shared object file:
No such file or directory


Does Xtables completely replace the iptables package?  Do precompiled 
binaries exist for it?

Thanks,

Eric





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08 18:15       ` Eric B.
@ 2008-04-08 19:14         ` Jan Engelhardt
  2008-04-08 19:28           ` Eric B.
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Engelhardt @ 2008-04-08 19:14 UTC (permalink / raw)
  To: Eric B.; +Cc: netfilter


On Tuesday 2008-04-08 20:15, Eric B. wrote:
>>>
>>>Sorry, but what is the LOGMARK target?  I can't seem to find that
>>>target anywhere in the docs or the man pages.  I've seen the LOG
>>>target and the MARK target, but not sure what the LOGMARK target
>>>is.
>>
>> Similar to LOG but instead of dumping the packet data, it dumps
>> the associated Netfilter metastructures.
>
>I'm not sure I follow.  I'm using iptables v1.2.11, and I've tried the
>following command, but as I feared, LOGMARK is an unknown target for my 
>version.  Is there a way to get the logmark target for my version, or do I 
>need to update the entire package?

LOGMARK is an extension I wrote, and it being in the xtables-addons
package menas you need kernel 2.6.18 at least (but newer is always
better, we are approaching 2.6.25), and the xtables base package.

>Does Xtables completely replace the iptables package?

Technically yes. Politically no :)

>Do precompiled binaries exist for it?

I only have for OpenSUSE 10.3.


					Oh the joy of enterprise distros...

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08 19:14         ` Jan Engelhardt
@ 2008-04-08 19:28           ` Eric B.
  2008-04-08 19:38             ` Jan Engelhardt
  0 siblings, 1 reply; 9+ messages in thread
From: Eric B. @ 2008-04-08 19:28 UTC (permalink / raw)
  To: netfilter

"Jan Engelhardt" <jengelh@computergmbh.de> wrote in message 
news:alpine.LNX.1.10.0804082106570.2229@fbirervta.pbzchgretzou.qr...
>
> On Tuesday 2008-04-08 20:15, Eric B. wrote:
>>>>
>>>>Sorry, but what is the LOGMARK target?  I can't seem to find that
>>>>target anywhere in the docs or the man pages.  I've seen the LOG
>>>>target and the MARK target, but not sure what the LOGMARK target
>>>>is.
>>>
>>> Similar to LOG but instead of dumping the packet data, it dumps
>>> the associated Netfilter metastructures.
>>
>>I'm not sure I follow.  I'm using iptables v1.2.11, and I've tried the
>>following command, but as I feared, LOGMARK is an unknown target for my
>>version.  Is there a way to get the logmark target for my version, or do I
>>need to update the entire package?
>
> LOGMARK is an extension I wrote, and it being in the xtables-addons
> package menas you need kernel 2.6.18 at least (but newer is always
> better, we are approaching 2.6.25), and the xtables base package.

*sigh* Running enterprise servers precludes me from manually installing 
those kernels.   Although I'm not quite sure what release 67 of the RH 
kernel includes as updates to the 2.6.9 kernel...  Might there be any chance 
of it working on the RH 2.6.9-67 kernel?

> Oh the joy of enterprise distros...
One of the necessary side effects of running entreprise servers, I guess....

Thanks again,

Eric




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08 19:28           ` Eric B.
@ 2008-04-08 19:38             ` Jan Engelhardt
  2008-04-08 19:44               ` Eric B.
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Engelhardt @ 2008-04-08 19:38 UTC (permalink / raw)
  To: Eric B.; +Cc: netfilter


On Tuesday 2008-04-08 21:28, Eric B. wrote:
>>
>> LOGMARK is an extension I wrote, and it being in the xtables-addons
>> package menas you need kernel 2.6.18 at least (but newer is always
>> better, we are approaching 2.6.25), and the xtables base package.
>
>*sigh* Running enterprise servers precludes me from manually installing 
>those kernels.   Although I'm not quite sure what release 67 of the RH 
>kernel includes as updates to the 2.6.9 kernel...  Might there be any chance 
>of it working on the RH 2.6.9-67 kernel?

Yes, though I suppose hacking up the place in ipt_LOG to print
you the info you need (which is?) would be faster than backporting
the entire xtables. Noting that simple rules like -m conntrack
--ctstate NEW are approaching the debug value of a direct log message
from the modules.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Packets not traversing the POSTROUTING table?
  2008-04-08 19:38             ` Jan Engelhardt
@ 2008-04-08 19:44               ` Eric B.
  0 siblings, 0 replies; 9+ messages in thread
From: Eric B. @ 2008-04-08 19:44 UTC (permalink / raw)
  To: netfilter


"Jan Engelhardt" <jengelh@computergmbh.de> wrote in message 
news:alpine.LNX.1.10.0804082135360.2229@fbirervta.pbzchgretzou.qr...
>
> On Tuesday 2008-04-08 21:28, Eric B. wrote:
>>>
>>> LOGMARK is an extension I wrote, and it being in the xtables-addons
>>> package menas you need kernel 2.6.18 at least (but newer is always
>>> better, we are approaching 2.6.25), and the xtables base package.
>>
>>*sigh* Running enterprise servers precludes me from manually installing
>>those kernels.   Although I'm not quite sure what release 67 of the RH
>>kernel includes as updates to the 2.6.9 kernel...  Might there be any 
>>chance
>>of it working on the RH 2.6.9-67 kernel?
>
> Yes, though I suppose hacking up the place in ipt_LOG to print
> you the info you need (which is?) would be faster than backporting
> the entire xtables. Noting that simple rules like -m conntrack
> --ctstate NEW are approaching the debug value of a direct log message
> from the modules.

Actually, ideally, I'd also like to be able to see the "mark" that is 
associated to the packet, if at all possible.

Any hope of that?  (Again, b/c I'm having trouble getting it to route 
through my kernel's routing table using iproute2).

Thanks,

Eric 




^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2008-04-08 19:44 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-08  3:27 Packets not traversing the POSTROUTING table? Eric B.
2008-04-08  9:26 ` Jan Engelhardt
2008-04-08 11:42   ` Eric B.
2008-04-08 12:17     ` Jan Engelhardt
2008-04-08 18:15       ` Eric B.
2008-04-08 19:14         ` Jan Engelhardt
2008-04-08 19:28           ` Eric B.
2008-04-08 19:38             ` Jan Engelhardt
2008-04-08 19:44               ` Eric B.

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox