>Number:         26626
>Category:       kern
>Synopsis:       ipfilter does not allow some TCP/UDP connection related ICMP packets through
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 12 18:31:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Arto Selonen
>Release:        NetBSD-current ~20040809
>Organization:
>Environment:
NetBSD blah 2.0G NetBSD 2.0G (BLAH) #64: Tue Aug 10 20:16:06 EEST 2004  blah@blah:/obj/sys/arch/i386/compile/BLAH i386

>Description:
According to http://www.phildev.net/ipf/IPFques.html#1 ipfilter 3.4 series would allow ICMP packets through, if they were related to an established TCP or UDP connection that was created with "keep state" rule (assuming that the state entry has not timed out, etc). I may well have missed the documentation regarding ipfilter 4.1, so my expectation is that this should still be the case. However, it seems that at least some TCP/UDP related ICMP packets are being blocked instead of getting through.

The following trace of rules is travelled in ipf.conf, when an internal
UDP-based DNS query is sent to Internet (NOT ALL RULES SHOWN):

block in log quick on fxp1 all head 11001
block in log quick from <internal-net> to any head 11011 group 11001
block in log quick proto udp all head 11061 group 11011
pass  in     quick proto udp all keep state group 11061

I have several ipmon log entries showing that a new state had been created for the query connection, and then the next thing logged
is the blocked ICMP error message from the server, some seconds after the state was created (see below).

I tried repeating this manually, but I only got this:

Client behind fxp1, sending query to non-controlled server behind fxp0:
11/08/2004 13:57:43.057025 STATE:NEW client,4335 -> server,53 PR udp
13:57:43.057037 client.4335 > server: [udp sum ok]  4+ NS? example.com. (33) (ttl 29, id 46562, len 61)

Destination host replies with an ICMP message:
13:57:43.064724 server > client: icmp: server udp port 53 unreachable for client.4335 > server.53: [|domain] (ttl 18, id 58037, len 61, bad cksum 4c5b (->1f88)!) (ttl 245, id 56326, len 56)

Nothing shows up in ipmon logs, and the ICMP packet does get back to the client.

Here is one set of log entries that originally caused me to look into this. Both client and server are the same as above:

11/08/2004 07:42:26.115308 STATE:NEW client,53 -> server,53 PR udp
11/08/2004 07:42:28.122775 fxp0 @10091:4 b server -> client PR icmp len 20 56 icmp unreach/port for client,53 - server,53 PR udp len 20 79 IN
11/08/2004 07:42:40.138144 2x fxp0 @10091:4 b server -> client PR icmp len 20 56 icmp unreach/port for client,53 - server,53 PR udp len 20 68 IN
11/08/2004 07:42:48.010453 2x fxp0 @10091:4 b server -> client PR icmp len 20 56 icmp unreach/port for client,53 - server,53 PR udp len 20 68 IN
11/08/2004 07:44:48.433438 STATE:EXPIRE client,53 -> server,53 PR udp Forward: Pkts in 7 Bytes in 486 Pkts out 7 Bytes out 486 Backward: Pkts in 1 Bytes in 56 Pkts out 1 Bytes out 56

What could be causing this? I've seen an increase in blocked ICMP packets, but so far I've considered them to be spoofed ones. With the state transitions logged by ipmon ('ipmon -a') I can see that many of them are in fact replies to traffic originating from us (and as such they should get through, no?).

One thing that may or may not be related: in the cases I've looked at so far, there are also rules to allow similar traffic in, ie. "there exists a keep state rule that allows external traffic in to SERVER/PORT; when SERVER initiates a connection to some external host/PORT, related ICMP traffic may get blocked". I've seen this with at least DNS servers and one SMTP server (so, according to logs, this happens with both TCP and UDP).

Final note: if tcpdump shows checksum errors for the incoming packets, then how come they still get through to the client?
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: