MARK not working
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
Quoted 1 line
Hello,
Hi,
Quoted 2 lines
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:
Quoted 1 line
-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
Quoted 11 lines · Marek Kierdelewicz
I think packets marked
0x1in prerouting should never reach LOG & ACCEPT rule because of the following rule before them:Quoted 2 lines
-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-unreachableThen 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/0xffffffffYou 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-unreachableAnd 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
Hi,
Quoted 4 lines
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
Quoted 5 lines · Dennison Williams
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..
Quoted 18 lines
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.
A message that is not in the archive (sent off-list or not yet received): 006a01cad270$b1876110$14962330$@[email protected]
Re: setting quotas with quota
Quoted 8 lines · Toure Mamadou
when i run this :
iptables -L FORWARD -vI 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
Quoted 8 lines
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 bytesWhy 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.
Quoted 4 lines · Jan Engelhardt
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
Quoted 8 lines · Marek Kierdelewicz
Quoted 3 lines
I am having a problem receiving marked packets from the mangle table in my filter table. I have:
I think packets marked
0x1in prerouting should never reach LOG & ACCEPT rule because of the following rule before them:Quoted 1 line
-A INPUT -i eth1 -p udp -m udp --dport 4500 -j ACCEPT
There is no such rule (given in the mail).
Quoted 4 lines
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.
Hi,
Quoted 3 lines
Quoted 1 line
-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.
Quoted 3 lines
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
Quoted 7 lines · Dennison Williams
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-prefixipsec_nat_tiptables -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