* MARK not working
@ 2010-04-02 0:35 Dennison Williams
2010-04-02 4:57 ` Marek Kierdelewicz
2010-04-02 7:24 ` John Lister
0 siblings, 2 replies; 10+ messages in thread
From: Dennison Williams @ 2010-04-02 0:35 UTC (permalink / raw)
To: netfilter
Hello,
I am having a problem receiving marked packets from the mangle table in
my filter table. I have:
iptables -t mangle -A PREROUTING -i eth1 -p udp --dport 4500 -j MARK
--set-mark 1
iptables -t filter -A INPUT -m mark --mark 1 -j LOG --log-prefix ipsec_nat_t
iptables -t filter -A INPUT -m mark --mark 1 -j ACCEPT
iptables -t filter -A INPUT -j LOG
iptables -t filter -A INPUT -j REJECT
I see that the packets are correctly getting marked in the mangle table,
but then it bypasses the log and accept rules eventually getting logged
and rejected. I have trimmed the ruleset down a fair amount to try and
find the problem but I can't seem to get to the cause. While I have
seen a fair amount of this subject on the mailing list I have not found
anything that seems relevant to this issue.
All feedback is appreciated. More details below.
Sincerely,
DennisonWilliams
Kernel: 2.6.26-2-486
Distro: Debian 5.0.4
Iptables version: v1.4.2
iptables-save output:
# Generated by iptables-save v1.4.2 on Thu Apr 1 17:27:16 2010
*nat
:PREROUTING ACCEPT [67:12256]
:POSTROUTING ACCEPT [106:6673]
:OUTPUT ACCEPT [106:6673]
-A POSTROUTING -s 10.66.6.0/24 -d ! 10.66.7.0/24 -o eth1 -j MASQUERADE
COMMIT
# Completed on Thu Apr 1 17:27:16 2010
# Generated by iptables-save v1.4.2 on Thu Apr 1 17:27:16 2010
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [617:152871]
:OUTPUT ACCEPT [1282:293981]
:Accounting - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth2 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p esp -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -i eth1 -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -m mark --mark 0x1 -j LOG --log-prefix "ipsec_nat_t"
-A INPUT -m mark --mark 0x1 -j ACCEPT
-A INPUT -j LOG
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Thu Apr 1 17:27:16 2010
# Generated by iptables-save v1.4.2 on Thu Apr 1 17:27:16 2010
*mangle
:PREROUTING ACCEPT [2504:776880]
:INPUT ACCEPT [1548:605475]
:FORWARD ACCEPT [956:171405]
:OUTPUT ACCEPT [1285:295001]
:POSTROUTING ACCEPT [2241:466406]
-A PREROUTING -i eth1 -p udp -m udp --dport 4500 -j MARK --set-xmark
0x1/0xffffffff
COMMIT
# Completed on Thu Apr 1 17:27:16 2010
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MARK not working
2010-04-02 0:35 MARK not working Dennison Williams
@ 2010-04-02 4:57 ` Marek Kierdelewicz
2010-04-02 7:27 ` Dennison Williams
2010-04-02 11:26 ` Jan Engelhardt
2010-04-02 7:24 ` John Lister
1 sibling, 2 replies; 10+ messages in thread
From: Marek Kierdelewicz @ 2010-04-02 4:57 UTC (permalink / raw)
To: Dennison Williams; +Cc: netfilter
>Hello,
Hi,
>I am having a problem receiving marked packets from the mangle table in
>my filter table. I have:
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
Regards,
Marek
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MARK not working
2010-04-02 4:57 ` Marek Kierdelewicz
@ 2010-04-02 7:27 ` Dennison Williams
2010-04-02 9:16 ` Marek Kierdelewicz
2010-04-02 11:30 ` Jan Engelhardt
2010-04-02 11:26 ` Jan Engelhardt
1 sibling, 2 replies; 10+ messages in thread
From: Dennison Williams @ 2010-04-02 7:27 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Re: MARK not working
2010-04-02 7:27 ` Dennison Williams
@ 2010-04-02 9:16 ` Marek Kierdelewicz
2010-04-02 11:30 ` Jan Engelhardt
1 sibling, 0 replies; 10+ messages in thread
From: Marek Kierdelewicz @ 2010-04-02 9:16 UTC (permalink / raw)
To: Dennison Williams; +Cc: netfilter
Hi,
>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).
I think you're missing rule accepting traffic entering VPN
connection interface.
Try adding ACCEPT in INPUT or MARK 0x1 in PREROUTING for udp dport
1701. Alternatively you can MARK/ACCEPT incomming traffic on VPN
interface (eg. tap0 - vpn interface, then -i tap0).
The same will apply to traffic comming on l2tp interface if you going to
terminate the connection on very same box.
Hope that helps.
Regards,
Marek
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MARK not working
2010-04-02 7:27 ` Dennison Williams
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 20:35 ` MARK not working Dennison Williams
1 sibling, 2 replies; 10+ messages in thread
From: Jan Engelhardt @ 2010-04-02 11:30 UTC (permalink / raw)
To: Dennison Williams; +Cc: netfilter
On Friday 2010-04-02 09:27, Dennison Williams wrote:
>Before brining up the vpn I flush both mangle/PREROUTING and
>filter/INPUT tables:
># iptables -t filter -Z
># iptables -t mangle -Z PREROUTING
>
Deparsing this mess..
>I then succesfully bring up the vpn connection and provide a count of
>the two tables:
># 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
There is your mark-1 packet, and right above it is the ESTABLISHED
rule that catches all the other packets that have this condition,
including those marked 1 which are subsequent in the IKE talk.
^ permalink raw reply [flat|nested] 10+ messages in thread[parent not found: <006a01cad270$b1876110$14962330$@toure@vipnet.ci>]
* Re: setting quotas with quota
[not found] ` <006a01cad270$b1876110$14962330$@toure@vipnet.ci>
@ 2010-04-02 14:37 ` Jan Engelhardt
0 siblings, 0 replies; 10+ messages in thread
From: Jan Engelhardt @ 2010-04-02 14:37 UTC (permalink / raw)
To: Toure Mamadou; +Cc: 'Dennison Williams', netfilter
On Friday 2010-04-02 16:27, Toure Mamadou wrote:
>when i run this :
>iptables -L FORWARD -v
>
>I got this output :
>pkts bytes target prot opt in out source destination
>2786 3744K ACCEPT udp -- any any anywhere anywhere udp dpt:search-agent
>quota: 1024 bytes
>
>But when traffic pass through my box I got this output of iptables -L
>FORWARD -v pkts bytes target prot opt in out source destination
>2786 3744K ACCEPT udp -- any any anywhere anywhere udp dpt:search-agent
>quota: 13976899182565778736 bytes
>
>Why the quota is too big even i have fixe to 1024.
>I'm using kernel 2.6.30 with iptable 1.4.4 Note : I did not made any pach
>for kernel nor iptable.
The 139... is caused by a bug present in kernels before 2.6.31.
Additionally, the quota cannot be displayed with iptables
(it will stay at 1024 starting from 2.6.31), as the kernel
does not export the current counter back to userspace.
You will have to use xt_quota2 and its procfs interface to read
the counters back.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MARK not working
2010-04-02 11:30 ` Jan Engelhardt
[not found] ` <006a01cad270$b1876110$14962330$@toure@vipnet.ci>
@ 2010-04-02 20:35 ` Dennison Williams
1 sibling, 0 replies; 10+ messages in thread
From: Dennison Williams @ 2010-04-02 20:35 UTC (permalink / raw)
To: netfilter
Jan Engelhardt wrote:
> There is your mark-1 packet, and right above it is the ESTABLISHED
> rule that catches all the other packets that have this condition,
> including those marked 1 which are subsequent in the IKE talk
>
Right you are. I messed around with the order of the rules and noticed
that the packets were in fact getting marked. It turns out I
misdiagnosed the problem which seems to actually be with the vpn
software not encapsulating the packets. Thanks for your time.
Sincerely,
Dennison Williams
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MARK not working
2010-04-02 4:57 ` Marek Kierdelewicz
2010-04-02 7:27 ` Dennison Williams
@ 2010-04-02 11:26 ` Jan Engelhardt
2010-04-02 13:02 ` Marek Kierdelewicz
1 sibling, 1 reply; 10+ messages in thread
From: Jan Engelhardt @ 2010-04-02 11:26 UTC (permalink / raw)
To: Marek Kierdelewicz; +Cc: Dennison Williams, netfilter
On Friday 2010-04-02 06:57, Marek Kierdelewicz wrote:
>
>>I am having a problem receiving marked packets from the mangle table in
>>my filter table. I have:
>
>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
There is no such rule (given in the mail).
>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
Use `iptables-save -c`, it's much more complete and better to parse
because it does not try to make a pretty-print table that always wraps
in e-mail anyway.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MARK not working
2010-04-02 11:26 ` Jan Engelhardt
@ 2010-04-02 13:02 ` Marek Kierdelewicz
0 siblings, 0 replies; 10+ messages in thread
From: Marek Kierdelewicz @ 2010-04-02 13:02 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Dennison Williams, netfilter
Hi,
>>-A INPUT -i eth1 -p udp -m udp --dport 4500 -j ACCEPT
>There is no such rule (given in the mail).
There was one at the end of email in the iptables-save output.
>Use `iptables-save -c`, it's much more complete and better to parse
>because it does not try to make a pretty-print table that always wraps
>in e-mail anyway.
True ;-). Looks much better.
Regards,
Marek
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MARK not working
2010-04-02 0:35 MARK not working Dennison Williams
2010-04-02 4:57 ` Marek Kierdelewicz
@ 2010-04-02 7:24 ` John Lister
1 sibling, 0 replies; 10+ messages in thread
From: John Lister @ 2010-04-02 7:24 UTC (permalink / raw)
To: Dennison Williams; +Cc: netfilter
Dennison Williams wrote:
> iptables -t mangle -A PREROUTING -i eth1 -p udp --dport 4500 -j MARK
> --set-mark 1
> iptables -t filter -A INPUT -m mark --mark 1 -j LOG --log-prefix ipsec_nat_t
> iptables -t filter -A INPUT -m mark --mark 1 -j ACCEPT
> iptables -t filter -A INPUT -j LOG
> iptables -t filter -A INPUT -j REJECT
>
In general make sure that you are saving the marks to the conntrack
tables and restoring them with
-j CONNTRACK --save-mark
and
-j CONNTRACK --restore-mark
although in your sample this doesn't matter as you tag every incoming
packet and as the other post notes, you seem to accept the connections
before your logging.
I usually only set the mark when the state is NEW
John
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-04-02 20:35 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-02 0:35 MARK not working Dennison Williams
2010-04-02 4:57 ` Marek Kierdelewicz
2010-04-02 7:27 ` Dennison Williams
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).