* Packets that should have been DNATted appearing in INPUT table @ 2005-01-05 18:00 Marius Mertens 2005-01-06 15:55 ` Jason Opperisano 0 siblings, 1 reply; 11+ messages in thread From: Marius Mertens @ 2005-01-05 18:00 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-05 18:00 Packets that should have been DNATted appearing in INPUT table Marius Mertens @ 2005-01-06 15:55 ` Jason Opperisano 2005-01-06 16:49 ` Marius Mertens 0 siblings, 1 reply; 11+ messages in thread From: Jason Opperisano @ 2005-01-06 15:55 UTC (permalink / raw) To: netfilter; +Cc: Marius Mertens 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-06 15:55 ` Jason Opperisano @ 2005-01-06 16:49 ` Marius Mertens 2005-01-07 20:08 ` Michael Gale 0 siblings, 1 reply; 11+ messages in thread From: Marius Mertens @ 2005-01-06 16:49 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-06 16:49 ` Marius Mertens @ 2005-01-07 20:08 ` Michael Gale 2005-01-08 0:43 ` Marius Mertens 0 siblings, 1 reply; 11+ messages in thread From: Michael Gale @ 2005-01-07 20:08 UTC (permalink / raw) To: Marius Mertens, netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-07 20:08 ` Michael Gale @ 2005-01-08 0:43 ` Marius Mertens 2005-01-11 0:27 ` R. DuFresne 0 siblings, 1 reply; 11+ messages in thread From: Marius Mertens @ 2005-01-08 0:43 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-08 0:43 ` Marius Mertens @ 2005-01-11 0:27 ` R. DuFresne 2005-01-11 15:03 ` Marius Mertens 0 siblings, 1 reply; 11+ messages in thread From: R. DuFresne @ 2005-01-11 0:27 UTC (permalink / raw) To: Marius Mertens; +Cc: netfilter 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> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-11 0:27 ` R. DuFresne @ 2005-01-11 15:03 ` Marius Mertens 2005-01-11 16:29 ` Jason Opperisano 0 siblings, 1 reply; 11+ messages in thread From: Marius Mertens @ 2005-01-11 15:03 UTC (permalink / raw) To: R. DuFresne; +Cc: netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-11 15:03 ` Marius Mertens @ 2005-01-11 16:29 ` Jason Opperisano 2005-01-11 18:15 ` Marius Mertens 2005-01-11 18:16 ` R. DuFresne 0 siblings, 2 replies; 11+ messages in thread From: Jason Opperisano @ 2005-01-11 16:29 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-11 16:29 ` Jason Opperisano @ 2005-01-11 18:15 ` Marius Mertens 2005-01-11 18:16 ` R. DuFresne 1 sibling, 0 replies; 11+ messages in thread From: Marius Mertens @ 2005-01-11 18:15 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-11 16:29 ` Jason Opperisano 2005-01-11 18:15 ` Marius Mertens @ 2005-01-11 18:16 ` R. DuFresne 2005-01-11 18:33 ` Marius Mertens 1 sibling, 1 reply; 11+ messages in thread From: R. DuFresne @ 2005-01-11 18:16 UTC (permalink / raw) To: Jason Opperisano; +Cc: netfilter 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> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Packets that should have been DNATted appearing in INPUT table 2005-01-11 18:16 ` R. DuFresne @ 2005-01-11 18:33 ` Marius Mertens 0 siblings, 0 replies; 11+ messages in thread From: Marius Mertens @ 2005-01-11 18:33 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-01-11 18:33 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-01-05 18:00 Packets that should have been DNATted appearing in INPUT table Marius Mertens 2005-01-06 15:55 ` Jason Opperisano 2005-01-06 16:49 ` Marius Mertens 2005-01-07 20:08 ` Michael Gale 2005-01-08 0:43 ` Marius Mertens 2005-01-11 0:27 ` R. DuFresne 2005-01-11 15:03 ` Marius Mertens 2005-01-11 16:29 ` Jason Opperisano 2005-01-11 18:15 ` Marius Mertens 2005-01-11 18:16 ` R. DuFresne 2005-01-11 18:33 ` Marius Mertens
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.