Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

possible regression in ipf 5.1.1?

8 views
Skip to first unread message

Logan O'Sullivan Bruns

unread,
Mar 4, 2012, 2:24:17 PM3/4/12
to
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

unread,
Mar 5, 2012, 6:25:43 AM3/5/12
to
On 5/03/2012 6:24 AM, Logan O'Sullivan Bruns wrote:
> 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.

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

unread,
Mar 6, 2012, 10:25:00 AM3/6/12
to
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

unread,
Mar 6, 2012, 12:15:42 PM3/6/12
to
Yes, that fixes it. Thanks!

- logan
0 new messages