* conntrack helpers in kernel 4.7
@ 2016-08-11 8:52 Marc Haber
2016-08-11 11:34 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: Marc Haber @ 2016-08-11 8:52 UTC (permalink / raw)
To: netfilter
Hi,
I am running my firewall at home with Debian stable (which has
iptables 1.4.21) with a current kernel. Since the update to kernel
4.7, my connection tracking seems to be broken which shows itself in
sporadic malfunctions of SIP telephony. Protocols not needing
conntrack helpers do still work fine.
I have found the document "Secure use of iptables and connection
tracking helpers" on
https://home.regit.org/netfilter-en/secure-use-of-helpers/ and am
currently suspecting that support for the legacy mechanisms has been
removed in kernel 4.7 since the reject log messages for SIP packets
have started after I upgraded to linux 4.7.
However, I don't find anything about millions of firewalls suddenly
going up in flames on the net, which suggests that the phenomenon seen
on my system is not widely observed and that my hypothesis is wrong.
I have taken the opportunity of finally adding mod conntrack to my
existing (and unchanged) mod state rules. Since my mod state rules
don't apply any more (everythign seems to be caught by the mod
conntrack rules, I think this is fine.
I am at a loss about how to define the RELATED rules that need the
explicitly mention the helper. Regardless of how I write the rules,
they don't seem to apply and a lot of my SIP packets ends up in the
final REJECT rule.
Here is the relevant part of my rule set:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp spt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp dpt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp dpts:1:65535 helper match "sip"
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED udp spt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED udp dpt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED udp dpts:1:65535 helper match "sip"
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED helper match "sip"
694 307K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
180 18459 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
670 64703 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix "input "
670 64703 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- int181 int181 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int191 int191 0.0.0.0/0 0.0.0.0/0
2 120 ACCEPT all -- int182 int182 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int192 int192 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int183 int183 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int184 int184 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int185 int185 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int186 int186 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int187 int187 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int188 int188 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- int189 int189 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- per281 per281 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- unt381 unt381 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- unt382 unt382 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- unt383 unt383 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- int186 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- int187 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
209 97813 ACCEPT udp -- int+ * 0.0.0.0/0 192.168.181.161 udp spt:68 dpt:67
0 0 ACCEPT udp -- int+ * 0.0.0.0/0 192.168.251.12 udp spt:68 dpt:67
0 0 ACCEPT udp -- int+ * 0.0.0.0/0 192.168.251.9 udp spt:68 dpt:67
0 0 ACCEPT udp -- int+ * 0.0.0.0/0 192.168.251.53 udp spt:68 dpt:67
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp spt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp dpt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp dpts:1:65535 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED udp spt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED udp dpt:5060 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED udp dpts:1:65535 helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate ESTABLISHED helper match "sip"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp spt:69 helper match "tftp"
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED udp dpt:69 helper match "tftp"
1093K 729M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
4003 208K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
43793 1897K int185in all -- int185 * 0.0.0.0/0 0.0.0.0/0
Chain int185in (1 references)
pkts bytes target prot opt in out source destination
42506 1812K ACCEPT all -- * unt+ 192.168.185.250 0.0.0.0/0
0 0 ACCEPT all -- * int181 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * int191 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * int182 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * per281 0.0.0.0/0 0.0.0.0/0
1287 84228 ACCEPT all -- * unt381 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * unt382 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * unt383 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 16480 packets, 1385K bytes)
pkts bytes target prot opt in out source destination
9046 577K MASQUERADE all -- * unt+ 192.168.184.0/23 0.0.0.0/0
If you prefer reading iptables-save output, I have pasted it under my
signature.
192.168.185.250 is my internal SIP machine. The firewall does also NAT
for the machines on the internal networks.
And here is what my firewall logs when someone tries to call me:
Aug 10 21:31:09 barrida kernel: input IN=unt381 OUT= MAC=1a:db:fb:4d:fd:f8:9c:c7:a6:2a:f6:09:08:00:45:10:05:94 SRC=212.227.67.205 DST=192.168.251.241 LEN=1428 TOS=0x10 PREC=0x00 TTL=56 ID=8610 PROTO=UDP SPT=5060 DPT=5060 LEN=1408
This confuses me:
(1) Why does the packet end up in the input queue in the first place?
To me, this looks like the incoming packet on unt381 is not correctly
tracked by the NAT code. It should be natted and processed by the
FORWARD chain.
(2) Why are the packet counters of all ctstate rules with helper match
"sip" at zero? Why don't they apply for the incoming packet which
seems to fall through until the concluding REJECT rule?
(3) do I need the PREROUTING --jump CT rule mentioned in the Securing
helpers page if I only use the default Port 5060?
I would appreciate your hints.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
iptables-save:
# Generated by iptables-save v1.4.21 on Thu Aug 11 10:48:27 2016
*raw
:PREROUTING ACCEPT [1195282:737239692]
:OUTPUT ACCEPT [5928:1550650]
COMMIT
# Completed on Thu Aug 11 10:48:27 2016
# Generated by iptables-save v1.4.21 on Thu Aug 11 10:48:27 2016
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [5927:1550562]
-A INPUT -p udp -m conntrack --ctstate RELATED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate RELATED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate RELATED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED -m helper --helper sip -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate ESTABLISHED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED -m helper --helper sip -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -m state --state INVALID -j DROP
-A INPUT -j LOG --log-prefix "input "
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i int181 -o int181 -j ACCEPT
-A FORWARD -i int191 -o int191 -j ACCEPT
-A FORWARD -i int182 -o int182 -j ACCEPT
-A FORWARD -i int192 -o int192 -j ACCEPT
-A FORWARD -i int183 -o int183 -j ACCEPT
-A FORWARD -i int184 -o int184 -j ACCEPT
-A FORWARD -i int185 -o int185 -j ACCEPT
-A FORWARD -i int186 -o int186 -j ACCEPT
-A FORWARD -i int187 -o int187 -j ACCEPT
-A FORWARD -i int188 -o int188 -j ACCEPT
-A FORWARD -i int189 -o int189 -j ACCEPT
-A FORWARD -i per281 -o per281 -j ACCEPT
-A FORWARD -i unt381 -o unt381 -j ACCEPT
-A FORWARD -i unt382 -o unt382 -j ACCEPT
-A FORWARD -i unt383 -o unt383 -j ACCEPT
-A FORWARD -i int186 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i int187 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -d 192.168.181.161/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A FORWARD -d 192.168.251.12/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A FORWARD -d 192.168.251.9/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A FORWARD -d 192.168.251.53/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate RELATED -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m helper --helper sip -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --sport 69 -m helper --helper tftp -j ACCEPT
-A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --dport 69 -m helper --helper tftp -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -i int185 -j int185in
-A int185in -s 192.168.185.250/32 -o unt+ -j ACCEPT
-A int185in -o int181 -j ACCEPT
-A int185in -o int191 -j ACCEPT
-A int185in -o int182 -j ACCEPT
-A int185in -o per281 -j ACCEPT
-A int185in -o unt381 -j ACCEPT
-A int185in -o unt382 -j ACCEPT
-A int185in -o unt383 -j ACCEPT
*nat
:PREROUTING ACCEPT [55038:4057737]
:INPUT ACCEPT [548:153919]
:OUTPUT ACCEPT [1641:284010]
:POSTROUTING ACCEPT [16536:1391079]
-A POSTROUTING -s 192.168.184.0/23 -o unt+ -j MASQUERADE
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack helpers in kernel 4.7
2016-08-11 8:52 conntrack helpers in kernel 4.7 Marc Haber
@ 2016-08-11 11:34 ` Pablo Neira Ayuso
2016-08-11 11:53 ` Marc Haber
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2016-08-11 11:34 UTC (permalink / raw)
To: Marc Haber; +Cc: netfilter
On Thu, Aug 11, 2016 at 10:52:51AM +0200, Marc Haber wrote:
> Hi,
>
> I am running my firewall at home with Debian stable (which has
> iptables 1.4.21) with a current kernel. Since the update to kernel
> 4.7, my connection tracking seems to be broken which shows itself in
> sporadic malfunctions of SIP telephony. Protocols not needing
> conntrack helpers do still work fine.
>
> I have found the document "Secure use of iptables and connection
> tracking helpers" on
> https://home.regit.org/netfilter-en/secure-use-of-helpers/ and am
> currently suspecting that support for the legacy mechanisms has been
> removed in kernel 4.7 since the reject log messages for SIP packets
> have started after I upgraded to linux 4.7.
You can still recover the old automagic behaviour by:
echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper
But that will go away too at some point given this behaviour is
unsecure as the document above describes, so please don't give up on
upgrading your ruleset.
[...]
> This confuses me:
>
> (1) Why does the packet end up in the input queue in the first place?
> To me, this looks like the incoming packet on unt381 is not correctly
> tracked by the NAT code. It should be natted and processed by the
> FORWARD chain.
>
> (2) Why are the packet counters of all ctstate rules with helper match
> "sip" at zero? Why don't they apply for the incoming packet which
> seems to fall through until the concluding REJECT rule?
Because no conntrack entries are getting the sip helper attached.
> (3) do I need the PREROUTING --jump CT rule mentioned in the Securing
> helpers page if I only use the default Port 5060?
Yes, the CT target explicitly attach the conntrack helper, so you
need something like:
-A PREROUTING -t raw -p udp --dport 5060 -j CT --helper sip
This plugs the sip helper to every new flow going to port 5060.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack helpers in kernel 4.7
2016-08-11 11:34 ` Pablo Neira Ayuso
@ 2016-08-11 11:53 ` Marc Haber
2016-08-11 12:17 ` Pablo Neira Ayuso
0 siblings, 1 reply; 6+ messages in thread
From: Marc Haber @ 2016-08-11 11:53 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter
Hi Pablo,
thanks for helping!
On Thu, Aug 11, 2016 at 01:34:35PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Aug 11, 2016 at 10:52:51AM +0200, Marc Haber wrote:
> > This confuses me:
> >
> > (1) Why does the packet end up in the input queue in the first place?
> > To me, this looks like the incoming packet on unt381 is not correctly
> > tracked by the NAT code. It should be natted and processed by the
> > FORWARD chain.
> >
> > (2) Why are the packet counters of all ctstate rules with helper match
> > "sip" at zero? Why don't they apply for the incoming packet which
> > seems to fall through until the concluding REJECT rule?
>
> Because no conntrack entries are getting the sip helper attached.
>
> > (3) do I need the PREROUTING --jump CT rule mentioned in the Securing
> > helpers page if I only use the default Port 5060?
>
> Yes, the CT target explicitly attach the conntrack helper, so you
> need something like:
>
> -A PREROUTING -t raw -p udp --dport 5060 -j CT --helper sip
>
> This plugs the sip helper to every new flow going to port 5060.
Can I see in conntrack(1) output whether a flow has a helper attached?
Is the helper supposed to be attached to the first packet only?
I now have:
Chain PREROUTING (policy ACCEPT 1909 packets, 445K bytes)
pkts bytes target prot opt in out source destination
0 0 CT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 helper match "sip" CT
# Generated by iptables-save v1.4.21 on Thu Aug 11 13:51:44 2016
*raw
:PREROUTING ACCEPT [2022:465365]
:OUTPUT ACCEPT [16:4970]
-A PREROUTING -p udp -m udp --dport 5060 -m helper --helper sip -j CT
and, as you can see, the rule counters are at zero while packets still
fall through to the REJECT rule t the end of the INPUT chain.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack helpers in kernel 4.7
2016-08-11 11:53 ` Marc Haber
@ 2016-08-11 12:17 ` Pablo Neira Ayuso
2016-08-11 13:29 ` Marc Haber
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2016-08-11 12:17 UTC (permalink / raw)
To: Marc Haber; +Cc: netfilter
On Thu, Aug 11, 2016 at 01:53:36PM +0200, Marc Haber wrote:
> On Thu, Aug 11, 2016 at 01:34:35PM +0200, Pablo Neira Ayuso wrote:
> > On Thu, Aug 11, 2016 at 10:52:51AM +0200, Marc Haber wrote:
> > > This confuses me:
> > >
> > > (1) Why does the packet end up in the input queue in the first place?
> > > To me, this looks like the incoming packet on unt381 is not correctly
> > > tracked by the NAT code. It should be natted and processed by the
> > > FORWARD chain.
> > >
> > > (2) Why are the packet counters of all ctstate rules with helper match
> > > "sip" at zero? Why don't they apply for the incoming packet which
> > > seems to fall through until the concluding REJECT rule?
> >
> > Because no conntrack entries are getting the sip helper attached.
> >
> > > (3) do I need the PREROUTING --jump CT rule mentioned in the Securing
> > > helpers page if I only use the default Port 5060?
> >
> > Yes, the CT target explicitly attach the conntrack helper, so you
> > need something like:
> >
> > -A PREROUTING -t raw -p udp --dport 5060 -j CT --helper sip
> >
> > This plugs the sip helper to every new flow going to port 5060.
>
> Can I see in conntrack(1) output whether a flow has a helper attached?
Yes, conntrack -L shows here:
tcp 6 431999 ESTABLISHED src=192.168.3.132 dst=130.89.148.12
sport=54736 dport=21 src=130.89.148.12 dst=192.168.3.132 sport=21
dport=54736 [ASSURED] mark=0 helper=ftp use=2
it should show similar thing for sip.
> Is the helper supposed to be attached to the first packet only?
It is attached to the flow and remains there until the flow is teared
down, the first packet creates the flow entry in the conntrack table.
By then, the helper is set up.
> I now have:
> Chain PREROUTING (policy ACCEPT 1909 packets, 445K bytes)
> pkts bytes target prot opt in out source destination
> 0 0 CT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 helper match "sip" CT
>
> # Generated by iptables-save v1.4.21 on Thu Aug 11 13:51:44 2016
> *raw
> :PREROUTING ACCEPT [2022:465365]
> :OUTPUT ACCEPT [16:4970]
> -A PREROUTING -p udp -m udp --dport 5060 -m helper --helper sip -j CT
note that:
-m helper sip
is used to match based on the helper name and you have no helper yet.
To attach the helper you have to use:
-j CT --helper sip
and remove the -m helper match given, so this looks like:
-A PREROUTING -p udp -m udp --dport 5060 -j CT --helper sip
in the raw table.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack helpers in kernel 4.7
2016-08-11 12:17 ` Pablo Neira Ayuso
@ 2016-08-11 13:29 ` Marc Haber
2016-08-11 19:44 ` Marc Haber
0 siblings, 1 reply; 6+ messages in thread
From: Marc Haber @ 2016-08-11 13:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter
Hi Pablo,
this looks good now.
On Thu, Aug 11, 2016 at 02:17:34PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Aug 11, 2016 at 01:53:36PM +0200, Marc Haber wrote:
> > Can I see in conntrack(1) output whether a flow has a helper attached?
>
> Yes, conntrack -L shows here:
>
> tcp 6 431999 ESTABLISHED src=192.168.3.132 dst=130.89.148.12
> sport=54736 dport=21 src=130.89.148.12 dst=192.168.3.132 sport=21
> dport=54736 [ASSURED] mark=0 helper=ftp use=2
>
> it should show similar thing for sip.
It does. I never saw the helper clause because I had the CT rule wrong.
> > Is the helper supposed to be attached to the first packet only?
>
> It is attached to the flow and remains there until the flow is teared
> down, the first packet creates the flow entry in the conntrack table.
> By then, the helper is set up.
But the rule attaching the helper needs to match the first packet of
the connection? Or does it suffice to slap the helper on any packet to
have it attached in the future?
> > -A PREROUTING -p udp -m udp --dport 5060 -m helper --helper sip -j CT
>
> note that:
>
> -m helper sip
>
> is used to match based on the helper name and you have no helper yet.
>
> To attach the helper you have to use:
>
> -j CT --helper sip
>
> and remove the -m helper match given, so this looks like:
>
> -A PREROUTING -p udp -m udp --dport 5060 -j CT --helper sip
>
> in the raw table.
Ah! I missed the difference between CT --helper and --module helper.
jftr, in ferm this would be
table raw {
chain PREROUTING {
proto udp dport 5060 CT helper sip;
}
}
Just to be sure: The changes needed are only related to protocols that
need helpers, --mod conntrack --ctstate ESTABLISHED/RELATED works the
same as --mod state --state ESTABLISHED/RELATED for other things such
as ICMP messages regarding a connection etc foo?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: conntrack helpers in kernel 4.7
2016-08-11 13:29 ` Marc Haber
@ 2016-08-11 19:44 ` Marc Haber
0 siblings, 0 replies; 6+ messages in thread
From: Marc Haber @ 2016-08-11 19:44 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter
Hi,
I can confirm that my telephone works again with the following rules:
# Generated by iptables-save v1.4.21 on Thu Aug 11 21:16:57 2016
*raw
:PREROUTING ACCEPT [47907:21288529]
:OUTPUT ACCEPT [475:103181]
[1308:89383] -A PREROUTING -p udp -m udp --dport 5060 -j CT --helper sip
[8:479] -A PREROUTING -p udp -m udp --dport 69 -j CT --helper tftp
COMMIT
[0:0] -A INPUT -p udp -m conntrack --ctstate RELATED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A INPUT -p udp -m conntrack --ctstate RELATED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A INPUT -p udp -m conntrack --ctstate RELATED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
[0:0] -A INPUT -m conntrack --ctstate RELATED -m helper --helper sip -j ACCEPT
[0:0] -A INPUT -p udp -m conntrack --ctstate RELATED -m udp --dport 79 -m helper --helper tftp -j ACCEPT
[0:0] -A INPUT -p udp -m conntrack --ctstate ESTABLISHED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A INPUT -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A INPUT -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
[0:0] -A INPUT -m conntrack --ctstate ESTABLISHED -m helper --helper sip -j ACCEPT
[507:46400] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
[5:200] -A INPUT -m conntrack --ctstate INVALID -j DROP
[0:0] -A INPUT -m state --state INVALID -j DROP
[0:0] -A FORWARD -i int181 -o int181 -j ACCEPT
[0:0] -A FORWARD -i int191 -o int191 -j ACCEPT
[0:0] -A FORWARD -i int182 -o int182 -j ACCEPT
[0:0] -A FORWARD -i int192 -o int192 -j ACCEPT
[0:0] -A FORWARD -i int183 -o int183 -j ACCEPT
[0:0] -A FORWARD -i int184 -o int184 -j ACCEPT
[0:0] -A FORWARD -i int185 -o int185 -j ACCEPT
[0:0] -A FORWARD -i int186 -o int186 -j ACCEPT
[0:0] -A FORWARD -i int187 -o int187 -j ACCEPT
[0:0] -A FORWARD -i int188 -o int188 -j ACCEPT
[0:0] -A FORWARD -i int189 -o int189 -j ACCEPT
[0:0] -A FORWARD -i per281 -o per281 -j ACCEPT
[0:0] -A FORWARD -i unt381 -o unt381 -j ACCEPT
[0:0] -A FORWARD -i unt382 -o unt382 -j ACCEPT
[0:0] -A FORWARD -i unt383 -o unt383 -j ACCEPT
[0:0] -A FORWARD -i int186 -j REJECT --reject-with icmp-port-unreachable
[0:0] -A FORWARD -i int187 -j REJECT --reject-with icmp-port-unreachable
[5:2139] -A FORWARD -d 192.168.181.161/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
[0:0] -A FORWARD -d 192.168.251.12/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
[0:0] -A FORWARD -d 192.168.251.9/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
[0:0] -A FORWARD -d 192.168.251.53/32 -i int+ -p udp -m udp --sport 68 --dport 67 -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate RELATED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate RELATED -m helper --helper sip -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m udp --sport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 5060 -m helper --helper sip -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m udp --dport 1:65535 -m helper --helper sip -j ACCEPT
[0:0] -A FORWARD -p udp -m conntrack --ctstate ESTABLISHED -m helper --helper sip -j ACCEPT
[44343:21048968] -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
[30:1464] -A FORWARD -m conntrack --ctstate INVALID -j DROP
[0:0] -A FORWARD -m state --state INVALID -j DROP
[1120:42740] -A FORWARD -i int185 -j int185in
[995:34560] -A int185in -s 192.168.185.250/32 -o unt+ -j ACCEPT
[0:0] -A int185in -o int181 -j ACCEPT
[0:0] -A int185in -o int191 -j ACCEPT
[0:0] -A int185in -o int182 -j ACCEPT
[0:0] -A int185in -o per281 -j ACCEPT
[125:8180] -A int185in -o unt381 -j ACCEPT
[0:0] -A int185in -o unt382 -j ACCEPT
[0:0] -A int185in -o unt383 -j ACCEPT
However, I am wondering why the counter in my helper match rules stay
at zero. I would expect them to count packets and bytes. Is this the
expected behavior?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-08-11 19:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-11 8:52 conntrack helpers in kernel 4.7 Marc Haber
2016-08-11 11:34 ` Pablo Neira Ayuso
2016-08-11 11:53 ` Marc Haber
2016-08-11 12:17 ` Pablo Neira Ayuso
2016-08-11 13:29 ` Marc Haber
2016-08-11 19:44 ` Marc Haber
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.