On 10/31/2013 3:22 PM, Dash Four wrote: > Tom Eastep wrote: >> Okay -- I'm seeing some similar bizarreness on my own firewall; > I'm relieved it isn't just me! > >> last episode was on 10/24 where I see a number of these from ulogd: >> >> Oct 24 09:15:54 gateway : +loop-fw REJECT IN=lo OUT= >> MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=54.236.187.178 >> DST=10.0.0.4 LEN=40 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=8080 >> DPT=41763 SEQ=0 ACK=2096124008 WINDOW=0 ACK RST URGP=0 >> >> In this case, 54.236.187.178 is an external host and 10.0.0.4 is the >> IPv4 address of eth0. eth0 is a provider interface sitting behind a NAT >> router. So clearly, the original input interface should have been eth0, >> not lo. > Precisely. Very similar scenario here. The difference in my case is that > the connection has already been established, but all else matches what > you've described above. One other difference is that "lo" is the out > interface in my case. >
I only define loop->$FW rules so the bizarreness only occurs with IN=lo. > What I've done today is I replaced the main INPUT/OUTPUT rules governing > the loopback and introduced a restriction on the fw2local and local2fw > iptables rules so that the source/destination is matched to be 127.0.0.1 > and not "all" (0.0.0.0) as was the case before. > > After doing that, I established a connection from one of the machines on > my "eth1" subnet and when that connection was established (internal > machine -> eth1 (fw) -> eth0 (fw) -> NAT -> external IP address) I > pulled the plug on eth0. Surprise, surprise, I saw about 20 packets > DROPped in my Shorewall:OUTPUT:DROP chain via ulogd2 and all had "lo" as > the outgoing interface. Are you using a link status monitor that is disabling eth0 when you pull the plug? > >> Also hard to see why this was classified as RELATED, given that >> my firewall drops external connection requests on port 8080. >> > What kernel are you using? I am on 3.11 and don't remember seeing this > with previous kernel versions? I'm running the Debian 3.2 kernel. > >> I'm leaving town shorty and will be gone for several days, but I can >> look at this more closely when I return. >> > No problem Tom. I've done some additional looking and find that I cannot correlate the bizarreness with link-down situations. My cases seem to all look like this: /var/log/ulog/syslogemu.log.3:Oct 18 07:09:53 gateway : fw-net REJECT IN= OUT=eth1 MAC= SRC=70.90.191.121 DST=54.236.176.137 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=3829 DF PROTO=TCP SPT=32791 DPT=8080 SEQ=890725573 ACK=0 WINDOW=14600 SYN URGP=0 /var/log/ulog/syslogemu.log.3:Oct 18 07:09:53 gateway : +loop-fw REJECT IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=54.236.176.137 DST=70.90.191.121 LEN=40 TOS=00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=8080 DPT=32791 SEQ=0 ACK=890725574 WINDOW=0 ACK RST URGP=0 I don't have a rule allowing tcp port 8080 from fw->net and am rejecting the connection request (first message). The REJECT target is synthesizing an RST response which is sent over the loopback interface. Note that in my case, the SOURCE address in the connection request (70.90.191.121) is an address on eth1. I suspect that ICMP 3/1 packets are being handled similarly by the IP stack. So it seems like we should be allowing related RSTs and ICMPs through the loopback zone. -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
