[PATCH] netfilter: nf_nat: avoid double nat for loopback

[PATCH] netfilter: nf_nat: avoid double nat for loopback

[Julian Anastasov]

	Avoid double NAT and seq adjustment for loopback
traffic because it causes silent repetition of TCP data. One
example is passive FTP with DNAT rule and difference in the
length of IP addresses.

	This patch adds checks if packet is sent and
received via loopback device. As the same conntrack is used
both for outgoing and incoming direction, we restrict NAT,
seq adjustment and confirmation to happen only in
outgoing direction (OUTPUT and POSTROUTING).

Signed-off-by: Julian Anastasov <ja@ssi.bg>
---

	As the check is not so cheap, another alternative
is to add new skb flag, eg. "loopback", that can be set in 
drivers/net/loopback.c, loopback_xmit(). May be there is space
for it in flags2?

diff -urp v2.6.39/linux/include/net/netfilter/nf_conntrack.h linux/include/net/netfilter/nf_conntrack.h
--- v2.6.39/linux/include/net/netfilter/nf_conntrack.h	2011-05-20 10:38:04.000000000 +0300
+++ linux/include/net/netfilter/nf_conntrack.h	2011-06-04 14:53:54.636380393 +0300
@@ -308,6 +308,12 @@ static inline int nf_ct_is_untracked(con
 	return test_bit(IPS_UNTRACKED_BIT, &ct->status);
 }
 
+/* Packet is received from loopback */
+static inline bool nf_is_loopback_packet(const struct sk_buff *skb)
+{
+	return skb->dev && skb->skb_iif && skb->dev->flags & IFF_LOOPBACK;
+}
+
 extern int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp);
 extern unsigned int nf_conntrack_htable_size;
 extern unsigned int nf_conntrack_max;
diff -urp v2.6.39/linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
--- v2.6.39/linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c	2010-08-02 09:37:49.000000000 +0300
+++ linux/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c	2011-06-04 14:17:28.223380526 +0300
@@ -99,6 +99,10 @@ static unsigned int ipv4_confirm(unsigne
 	const struct nf_conntrack_helper *helper;
 	unsigned int ret;
 
+	/* loopback traffic is confirmed only in outgoing direction */
+	if (unlikely(nf_is_loopback_packet(skb)))
+		return NF_ACCEPT;
+
 	/* This is where we call the helper: as the packet goes out. */
 	ct = nf_ct_get(skb, &ctinfo);
 	if (!ct || ctinfo == IP_CT_RELATED + IP_CT_IS_REPLY)
diff -urp v2.6.39/linux/net/ipv4/netfilter/nf_nat_standalone.c linux/net/ipv4/netfilter/nf_nat_standalone.c
--- v2.6.39/linux/net/ipv4/netfilter/nf_nat_standalone.c	2011-05-20 10:38:08.000000000 +0300
+++ linux/net/ipv4/netfilter/nf_nat_standalone.c	2011-06-04 14:55:02.542587345 +0300
@@ -86,6 +86,10 @@ nf_nat_fn(unsigned int hooknum,
 	/* maniptype == SRC for postrouting. */
 	enum nf_nat_manip_type maniptype = HOOK2MANIP(hooknum);
 
+	/* NAT for loopback traffic is done only in outgoing direction */
+	if (unlikely(nf_is_loopback_packet(skb)))
+		return NF_ACCEPT;
+
 	/* We never see fragments: conntrack defrags on pre-routing
 	   and local-out, and nf_nat_out protects post-routing. */
 	NF_CT_ASSERT(!(ip_hdr(skb)->frag_off & htons(IP_MF | IP_OFFSET)));

Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback

[Patrick McHardy]

On 04.06.2011 16:02, Julian Anastasov wrote:
> 
> 	Avoid double NAT and seq adjustment for loopback
> traffic because it causes silent repetition of TCP data. One
> example is passive FTP with DNAT rule and difference in the
> length of IP addresses.
> 
> 	This patch adds checks if packet is sent and
> received via loopback device. As the same conntrack is used
> both for outgoing and incoming direction, we restrict NAT,
> seq adjustment and confirmation to happen only in
> outgoing direction (OUTPUT and POSTROUTING).
> 
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
> ---
> 
> 	As the check is not so cheap, another alternative
> is to add new skb flag, eg. "loopback", that can be set in 
> drivers/net/loopback.c, loopback_xmit(). May be there is space
> for it in flags2?

I don't think we should be adding code specifically needed for netfilter
to the loopback driver if we can avoid it. I don't think we need to
actually avoid calling nf_nat_packet twice, that shouldn't do any harm,
just the sequence number adjustment. So we could add the loopback check
to the IPS_SEQ_ADJUST_BIT case to at least avoid it in some cases.
Would that work or am I missing something?

Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback

[Julian Anastasov]

	Hello,

On Tue, 7 Jun 2011, Patrick McHardy wrote:

> On 04.06.2011 16:02, Julian Anastasov wrote:
> > 
> > 	Avoid double NAT and seq adjustment for loopback
> > traffic because it causes silent repetition of TCP data. One
> > example is passive FTP with DNAT rule and difference in the
> > length of IP addresses.
> > 
> > 	This patch adds checks if packet is sent and
> > received via loopback device. As the same conntrack is used
> > both for outgoing and incoming direction, we restrict NAT,
> > seq adjustment and confirmation to happen only in
> > outgoing direction (OUTPUT and POSTROUTING).
> > 
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > ---
> > 
> > 	As the check is not so cheap, another alternative
> > is to add new skb flag, eg. "loopback", that can be set in 
> > drivers/net/loopback.c, loopback_xmit(). May be there is space
> > for it in flags2?
> 
> I don't think we should be adding code specifically needed for netfilter
> to the loopback driver if we can avoid it. I don't think we need to
> actually avoid calling nf_nat_packet twice, that shouldn't do any harm,
> just the sequence number adjustment. So we could add the loopback check

	Yes, may be calling nf_nat_packet is not fatal.

> to the IPS_SEQ_ADJUST_BIT case to at least avoid it in some cases.
> Would that work or am I missing something?

	Logically, the new check can be after
test_bit(IPS_SEQ_ADJUST_BIT, &ct->status). But I suspect
some modules adjust seqs in the helper->help call,
for example, sip_help_tcp if I'm correctly reading the
code.

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback

[Patrick McHardy]

On 07.06.2011 21:46, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Tue, 7 Jun 2011, Patrick McHardy wrote:
> 
>> On 04.06.2011 16:02, Julian Anastasov wrote:
>>>
>>> 	Avoid double NAT and seq adjustment for loopback
>>> traffic because it causes silent repetition of TCP data. One
>>> example is passive FTP with DNAT rule and difference in the
>>> length of IP addresses.
>>>
>>> 	This patch adds checks if packet is sent and
>>> received via loopback device. As the same conntrack is used
>>> both for outgoing and incoming direction, we restrict NAT,
>>> seq adjustment and confirmation to happen only in
>>> outgoing direction (OUTPUT and POSTROUTING).
>>>
>>> Signed-off-by: Julian Anastasov <ja@ssi.bg>
>>> ---
>>>
>>> 	As the check is not so cheap, another alternative
>>> is to add new skb flag, eg. "loopback", that can be set in 
>>> drivers/net/loopback.c, loopback_xmit(). May be there is space
>>> for it in flags2?
>>
>> I don't think we should be adding code specifically needed for netfilter
>> to the loopback driver if we can avoid it. I don't think we need to
>> actually avoid calling nf_nat_packet twice, that shouldn't do any harm,
>> just the sequence number adjustment. So we could add the loopback check
> 
> 	Yes, may be calling nf_nat_packet is not fatal.
> 
>> to the IPS_SEQ_ADJUST_BIT case to at least avoid it in some cases.
>> Would that work or am I missing something?
> 
> 	Logically, the new check can be after
> test_bit(IPS_SEQ_ADJUST_BIT, &ct->status). But I suspect
> some modules adjust seqs in the helper->help call,
> for example, sip_help_tcp if I'm correctly reading the
> code.

Yes, you're right. But it's the only one since it's the only helper
doing possibly many modifications on a single TCP packet, which can't
be handled by the generic code properly. So if you're worried about
performance costs, I'd have no problems adding this check to the SIP
helper.

Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback

[Julian Anastasov]

	Hello,

On Wed, 8 Jun 2011, Patrick McHardy wrote:

> >> to the IPS_SEQ_ADJUST_BIT case to at least avoid it in some cases.
> >> Would that work or am I missing something?
> > 
> > 	Logically, the new check can be after
> > test_bit(IPS_SEQ_ADJUST_BIT, &ct->status). But I suspect
> > some modules adjust seqs in the helper->help call,
> > for example, sip_help_tcp if I'm correctly reading the
> > code.
> 
> Yes, you're right. But it's the only one since it's the only helper
> doing possibly many modifications on a single TCP packet, which can't
> be handled by the generic code properly. So if you're worried about
> performance costs, I'd have no problems adding this check to the SIP
> helper.

	OK, I'm posting new version just for seq adjustment.
I'm not fixing sip_help_tcp because I'm not sure what is
the right fix, we must be sure that calling sip_help_tcp
twice is not a problem.

Regards

--
Julian Anastasov <ja@ssi.bg>