From: Dennison Williams <dennison.williams@gmail.com>
To: netfilter@vger.kernel.org
Subject: Re: MARK not working
Date: Fri, 02 Apr 2010 00:27:21 -0700 [thread overview]
Message-ID: <4BB59C59.50607@gmail.com> (raw)
In-Reply-To: <20100402065742.23be08f0@catlap>
Marek Kierdelewicz wrote:
> I think packets marked 0x1 in prerouting should never reach LOG &
> ACCEPT rule because of the following rule before them:
>
>
>> -A INPUT -i eth1 -p udp -m udp --dport 4500 -j ACCEPT
>>
>
> You can clear counters, feed some test traffic to the box and send me
> counter information retrieved with following commands:
> iptables -L -nv -t filter
> iptables -L -nv -t mangle
Yes, this is a bit confusing to me as well. In this scenario we have
the establishing of a vpn connection (udp port 4500), following this is
an attempt to establish a l2tp connection (udp port 1701 encapsulated in
the vpn tunnel).
Before brining up the vpn I flush both mangle/PREROUTING and
filter/INPUT tables:
# iptables -t filter -Z
# iptables -t mangle -Z PREROUTING
I then succesfully bring up the vpn connection and provide a count of
the two tables:
# iptables -t mangle -L PREROUTING -vxn
Chain PREROUTING (policy ACCEPT 97 packets, 10778 bytes)
pkts bytes target prot opt in out
source destination
2 1004 MARK udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:500 MARK xset
0x1/0xffffffff
9 1744 MARK udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:4500 MARK xset
0x1/0xffffffff
0 0 MARK esp -- eth1 *
0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0xffffffff
# iptables -t filter -L INPUT -vxn
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out
source destination
0 0 REJECT all -- !lo *
0.0.0.0/0 127.0.0.0/8 reject-with icmp-port-unreachable
374 37299 Accounting all -- * *
0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo *
0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth2 *
0.0.0.0/0 0.0.0.0/0
371 36320 ACCEPT all -- * *
0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1 620 ACCEPT all -- eth1 *
0.0.0.0/0 0.0.0.0/0 mark match 0x1
0 0 ACCEPT esp -- * *
0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT icmp -- eth1 *
0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 1/sec
burst 5
0 0 DROP tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent:
UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source
0 0 tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent:
SET name: DEFAULT side: source
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:5667
2 359 LOG all -- * *
0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
2 359 REJECT all -- * *
0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Then I bring up the l2tp connection, and provide a count. This is
where the problem is:
# iptables -t mangle -L PREROUTING -vxn
Chain PREROUTING (policy ACCEPT 280 packets, 31531 bytes)
pkts bytes target prot opt in out
source destination
2 1004 MARK udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:500 MARK xset
0x1/0xffffffff
17 1976 MARK udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:4500 MARK xset
0x1/0xffffffff
0 0 MARK esp -- eth1 *
0.0.0.0/0 0.0.0.0/0 MARK xset 0x1/0xffffffff
You can see here that we have an extra 8 packets from the l2tp
connection (the l2tp client tries 8 times before it gives up).
# iptables -t filter -L INPUT -vxn
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out
source destination
0 0 REJECT all -- !lo *
0.0.0.0/0 127.0.0.0/8 reject-with icmp-port-unreachable
433 45512 Accounting all -- * *
0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo *
0.0.0.0/0 0.0.0.0/0
2 130 ACCEPT all -- eth2 *
0.0.0.0/0 0.0.0.0/0
412 41532 ACCEPT all -- * *
0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1 620 ACCEPT all -- eth1 *
0.0.0.0/0 0.0.0.0/0 mark match 0x1
0 0 ACCEPT esp -- * *
0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- eth1 *
0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT icmp -- eth1 *
0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 1/sec
burst 5
0 0 DROP tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent:
UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source
0 0 tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent:
SET name: DEFAULT side: source
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- * *
0.0.0.0/0 0.0.0.0/0 tcp dpt:5667
18 3230 LOG all -- * *
0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
18 3230 REJECT all -- * *
0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
And you can see here that we do not get anymore matched packets in the
filter/INPUT table nor are anymore vpn packets found (udp port 4500).
Sincerely,
Dennison Williams
next prev parent reply other threads:[~2010-04-02 7:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-02 0:35 MARK not working Dennison Williams
2010-04-02 4:57 ` Marek Kierdelewicz
2010-04-02 7:27 ` Dennison Williams [this message]
2010-04-02 9:16 ` Marek Kierdelewicz
2010-04-02 11:30 ` Jan Engelhardt
[not found] ` <006a01cad270$b1876110$14962330$@toure@vipnet.ci>
2010-04-02 14:37 ` setting quotas with quota Jan Engelhardt
2010-04-02 20:35 ` MARK not working Dennison Williams
2010-04-02 11:26 ` Jan Engelhardt
2010-04-02 13:02 ` Marek Kierdelewicz
2010-04-02 7:24 ` John Lister
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=4BB59C59.50607@gmail.com \
--to=dennison.williams@gmail.com \
--cc=netfilter@vger.kernel.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.