Hello all, We have a new Shorewall install (v3.0.4) running on Ubuntu 6.06 with the 2.6.15-26-server kernel. We''re having a strange problem where some of the machines on the local 192.168.x.x network can access a website fine, but other machines cannot. All of the machines can ping the site successfully, and all machines can get an initial connection to the website. However, for some, the connection never gets data back according to the Wireshark trace. The main site we are seeing this problem with is http://java.sun.com<https://webmailcluster.perfora.net/xml/webmail/mailContent;jsessionid=6C22B48DC6FD53E5FEA51FEB29A82FF7.TC134b#>( 72.5.124.55). All of the machines get their IP configuration from the same DHCP server, and I verified that the DNS and gateways are the same on all machines. The machines that can get out to the site are XP, but so are some of the ones that can''t connect to the site, as well as several flavors of Linux. But it is only certain sites where this problem is seen, almost all other sites load fine. As requested, I have attached the output of the shorewall dump command. A machine that couldn''t connect is 192.168.1.110, and one that could connect is 192.168.1.107. I did a search of the archives, but didn''t see anything similar to this issue. Any help is appreciated. If there is more info needed from me about the configuration, let me know. Thanks! Greg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> However, for some, the connection never gets data back > according to the Wireshark trace. The main site we are seeing this > problem with is http://java.sun.com > <https://webmailcluster.perfora.net/xml/webmail/mailContent;jsessionid=6C22B48DC6FD53E5FEA51FEB29A82FF7.TC134b#> > (72.5.124.55 <http://72.5.124.55>).Does the Wireshark trace indicate that the problem clients are using ECN? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
No, the clients that can''t connect do not have any mention of ECN (explicit congestion notification) in the Wireshark traces. On Aug 17, 2007, at 8:04 PM, Tom Eastep <teastep@shorewall.net> wrote:>> However, for some, the connection never gets data back >> according to the Wireshark trace. The main site we are seeing this >> problem with is http://java.sun.com >> <https://webmailcluster.perfora.net/xml/webmail/mailContent;jsessionid=6C22B48DC6FD53E5FEA51FEB29A82FF7.TC134b# >> > >> (72.5.124.55 <http://72.5.124.55>). > > Does the Wireshark trace indicate that the problem clients are using > ECN? > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, 2007-08-17 at 22:51 -0500, Greg Gowins wrote:> No, the clients that can''t connect do not have any mention of ECN > (explicit congestion notification) in the Wireshark traces.Why does eth1 have an MTU of 1492? Are all of the hosts connected to that interface configured with that same MTU? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 8/17/07, Greg Gowins <eric.t.cartman@gmail.com> wrote:> > No, the clients that can''t connect do not have any mention of ECN > (explicit congestion notification) in the Wireshark traces.Have you tried to give a problem machine the IP of a working machine? To narrow down whether it''s in the firewall or the workstation? bb ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sat, Aug 18, 2007 at 08:59:30AM -0700, Tom Eastep wrote:> On Fri, 2007-08-17 at 22:51 -0500, Greg Gowins wrote: > > No, the clients that can''t connect do not have any mention of ECN > > (explicit congestion notification) in the Wireshark traces. > > Why does eth1 have an MTU of 1492? Are all of the hosts connected to > that interface configured with that same MTU? >An MTU of 1492 is common when connecting to a DSL modem via Ethernet and using PPPoE. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sat, 2007-08-18 at 11:24 -0500, Brad Bendily wrote:> On 8/17/07, Greg Gowins <eric.t.cartman@gmail.com> wrote: > > > > No, the clients that can''t connect do not have any mention of ECN > > (explicit congestion notification) in the Wireshark traces. > > Have you tried to give a problem machine the IP of a working machine? > To narrow down whether it''s in the firewall or the workstation?I rather doubt that it is IP-address related. The firewall ruleset treats the working and non-working addresses identically. In my experience, problems that affect some web sites but not others are either ECN- or Path MTU- related. Since we''ve ruled out ECN, I think that the problem has to do with the ersatz MTU (1492) on eth1. I suspect that replacing CLAMPMSS=Yes with CLAMPMSS=1452 (or lower) in shorewall.conf would correct the problem (as would configuring eth1 and all of the hosts on that LAN with the same MTU). MTU-related problems occur because complete idiots sometime masquerade as network administrators. These fools somehow believe that all ICMP packets are evil and must be prevented at any cost from passing through the routers that they administer. In so doing, they break path MTU discovery and cause grief for the rest of us. The Netfilter TCPMSS target (which CLAMPMSS uses) is netfilter''s tool for working around the effects of these administrators'' stupidity. CLAMPMSS=Yes works well if the outgoing interface''s MTU is smaller than the local LAN''s. In this case, however, it is the local interface that has the smaller MTU so CLAMPMSS=<mss> is the proper solution. The value is calculated as the smallest MTU in the client<->server path minus 40; hence, I recommended CLAMPMSS=1452. A word of warning. Greg is running Shorewall 3.0.4. In that version (in fact, in all versions up to 4.0.2), Setting CLAMPMSS=<mss> could actually *increase* the MSS setting in a packet. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Thanks Tom! The MTU setting was indeed the culprit. It was set to 1492 by default on that NIC, and old 3Com 3C905 card. I added a ''mtu 1500'' to the /etc/network/interfaces file for eth1, and the problem went away. Nice catch. Thanks for your help on this! Greg On 8/18/07, Tom Eastep <teastep@shorewall.net> wrote:> > On Sat, 2007-08-18 at 11:24 -0500, Brad Bendily wrote: > > On 8/17/07, Greg Gowins <eric.t.cartman@gmail.com> wrote: > > > > > > No, the clients that can''t connect do not have any mention of ECN > > > (explicit congestion notification) in the Wireshark traces. > > > > Have you tried to give a problem machine the IP of a working machine? > > To narrow down whether it''s in the firewall or the workstation? > > I rather doubt that it is IP-address related. The firewall ruleset > treats the working and non-working addresses identically. > > In my experience, problems that affect some web sites but not others are > either ECN- or Path MTU- related. Since we''ve ruled out ECN, I think > that the problem has to do with the ersatz MTU (1492) on eth1. I suspect > that replacing CLAMPMSS=Yes with CLAMPMSS=1452 (or lower) in > shorewall.conf would correct the problem (as would configuring eth1 and > all of the hosts on that LAN with the same MTU). > > MTU-related problems occur because complete idiots sometime masquerade > as network administrators. These fools somehow believe that all ICMP > packets are evil and must be prevented at any cost from passing through > the routers that they administer. In so doing, they break path MTU > discovery and cause grief for the rest of us. The Netfilter TCPMSS > target (which CLAMPMSS uses) is netfilter''s tool for working around the > effects of these administrators'' stupidity. > > CLAMPMSS=Yes works well if the outgoing interface''s MTU is smaller than > the local LAN''s. In this case, however, it is the local interface that > has the smaller MTU so CLAMPMSS=<mss> is the proper solution. The value > is calculated as the smallest MTU in the client<->server path minus 40; > hence, I recommended CLAMPMSS=1452. > > A word of warning. Greg is running Shorewall 3.0.4. In that version (in > fact, in all versions up to 4.0.2), Setting CLAMPMSS=<mss> could > actually *increase* the MSS setting in a packet. > > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/