On Fri, 31 Aug 2001, Jozsef Kadlecsik wrote:
> After upgrading a firewall which is configured with connection tracking
> from 2.4.2 to 2.4.5, the following strange thing happens on it:
>
> traceroute targeted to the firewall completes successfully:
> icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0) in
> udp.c generates proper (large enough) response packets, which
> then can be handled by the connection tracking code.
>
> traceroute going through the firewall doesn't generate "proper"
> ICMP packets from the firewall:
> icmp_send(skb, ICMP_TIME_EXCEEDED, ICMP_EXC_TTL, 0) in
> ip_forward.c seems to generate too short packets, which cannot
> therefore be tracked:
>
> Aug 31 12:16:12 zzz kernel: denied: IN= OUT=eth1 SRC=zzz.zzz.zzz.zzz
> DST=a.b.c.d LEN=66 TOS=0x00 PREC=0xC0 TTL=255 ID=10383 PROTO=ICMP
> TYPE=11 CODE=0 [SRC=a.b.c.d DST=x.y.z.w LEN=38 TOS=0x00
> PREC=0x00 TTL=1 ID=42915 PROTO=UDP INCOMPLETE [6 bytes] ]
>
> Nothing else's changed, only an upgrade happened.
>
> Is it a known bug? If yes, is it fixed in later releases?
Sorry, the quick (rush) explanation above is completely wrong.
Still, the problem stands, so a better analysys follows: in ip_forward.c
all error trackings (too many hops, strict route failed, fragmentation
needed) simply jump over calling the netfilter hooks for the original
packet. Thus if a *connection-initiating* packet would generate an ICMP
error message, the conntrack entry won't be created. In consequence the
generated reply packet will not be detected by the connection tracking as
RELATED, as it should be and as it is expected.
[As far as I see, the function ip_forward hasn't changed at least
from 2.4.0, up to 2.4.9. So I dunno how we didn't notice the problem
at running 2.4.2.]
Regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxx
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
|