Hi Tom, Thank you. It turns out to be centos 5.8 build that causes the segment to be out of order. I switched to centos 6.2 and the problem is gone.
One question about /etc/shorewall/providers: If I want to design in a way that: a. THE DEFAULT traffic will go out using provider1 (no rule need to be applied to tcrule or rtrule b. Use provider2 ONLY when i define rules in tcrule c. I want to direct the traffic in (b) based on outgoing ports d. Using the minimal amount of rules :) Is there a way i can achieve that? I can only find such note in the doc: "... If you are using /etc/shorewall/providers because you have multiple Internet connections, we recommend that you specify balance even if you don't need it. You can still use entries in /etc/shorewall/tcrules and /etc/shorewall/rtrules to force all traffic to one provider or another... " Without specifying specific rule, the default behavior is load balance hence 100:50 proportion for both providers. I guess I can make the proportion to be 100:1, but it still bleeds 1% of the traffic to the other provider. Many thanks. --- On Tue, 1/5/12, Tom Eastep <[email protected]> wrote: > From: Tom Eastep <[email protected]> > Subject: Re: [Shorewall-users] packet fragmentation between LAN and DMZ for > multi ISP firewall > To: [email protected] > Received: Tuesday, 1 May, 2012, 2:45 PM > On 04/30/2012 09:58 PM, Lito Kusnadi > wrote: > > I managed to get multi ISPs firewall running with 4 > zones: - net > > (internet) - loc - dmz - road (openvpn rwarrior) > > > > Browsing from loc to internet, vpn to dmz, vpn to loc > are working > > fine with reasonable response. However, loc to dmz > traffic is having > > issue. > > > > I found when browsing from a workstation in the LAN > (loc) zone to a > > web server hosted in DMZ zone takes a very long time. > > > > I did packet analyzer using wireshark. I found that the > data traffic > > from the web server is being fragmented and eventually > experience > > out-of-order fragmented packets. This results in slow > speed and the > > data from the web server eventually not delivered > completely to the > > browser (e.g. only partial data). > > > > wireshark reports "TCP segment of a reassembled PDU" > for many times > > until the "out-of-order segment" trace. > > > > Google around about fragmentation, the first thing to > look at is MTU. > > However, when I move a LAN workstation to dmz zone, by > just changing > > the IP address to suit the dmz subnet (not playing with > the MTU > > setup), I have no problem browsing the web server. So > that eliminates > > MTU as the cause. > > Well, there is certainly nothing in a Shorewall > configuration that can > *cause* fragmentation. > > What are the MTU settings on the web server and on the LAN > workstation? > If either is > 1500, you can set CLAMPMSS=Yes in > shorewall.conf and see > if that helps. > > -Tom > -- > Tom Eastep \ When I die, I want > to go like my Grandfather who > Shoreline, \ died > peacefully in his sleep. Not screaming like > Washington, USA \ all of the > passengers in his car > http://shorewall.net > \________________________________________________ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's > security and > threat landscape has changed and how IT managers can > respond. Discussions > will include endpoint security, mobile security and the > latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
