Packets that should have been DNATted appearing in INPUT table

Packets that should have been DNATted appearing in INPUT table

[Marius Mertens]

Hi everybody,

first of all, please cc me in your answer as I am not a subscriber of this 
list.
I have a problem in understanding how the packet flow really works, as my 
setup is not completely working as expected.
I want to redirect all traffic coming from the internet to (for example) 
port 4664 to the same port on a box in my LAN and I use the following rule 
to accomplish this:
iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 4664 -j DNAT --to 
192.168.6.10
From what I read, I thought that with this rule packets go to PREROUTING, 
get their new destination and then through FORWARD and POSTROUTING right to 
eth0 and out to my LAN.
The only thing I have in my POSTROUTING is
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.6.0/24 -j MASQUERADE
What I find really weird is that the packet counter of
iptables -A INPUT -i ppp0 -p tcp --dport 4664 -j DROP
is not zero, in fact the value is growing and about 10% of the number of 
packets successfully redirected to the other box in my LAN.
An example of a packet which should have been redirected but was logged in 
the INPUT chain is
IN=ppp0 OUT= MAC= SRC=217.30.133.213 DST=217.225.50.178 LEN=40 TOS=0x00 
PREC=0x00 TTL=120 ID=5272 DF PROTO=TCP SPT=2214 DPT=4664 WINDOW=10094 
RES=0x00 ACK FIN URGP=0
DST correctly shows my internet IP, but I thought that it should have been 
replaced with 192.168.6.10 in PREROUTING...
Now my questions are: Is there something I misunderstood with packet flow? 
Or should it be OK in theory and I screwed something up during 
implementation?
And finally: How do I get it to work in a way, that really every single 
packet coming in for a specific port on a specific interface is redirected 
to another host?

Thank you very much,

Marius 

Re: Packets that should have been DNATted appearing in INPUT table

[Jason Opperisano]

On Wed, Jan 05, 2005 at 07:00:40PM +0100, Marius Mertens wrote:
> first of all, please cc me in your answer as I am not a subscriber of this 
> list.

always a great way to start a post...

<snip>

does your DNAT work or not?

-j

--
"What's the point of going out, we're just going to end up back
 here anyway?"
        --The Simpsons

Re: Packets that should have been DNATted appearing in INPUT table

[Marius Mertens]

On Thursday, January 06, 2005 4:55 PM,
Jason Opperisano wrote:

> does your DNAT work or not?

Thats what I find most weird: For about 95% of the packets it indeed does 
work, but some of the packets seem to be ignored by the DNAT rule added to 
PREROUTING. The relevant parts of iptables' rules list output are:

Chain INPUT (policy ACCEPT 1 packets, 40 bytes)
 pkts bytes target     prot opt in     out     source 
destination
  178 17537 ACCEPT     all  --  lo     any     anywhere             anywhere
 1012 63664 DROP       tcp  --  ppp0   any     anywhere             anywhere 
tcp dpt:4664
[...]

and

Chain PREROUTING (policy ACCEPT 333K packets, 17M bytes)
 pkts bytes target     prot opt in     out     source 
destination
26615 1336K DNAT       tcp  --  ppp0   any     anywhere             anywhere 
tcp dpt:4664 to:192.168.6.10
[...]

So from the users point of view I would not have even noticed it, as 
applications work as expected. So the user would say, my DNAT does work. But 
looking at the packet counters I would like to understand what is happening, 
because my aim was to have every single packet going to specific ports being 
redirected to another box. As already mentioned, I believe the packet 
counter of the above drop rule should be zero, because all packets matching 
this rule should already have matched DNAT in PREROUTING and therefore never 
enter INPUT. From that point of view (at least for some packets) I have to 
say, that DNAT does not work.

If there is more information I can provide to narrow down the problem, 
please let me know. And thanks again for your help,

Marius 

Re: Packets that should have been DNATted appearing in INPUT table

[Michael Gale]

Hello,

	I believe you are misunderstanding what is happening, your rule:

iptables -A INPUT -i ppp0 -p tcp --dport 4664 -j DROP

Should not affect packets you are forwarding, because those packets from 
outside that are being sent to a internal machine should be matched 
against the FORWARD and not the INPUT.

So some where packets are not matching the PREROUTING rule, either you 
have a rule above that is causing some packets to be accept before they 
reach the PREROUTING rule.

You could to a iptables -t nat -vnL and iptables -vnL and provide the 
out put. Plus if you are running test where are you running them from ?

Michael.




Marius Mertens wrote:
> On Thursday, January 06, 2005 4:55 PM,
> Jason Opperisano wrote:
> 
>> does your DNAT work or not?
> 
> 
> Thats what I find most weird: For about 95% of the packets it indeed 
> does work, but some of the packets seem to be ignored by the DNAT rule 
> added to PREROUTING. The relevant parts of iptables' rules list output are:
> 
> Chain INPUT (policy ACCEPT 1 packets, 40 bytes)
> pkts bytes target     prot opt in     out     source destination
>  178 17537 ACCEPT     all  --  lo     any     anywhere             anywhere
> 1012 63664 DROP       tcp  --  ppp0   any     anywhere             
> anywhere tcp dpt:4664
> [...]
> 
> and
> 
> Chain PREROUTING (policy ACCEPT 333K packets, 17M bytes)
> pkts bytes target     prot opt in     out     source destination
> 26615 1336K DNAT       tcp  --  ppp0   any     anywhere             
> anywhere tcp dpt:4664 to:192.168.6.10
> [...]
> 
> So from the users point of view I would not have even noticed it, as 
> applications work as expected. So the user would say, my DNAT does work. 
> But looking at the packet counters I would like to understand what is 
> happening, because my aim was to have every single packet going to 
> specific ports being redirected to another box. As already mentioned, I 
> believe the packet counter of the above drop rule should be zero, 
> because all packets matching this rule should already have matched DNAT 
> in PREROUTING and therefore never enter INPUT. From that point of view 
> (at least for some packets) I have to say, that DNAT does not work.
> 
> If there is more information I can provide to narrow down the problem, 
> please let me know. And thanks again for your help,
> 
> Marius
> 

-- 
Michael Gale
Lan Administrator
Utilitran Corp.

I make better friends with those who think for them selves

Re: Packets that should have been DNATted appearing in INPUT table

[Marius Mertens]

On Friday, January 07, 2005 9:08 PM,
Michael Gale wrote:

> I believe you are misunderstanding what is happening, your rule:
>
> iptables -A INPUT -i ppp0 -p tcp --dport 4664 -j DROP
>
> Should not affect packets you are forwarding, because those packets
> from outside that are being sent to a internal machine should be
> matched against the FORWARD and not the INPUT.

Yes, this is exactly my problem: As you said, forwarded packets should never 
be matched against rules in INPUT. And thats where the DROP rule above 
enters the game: I just inserted it as a very primitive "test", just to have 
a packet counter for packets matching criteria "-i ppp0 -p tcp --dport 4664" 
in INPUT and expected it to be constantly zero. The only purpose of this 
drop rule is to show me, how many packets (matching the same criteria "-i 
ppp0 -p tcp --dport 4664") have not been DNATed in PREROUTING.

> So some where packets are not matching the PREROUTING rule, either you
> have a rule above that is causing some packets to be accept before
> they reach the PREROUTING rule.

Again, I fully agree: Something made some of the packets not match the DNAT 
rule in PREROUTING, otherwise INPUT would never have seen them. I hope you 
can see anything abnormal with my rules, because I am really stuck with that 
problem.

> You could to a iptables -t nat -vnL and iptables -vnL and provide the
> out put. Plus if you are running test where are you running them from
> ?

Please see the complete output below. The "test" I do is no active testing. 
I just run the application (which communicates with machines on the 
internet, outside my LAN) on the box in my LAN the router should DNAT to and 
monitor the packet counters of the rules I added for diagnostic purpose. I 
am sure you already have noticed, but as my english is not that good, I 
would now like to let the rules talk for themselves ;-)
Just one final comment: I temporarily "tidied up" (yes, I know that this 
setup doesn't make sense for a productive system ;-)) my ruleset in order 
not to flood this list with unnecessary stuff (my actual ruleset is rather 
looooong and the things I removed are irrelevant for the problem, but please 
see for yourself). I fear it will get ugly enough, because of that automatic 
linebreak ;-)

Thanks for your patience,

Marius


Output of iptables -vnL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source 
destination
    4   420 ACCEPT     all  --  lo     *       0.0.0.0/0 
0.0.0.0/0
  789  925K DROP       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4664
    0     0 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:22
  347 30488 ACCEPT     tcp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:22
    3   194 ACCEPT     udp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:53
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:53
    2   656 ACCEPT     udp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:123
   10   924 ACCEPT     udp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:137
   10  2401 ACCEPT     udp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:138
   25  3098 ACCEPT     tcp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:139
   16  2287 ACCEPT     tcp  --  eth0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:445
  428 20960 DROP       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp flags:0x16/0x02
   63  5744 ACCEPT     all  --  *      *       0.0.0.0/0 
0.0.0.0/0           state RELATED,ESTABLISHED
    1    60 ACCEPT     all  --  eth0   *       0.0.0.0/0 
0.0.0.0/0
  123 17315 DROP       all  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0

Chain FORWARD (policy ACCEPT 292K packets, 138M bytes)
 pkts bytes target     prot opt in     out     source 
destination

Chain OUTPUT (policy ACCEPT 462 packets, 39562 bytes)
 pkts bytes target     prot opt in     out     source 
destination
    4   420 ACCEPT     all  --  *      lo      0.0.0.0/0 
0.0.0.0/0


Output of  iptables -t nat -vnL

Chain PREROUTING (policy ACCEPT 5765 packets, 288K bytes)
 pkts bytes target     prot opt in     out     source 
destination
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:1070 to:192.168.6.66
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:6112 to:192.168.6.66
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:38930 to:192.168.6.66
 2166  116K DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4664 to:192.168.6.10
 1505 72854 DNAT       udp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:9053 to:192.168.6.10
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:6881 to:192.168.6.10
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4884 to:192.168.6.10
    0     0 DNAT       udp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:6886 to:192.168.6.10
    0     0 DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4663 to:192.168.6.11
    0     0 DNAT       udp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           udp dpt:6052 to:192.168.6.11

Chain POSTROUTING (policy ACCEPT 3709 packets, 193K bytes)
 pkts bytes target     prot opt in     out     source 
destination
 5283  252K MASQUERADE  all  --  *      ppp0    192.168.6.0/24 
0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source 
destination 

Re: Packets that should have been DNATted appearing in INPUT table

[R. DuFresne]

On Sat, 8 Jan 2005, Marius Mertens wrote:

> On Friday, January 07, 2005 9:08 PM,
> Michael Gale wrote:
> 
> > I believe you are misunderstanding what is happening, your rule:
> >
> > iptables -A INPUT -i ppp0 -p tcp --dport 4664 -j DROP
> >
> > Should not affect packets you are forwarding, because those packets
> > from outside that are being sent to a internal machine should be
> > matched against the FORWARD and not the INPUT.
> 
> Yes, this is exactly my problem: As you said, forwarded packets should never 
> be matched against rules in INPUT. And thats where the DROP rule above 
> enters the game: I just inserted it as a very primitive "test", just to have 
> a packet counter for packets matching criteria "-i ppp0 -p tcp --dport 4664" 
> in INPUT and expected it to be constantly zero. The only purpose of this 
> drop rule is to show me, how many packets (matching the same criteria "-i 
> ppp0 -p tcp --dport 4664") have not been DNATed in PREROUTING.
> 

And there are other reasons that you might get this counter to increment
and none of them relating to packets meant for the DNAT system<s>/rules on
the FORWARD chain.  It's not enough of a test to validate your
conclusions, adding a LOG rule prior to the drop might help track down
'why' you are seeing that 'counter' increment.

Thanks,

Ron DuFresne
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com

...Love is the ultimate outlaw.  It just won't adhere to rules.
The most any of us can do is sign on as it's accomplice.  Instead
of vowing to honor and obey, maybe we should swear to aid and abet.
That would mean that security is out of the question.  The words
"make" and "stay" become inappropriate.  My love for you has no
strings attached.  I love you for free...
                        -Tom Robins <Still Life With Woodpecker>

Re: Packets that should have been DNATted appearing in INPUT table

[Marius Mertens]

Hi again,

I just subscribed to this list in order to save the moderator some work and 
minimize the delays in our discussion ;-)
So no need to cc anymore.

On Tuesday, January 11, 2005 1:27 AM,
R. DuFresne wrote:

> [...]
> validate your conclusions, adding a LOG rule prior to the drop might
> help track down 'why' you are seeing that 'counter' increment.

Below are the packets logged by
iptables -A INPUT -i ppp0 -p tcp --dport 4664 -j LOG --log-level 
6 --log-prefix "SUSPICIOUS: "
after running some minutes.

Thanks,

Marius

IN=ppp0 OUT= MAC= SRC=140.123.66.197 DST=217.225.53.155 LEN=48 TOS=0x00 
PREC=0x00 TTL=109 ID=55204 DF PROTO=TCP SPT=1440 DPT=4664 WINDOW=65535 
RES=0x00 SYN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=241 ID=32322 DF PROTO=TCP SPT=53421 DPT=4664 WINDOW=0 RES=0x00 
ACK RST URGP=0
IN=ppp0 OUT= MAC= SRC=84.30.47.18 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=116 ID=16344 DF PROTO=TCP SPT=4265 DPT=4664 WINDOW=16816 
RES=0x00 ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=84.30.47.18 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=116 ID=16723 DF PROTO=TCP SPT=4265 DPT=4664 WINDOW=16816 
RES=0x00 ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=84.30.47.18 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=116 ID=17446 DF PROTO=TCP SPT=4265 DPT=4664 WINDOW=16816 
RES=0x00 ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=84.30.47.18 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=116 ID=18857 DF PROTO=TCP SPT=4265 DPT=4664 WINDOW=16816 
RES=0x00 ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=213.103.35.61 DST=217.225.53.155 LEN=425 TOS=0x00 
PREC=0x00 TTL=121 ID=28543 DF PROTO=TCP SPT=3654 DPT=4664 WINDOW=64814 
RES=0x00 ACK PSH URGP=0
IN=ppp0 OUT= MAC= SRC=213.103.35.61 DST=217.225.53.155 LEN=1452 TOS=0x00 
PREC=0x00 TTL=121 ID=30075 DF PROTO=TCP SPT=3654 DPT=4664 WINDOW=64814 
RES=0x00 ACK PSH URGP=0
IN=ppp0 OUT= MAC= SRC=213.103.35.61 DST=217.225.53.155 LEN=1280 TOS=0x00 
PREC=0x00 TTL=121 ID=31490 DF PROTO=TCP SPT=3654 DPT=4664 WINDOW=64768 
RES=0x00 ACK PSH URGP=0
IN=ppp0 OUT= MAC= SRC=62.214.27.81 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=123 ID=29135 DF PROTO=TCP SPT=2687 DPT=4664 WINDOW=46391 
RES=0x00 ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=67.126.22.246 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=241 ID=47633 DF PROTO=TCP SPT=4984 DPT=4664 WINDOW=0 RES=0x00 
ACK RST URGP=0
IN=ppp0 OUT= MAC= SRC=212.45.48.230 DST=217.225.53.155 LEN=62 TOS=0x00 
PREC=0x00 TTL=115 ID=34124 DF PROTO=TCP SPT=3527 DPT=4664 WINDOW=17310 
RES=0x00 ACK PSH URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=58370 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=58435 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=58510 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=58698 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=59086 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=59598 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=60126 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=60901 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=66.122.241.147 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=246 ID=45285 DF PROTO=TCP SPT=3010 DPT=4664 WINDOW=0 RES=0x00 
ACK RST URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=61891 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=213.200.229.3 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=246 ID=9736 PROTO=TCP SPT=23067 DPT=4664 WINDOW=0 RES=0x00 RST 
URGP=0
IN=ppp0 OUT= MAC= SRC=213.200.229.3 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=246 ID=9737 PROTO=TCP SPT=23067 DPT=4664 WINDOW=0 RES=0x00 RST 
URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=62757 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=63693 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=64849 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=52 TOS=0x00 
PREC=0x00 TTL=49 ID=421 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK FIN URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=49 ID=1546 PROTO=TCP SPT=54021 DPT=4664 WINDOW=65535 RES=0x00 
ACK RST URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=241 ID=18689 DF PROTO=TCP SPT=54021 DPT=4664 WINDOW=0 RES=0x00 
ACK RST URGP=0
IN=ppp0 OUT= MAC= SRC=64.237.189.227 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=244 ID=17409 DF PROTO=TCP SPT=3846 DPT=4664 WINDOW=0 RES=0x00 
ACK RST URGP=0
IN=ppp0 OUT= MAC= SRC=63.201.36.204 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=241 ID=25925 DF PROTO=TCP SPT=54581 DPT=4664 WINDOW=0 RES=0x00 
ACK RST URGP=0
IN=ppp0 OUT= MAC= SRC=82.83.169.119 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=58 ID=30825 PROTO=TCP SPT=2276 DPT=4664 WINDOW=0 RES=0x00 RST 
URGP=0
IN=ppp0 OUT= MAC= SRC=62.1.170.19 DST=217.225.53.155 LEN=40 TOS=0x00 
PREC=0x00 TTL=115 ID=56835 PROTO=TCP SPT=1776 DPT=4664 WINDOW=0 RES=0x00 RST 
URGP=0

Re: Packets that should have been DNATted appearing in INPUT table

[Jason Opperisano]

On Tue, Jan 11, 2005 at 04:03:11PM +0100, Marius Mertens wrote:
> Hi again,
> 
> I just subscribed to this list in order to save the moderator some work and 
> minimize the delays in our discussion ;-)
> So no need to cc anymore.

we greatly appreciate that.

> On Tuesday, January 11, 2005 1:27 AM,
> R. DuFresne wrote:
> 
> >[...]
> >validate your conclusions, adding a LOG rule prior to the drop might
> >help track down 'why' you are seeing that 'counter' increment.
> 
> Below are the packets logged by
> iptables -A INPUT -i ppp0 -p tcp --dport 4664 -j LOG --log-level 
> 6 --log-prefix "SUSPICIOUS: "
> after running some minutes.

you could easily be creating this situation yourself with your "testing"
methodology.  if you are:

1) starting firewall
2) allowing connections to establish
3) stopping firewall, which includes removing ip_conntrack
4) starting firewall

all the packets that were part of the established connections in step 2
will no longer have a conntrack entry that ties them to the DNAT, and
they will end up in INPUT and get dropped.

i'm not saying this is what you are doing--but it's an explanation for
what you're seeing--the DNAT functionality in netfilter works properly
in my experience.

-j

--
"To alcohol: the cause of, and solution to, all of life's problems."
        --The Simpsons

Re: Packets that should have been DNATted appearing in INPUT table

[Marius Mertens]

On Tuesday, January 11, 2005 5:29 PM,
Jason Opperisano wrote:

> all the packets that were part of the established connections in step
> 2 will no longer have a conntrack entry that ties them to the DNAT,
> and they will end up in INPUT and get dropped.

Thats a very interesting theory! I would never have thought of that myself. 
And you are right, I actually do restart my firewall quite often during 
testing phase. There are just 2 things still preventing me from being 
completely happy:
1) The drops still happen after running the firewall for several hours. Its 
just a feeling, but isn't that a very long time for a tcp connection?
2) When I take a look at /proc/net/ip_conntrack it does not empty when 
restarting the firewall, so I thought, existing connections should go 
unharmed.

Maybe I looked in the wrong places, but are there detailed information about 
how DNAT works internally (apart from reading the sources ;-))?

Something I could also imagine, is that those 
somehow-not-handled-as-i-expected-packets are just bogus packets not 
belonging to any connection. In that case, namely that these packages are of 
no use anyhow (and that they would have been dropped at the target box, 
because of not belonging to any existing connection or initialising a new 
connection themselves), it would be perfectly correct to drop them at the 
router.
But there are still things, I do not understand, if thats the case:
Reverting to my mostly favourite game (comparing counters) I noticed the 
following:

Chain PREROUTING (policy ACCEPT 646K packets, 32M bytes)
 pkts bytes target     prot opt in     out     source 
destination
    0     0 LOG        tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4664 state INVALID LOG flags 0 level 6 prefix 
`SUSPICIOUS: '
  582 31900 LOG        tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4664 LOG flags 0 level 6 prefix `NORMAL: '
  582 31900 DNAT       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4664 to:192.168.6.10
    0     0 LOG        tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4664 LOG flags 0 level 6 prefix `SUSPICIOUS: '

For me it looks perfectly normal and like should-be-working. But in INPUT 
the drops are still there:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source 
destination
   22  1096 DROP       tcp  --  ppp0   *       0.0.0.0/0 
0.0.0.0/0           tcp dpt:4664

I also noticed that the LOG rule in nat PREROUTING has far less matches 
counted than the same LOG rule in mangle PREROUTING.

Perhaps you can tell me, whether I am right if i think that either
1) The critical packets have matched DNAT but somehow DNAT thought that it 
should not alter the destination and rather direct it to INPUT
2) The critical packets have never even entered nat PREROUTING (seems 
probable, but I have no proof)

Unfortunately, even if either of the two cases really happens, I still don't 
have any explanation, why it does...

Thank you very much,

Marius 

Re: Packets that should have been DNATted appearing in INPUT table

[R. DuFresne]

it's also quite possible these connetions his counter catches are not
related to the NAT c0onnections at all, but, are the result of other
systems scanning his or trying to find a way through his FW rulebase. My
cash is on these counters incrementing due to kiddies and others merely
scanning the ethers with new toys and trinkets they have found at various
links and sec websites on the net.  But,this can be confirmed with
comparing these INPUT hits with his FORWARDED NAT hits in the logs, yes?

thanks,

Ron DuFresne

On Tue, 11 Jan 2005, Jason Opperisano wrote:

> On Tue, Jan 11, 2005 at 04:03:11PM +0100, Marius Mertens wrote:
> > Hi again,
> > 
> > I just subscribed to this list in order to save the moderator some work and 
> > minimize the delays in our discussion ;-)
> > So no need to cc anymore.
> 
> we greatly appreciate that.
> 
> > On Tuesday, January 11, 2005 1:27 AM,
> > R. DuFresne wrote:
> > 
> > >[...]
> > >validate your conclusions, adding a LOG rule prior to the drop might
> > >help track down 'why' you are seeing that 'counter' increment.
> > 
> > Below are the packets logged by
> > iptables -A INPUT -i ppp0 -p tcp --dport 4664 -j LOG --log-level 
> > 6 --log-prefix "SUSPICIOUS: "
> > after running some minutes.
> 
> you could easily be creating this situation yourself with your "testing"
> methodology.  if you are:
> 
> 1) starting firewall
> 2) allowing connections to establish
> 3) stopping firewall, which includes removing ip_conntrack
> 4) starting firewall
> 
> all the packets that were part of the established connections in step 2
> will no longer have a conntrack entry that ties them to the DNAT, and
> they will end up in INPUT and get dropped.
> 
> i'm not saying this is what you are doing--but it's an explanation for
> what you're seeing--the DNAT functionality in netfilter works properly
> in my experience.
> 
> -j
> 
> --
> "To alcohol: the cause of, and solution to, all of life's problems."
>         --The Simpsons
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior security consultant:  sysinfo.com
                        http://sysinfo.com

...Love is the ultimate outlaw.  It just won't adhere to rules.
The most any of us can do is sign on as it's accomplice.  Instead
of vowing to honor and obey, maybe we should swear to aid and abet.
That would mean that security is out of the question.  The words
"make" and "stay" become inappropriate.  My love for you has no
strings attached.  I love you for free...
                        -Tom Robins <Still Life With Woodpecker>

Re: Packets that should have been DNATted appearing in INPUT table

[Marius Mertens]

On Tuesday, January 11, 2005 7:16 PM,
R. DuFresne wrote:

> [...]
> at various links and sec websites on the net.  But,this can be
> confirmed with comparing these INPUT hits with his FORWARDED NAT hits
> in the logs, yes?

Great idea, but I think we can exclude malicious attempts: The source IPs of 
the "critical packets" all (without exception) have far more packets that 
were correctly forwarded (several 10 or 100) than dropped (just 1 or 2 in 
the same time).

Thank you very much,

Marius