Harald Welte wrote:
On Sat, Aug 06, 2005 at 02:08:15AM +0400, Vladimir B. Savkin wrote:
I found that it really is NOTRACK who cause? bogus ICMP errors.
Good work tracking this down. I've seen reports of this before, but
never found the reason.
Well, this means that your ICMP errors need to be NAT'ed but they
cannot, since the original connection causing the ICMP error did not go
through connection tracking.
Your not-correctly-NATed ICMP packets are the logical result of this
configuration.
Use of NOTRACK in combination with NAT is _extremely_ dangerous, and
unless you understand it's full implications, I would not recommend
combining the two.
So it seems your use of NOTRACK is invalid in this setup - and thus like
a configuration problem.
I disagree, NAT already ignores untracked connections in most places,
just icmp_reply_translation is missing.
Vladimir, can you please test the attached patch?
diff --git a/net/ipv4/netfilter/ip_nat_core.c b/net/ipv4/netfilter/ip_nat_core.c
--- a/net/ipv4/netfilter/ip_nat_core.c
+++ b/net/ipv4/netfilter/ip_nat_core.c
@@ -430,6 +430,19 @@ int icmp_reply_translation(struct sk_buf
} *inside;
struct ip_conntrack_tuple inner, target;
int hdrlen = (*pskb)->nh.iph->ihl * 4;
+ unsigned long statusbit;
+
+ if (manip == IP_NAT_MANIP_SRC)
+ statusbit = IPS_SRC_NAT;
+ else
+ statusbit = IPS_DST_NAT;
+
+ /* Invert if this is reply dir. */
+ if (dir == IP_CT_DIR_REPLY)
+ statusbit ^= IPS_NAT_MASK;
+
+ if (!(ct->status & statusbit))
+ return 0;
if (!skb_make_writable(pskb, hdrlen + sizeof(*inside)))
return 0;
