possible regression in ipf 5.1.1?

[Logan O'Sullivan Bruns]

Hi Darren,

I'm using ipfilter 5.1.1 on OpenIndiana. I basically copied over a
rule set from a 4.1.35 installation on Solaris 10 over to a new OI
box. For the most part it is working as expected however in some cases
for outgoing tcp keep state connections the other server's response is
being rejected with entries list this:

04/03/2012 00:19:34.258038 bnx1 @0:2 b 76.164.171.232,80 -> 10.0.1.180,35862 PR tcp len 20 60 -AS IN NAT

In all these cases when I look at the packets coming back from the
server they have a window scale set. For example, courtesy of snoop:

TCP: Options: (20 bytes)
TCP: - Maximum segment size = 1460 bytes
TCP: - SACK permitted option
TCP: - TS Val = 3973139865, TS Echo = 507047078
TCP: - No operation
TCP: - Window scale = 7

The ones without a window scale pass through the firewall and set up
correctly. Perhaps it is unrelated and not helpful but I vaguely
remember such an issue in the 4.1.X branch.

Please let me know if there is more information that might useful? I
also have some questions about some of the changes to the SIOCADNAT
and SIOCGENITER ioctl calls from 4.1.X to 5.1.1 but that's less
important. (I'm trying to update my miniupnpd use too.)

Thanks as always for such a great tool.

- logan

[Darren Reed]

Post by Logan O'Sullivan Bruns
Hi Darren,
I'm using ipfilter 5.1.1 on OpenIndiana. I basically copied over a
rule set from a 4.1.35 installation on Solaris 10 over to a new OI
box. For the most part it is working as expected however in some cases
for outgoing tcp keep state connections the other server's response is
In all these cases when I look at the packets coming back from the
TCP: Options: (20 bytes)
TCP: - Maximum segment size = 1460 bytes
TCP: - SACK permitted option
TCP: - TS Val = 3973139865, TS Echo = 507047078
TCP: - No operation
TCP: - Window scale = 7
The ones without a window scale pass through the firewall and set up
correctly. Perhaps it is unrelated and not helpful but I vaguely
remember such an issue in the 4.1.X branch.

Using dtrace, try this out:

# dtrace -n 'sdt:ipf::{}'

.. and see which dtrace probes get hit.

In addition, can you use:
# snoop -o window.cap -d bnx1
and capture the SYN and its SYN-ACK that gets blocked and email
me the window.cap file please?

Thanks,
Darren

[Darren Reed]

With the IP addresses you were communicating with, it hits a
bug with how multicast packets are detected.

Please try this patch out.

Darren

--- fil.c.orig Tue Mar 6 00:35:51 2012
+++ fil.c Tue Mar 6 00:33:40 2012
@@ -1705,7 +1705,7 @@
fin->fin_crc += fi->fi_saddr;
fi->fi_daddr = ip->ip_dst.s_addr;
fin->fin_crc += fi->fi_daddr;
- if (IN_CLASSD(fi->fi_daddr))
+ if (IN_CLASSD(ntohl(fi->fi_daddr)))
fin->fin_flx |= FI_MULTICAST|FI_MBCAST;

/*

[Logan O'Sullivan Bruns]

Yes, that fixes it. Thanks!

- logan

Post by Darren Reed
With the IP addresses you were communicating with, it hits a
bug with how multicast packets are detected.
Please try this patch out.
Darren
--- fil.c.orig Tue Mar 6 00:35:51 2012
+++ fil.c Tue Mar 6 00:33:40 2012
@@ -1705,7 +1705,7 @@
fin->fin_crc += fi->fi_saddr;
fi->fi_daddr = ip->ip_dst.s_addr;
fin->fin_crc += fi->fi_daddr;
- if (IN_CLASSD(fi->fi_daddr))
+ if (IN_CLASSD(ntohl(fi->fi_daddr)))
fin->fin_flx |= FI_MULTICAST|FI_MBCAST;
/*