Tom Eastep wrote: >> 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? > No - I just pull the plug so that I get "ethX: link down" message to appear in my logs.
>> 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 am on 3.11. Maybe this is a new "feature" which was introduced recently. The configuration on that machine has changed very little over the years and the situation I described in the initial post must've occurred quite often and I don't remember seeing such messages before. > 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 > Well, exactly. Why is this packet rooted through the loopback? It should have been passed through the same zone/interface on which the OUT interface/IP address is (eth1 in your case above - 2nd packet carrying the icmp message). > 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 am doing a similar thing here, except I am inducing icmp messages by pulling the plug while a connection is active. > 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. > The loopback zone cannot route packets other than 127.0.0.0/8! It is why the whole thing fails. It is wrong! The related packets should be passed via the interface on which the OUT IP address is (eth1 in your example above). Why is the loopback used in the first place - it has no place there whatsoever? What prompts such bizarre behaviour? ------------------------------------------------------------------------------ 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
