Tom (and all), I can’t believe the answer was staring me right in the face this whole time.
After you had pointed out the conntrack issue, I thought about it more and decided to poke around /var/log/messages and see if conntrack is being loaded. One curious entry I saw was: Nov 27 09:35:51 belle kernel: [ 5.251644] Disabling conntracks and NAT for ve0 That got me thinking about what OpenVZ might’ve done to the system (as my other working server isn’t running OpenVZ, but KVM). So I looked at /etc/modprobe.d/ and noticed a openvz.conf with the following line in it: options nf_conntrack ip_conntrack_disable_ve0=1 >From what I understand about OpenVZ, ve0 (or CT0) is the host node itself. So >that line is basically disabling NAT and conntrack for the host node. I’m not >sure what the logic is behind that, but after commenting out that line and >rebooting the system, conntrack works again and Shorewall acts normally again. Hope this helps anyone else who might run into this issue in future. Thanks, Jeff > On Nov 29, 2015, at 9:40 AM, Jeff Sim <[email protected]> wrote: > > Hi Tom, thanks for responding and looking into this. It’s much appreciated. > > That’s the odd thing about I noticed too, that the conntrack isn’t happening > … despite the conntrack modules being present, and the conntrack utils being > installed. That might be why the firewall doesn’t realize that the net->fw > traffic is really a response to my fw->net traffic, so it gets dropped? > > The other odd thing is that the firewall logs don’t show the connection being > dropped at all. > > In this updated dump, I did the following: > > 1. shorewall clear > 2. curl -Lv http://yahoo.com > 3. shorewall dump > /tmp/shorewall.txt > > As you’ll see in the “Active connections” table, there is a connection made > out: > tcp 0 1 148.163.113.130:60810 98.138.253.109:80 > SYN_SENT 3745/curl > > But the ACK never gets allowed back in, and eventually the connection times > out. > > I had installed the conntrack utility like you suggested: > [root@belle ~]# rpm -qa | grep conntrack > conntrack-tools-0.9.13-3.el6.x86_64 > libnetfilter_conntrack-0.0.100-2.el6.x86_64 > > But the result is the same. I did a conntrack -L and nothing comes up either: > [root@belle ~]# conntrack -L > conntrack v0.9.13 (conntrack-tools): 0 flow entries have been shown. > > Pretty weird huh… > > <shorewall.txt.bz2> > >> On Nov 29, 2015, at 7:50 AM, Tom Eastep <[email protected]> wrote: >> >> On 11/28/2015 12:45 PM, Jeff Sim wrote: >>> Sadly, just tried that and it didn’t work either. >>> >>> Here’s the updated dump with the change you suggested. >>> >> >> Jeff, >> >> It doesn't look as though you tried to establish any fw->net connection >> between the time that you restarted Shorewall and when you initiated the >> dump. >> >> One thing that is very strange in the dump is that the conntrack table >> appears empty, even though there is obviously an active connection >> between the firewall and the 'loc' zone. If haven't already, please >> install the 'conntrack' utility. >> >> Thanks, >> -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 \________________________________________________ >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Shorewall-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Shorewall-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
