On 11/9/2013 5:42 AM, Dash Four wrote: > > > 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.
Can't say -- I've only been filtering traffic on 'lo' since I implemented 'loopback' zones. > >> 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). See below. > >> 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! Not true! The loopback interface is used for ANY packet sent from the host to itself. Run tcpdump on 'lo' and ping any local address; you will see the traffic in both direction. In the output below, 70.90.191.121 is the IP address of eth1: root@gateway:~# tcpdump -ni lo tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes 07:34:29.439866 IP 70.90.191.121 > 70.90.191.121: ICMP echo request, id 17541, seq 1, length 64 07:34:29.439926 IP 70.90.191.121 > 70.90.191.121: ICMP echo reply, id 17541, seq 1, length 64 07:34:30.441132 IP 70.90.191.121 > 70.90.191.121: ICMP echo request, id 17541, seq 2, length 64 07:34:30.441184 IP 70.90.191.121 > 70.90.191.121: ICMP echo reply, id 17541, seq 2, length 64 ... -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
