A bit of background: on one of my firewall machines, there are 7 different interfaces - 2 outward-facing, connected to the outside world (eth0 and tun0) and 5 inward-facing interfaces, connected to various internal networks (eth1-4). I also have a local zone on lo, which is also managed by shorewall, with various rules in existence. It is worth mentioning that I also have strict control of all related connections, with the appropriate logging set on all zones/interfaces. Now, when say, eth3 and eth4 have established connections to various IP addresses to the outside world via eth0 (with the appropriate masquerading set) and the link on eth0 drops, I get a flurry of about 30-40 entries in my logs consisting of icmp type 3, code 1 messages with source address set as the eth0 IP address and destination address set as the originating IP address, belonging to subnets of which my eth3 and eth4 interfaces are part of. So far so good and is more or less what I expect to see in such instances. What is rather bizarre and a complete mystery to me, however, is that all of this goes through lo! Yes, that''s right - I am seeing these logs appear on my +fw2local zone, which is responsible for packets from/to the local zone, consisting of a single interface - the loopback, not the zones which are responsible for handling packets from/to eth3 or eth4. In other words, I expected to see these packets appear in one of +fw2eth3, +fw2eth4, +eth02eth3 or +eth02eth4 zones, not on my +fw2local zone. The actual logs confirm that the out interface is indeed the loopback (lo), even though none of the addresses involved (source/destination IP addresses of either related or the actual connection) are on the loopback interface. Just to make sure, I checked my OUTPUT chain and there is indeed a rule in it, which directs all packets going out of lo to my fw2local zone and all RELATED connections then go to +fw2local. None of these packets reach their destination, which is hardly surprising since the out interface is the loopback. So, the big question is - have I done something wrong, is this a shorewall bug or is there something fundamentally wrong with the netfilter setup? ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
On 10/29/2013 4:15 PM, Dash Four wrote:> A bit of background: on one of my firewall machines, there are 7 > different interfaces - 2 outward-facing, connected to the outside world > (eth0 and tun0) and 5 inward-facing interfaces, connected to various > internal networks (eth1-4). I also have a local zone on lo, which is > also managed by shorewall, with various rules in existence. It is worth > mentioning that I also have strict control of all related connections, > with the appropriate logging set on all zones/interfaces. > > Now, when say, eth3 and eth4 have established connections to various IP > addresses to the outside world via eth0 (with the appropriate > masquerading set) and the link on eth0 drops, I get a flurry of about > 30-40 entries in my logs consisting of icmp type 3, code 1 messages with > source address set as the eth0 IP address and destination address set as > the originating IP address, belonging to subnets of which my eth3 and > eth4 interfaces are part of. So far so good and is more or less what I > expect to see in such instances. > > What is rather bizarre and a complete mystery to me, however, is that > all of this goes through lo! Yes, that''s right - I am seeing these logs > appear on my +fw2local zone, which is responsible for packets from/to > the local zone, consisting of a single interface - the loopback, not the > zones which are responsible for handling packets from/to eth3 or eth4. > > In other words, I expected to see these packets appear in one of > +fw2eth3, +fw2eth4, +eth02eth3 or +eth02eth4 zones, not on my +fw2local > zone. The actual logs confirm that the out interface is indeed the > loopback (lo), even though none of the addresses involved > (source/destination IP addresses of either related or the actual > connection) are on the loopback interface. Just to make sure, I checked > my OUTPUT chain and there is indeed a rule in it, which directs all > packets going out of lo to my fw2local zone and all RELATED connections > then go to +fw2local. > > None of these packets reach their destination, which is hardly > surprising since the out interface is the loopback. So, the big question > is - have I done something wrong, is this a shorewall bug or is there > something fundamentally wrong with the netfilter setup?The OUT interface is determined when the packet is routed. Is there a rogue route in the ''local'' table or route cache when you see this problem? ip route ls table local ip route ls cache -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 \________________________________________________ ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
Tom Eastep wrote:> The OUT interface is determined when the packet is routed. Is there a > rogue route in the ''local'' table or route cache when you see this problem? >Define "rogue". I can''t see anything out of the ordinary (see below).> ip route ls table local >Executing this gives me what I expect to see - a group of 3 routes per interface. For example, if we assume eth0 to have 10.1.0.1/24, then I have something like: broadcast 10.1.0.0 dev eth0 proto kernel scope link src 10.1.0.1 local 10.1.0.1 dev eth0 proto kernel scope host src 10.1.0.1 broadcast 10.1.0.255 dev eth0 proto kernel scope link src 10.1.0.1 The above repeats for each interface on that machine. The only exception to this is lo, where I have: broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 Again, nothing out of the ordinary.> ip route ls cache >That returns nothing. Baffling, isn''t it? The logs I''ve got are produced by my own version of ulogd2, where I extended the functionality and hardened its security (I have about 14 patches applied). This version gives me, among other things, full details of the "inner" header of icmp-related messages (that is the secondary header which is made available in the icmpv4 and icpmv6 message), so I get to see the details of the original connection. In addition to that, I have the iptables'' own counters, which confirm that these packets tried to traverse through the loopback (lo), so there can''t be a question of ulogd2 messing things up and reporting the wrong interface somehow. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
On 10/30/2013 4:36 PM, Dash Four wrote:> > > Tom Eastep wrote: >> The OUT interface is determined when the packet is routed. Is there a >> rogue route in the ''local'' table or route cache when you see this problem? >> > Define "rogue". I can''t see anything out of the ordinary (see below). > >> ip route ls table local >> > Executing this gives me what I expect to see - a group of 3 routes per > interface. For example, if we assume eth0 to have 10.1.0.1/24, then I > have something like: > > broadcast 10.1.0.0 dev eth0 proto kernel scope link src 10.1.0.1 > local 10.1.0.1 dev eth0 proto kernel scope host src 10.1.0.1 > broadcast 10.1.0.255 dev eth0 proto kernel scope link src 10.1.0.1 > > The above repeats for each interface on that machine. The only exception > to this is lo, where I have: > > broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 > local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 > local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 > broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 > > Again, nothing out of the ordinary. > > >> ip route ls cache >> > That returns nothing. > > Baffling, isn''t it? The logs I''ve got are produced by my own version of > ulogd2, where I extended the functionality and hardened its security (I > have about 14 patches applied). This version gives me, among other > things, full details of the "inner" header of icmp-related messages > (that is the secondary header which is made available in the icmpv4 and > icpmv6 message), so I get to see the details of the original connection. > > In addition to that, I have the iptables'' own counters, which confirm > that these packets tried to traverse through the loopback (lo), so there > can''t be a question of ulogd2 messing things up and reporting the wrong > interface somehow.Okay -- I''m seeing some similar bizarreness on my own firewall; 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 OUTMAC=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. Also hard to see why this was classified as RELATED, given that my firewall drops external connection requests on port 8080. I''m leaving town shorty and will be gone for several days, but I can look at this more closely when I return. -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 \________________________________________________ ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
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. 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.> 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 leaving town shorty and will be gone for several days, but I can > look at this more closely when I return. >No problem Tom. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
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 \________________________________________________ ------------------------------------------------------------------------------ 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
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
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 \________________________________________________ ------------------------------------------------------------------------------ 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
Tom Eastep wrote:> Not true! The loopback interface is used for ANY packet sent from the > host to itself.That''s a fair comment. However, in my case one address is "local", the other one is remove - that will never reach its destination and should have never been routed through the loopback, or am I missing something? Here is one example of what I get (all "o.*" properties are for the original connection for which the icmp message was issued; "<eth0>" is my external-facing IP on eth0, "<remote_IP_eth1_subnet>" is remote internal IP which has the same subnet as eth1, "<external_IP>" is a remote host): timestamp=2013/10/09-00:04:57,raw.pktlen=576,raw.pktcount=1,oob.prefix=Shorewall:fw2local:DROP:,oob.time.sec=1381273497,oob.time.usec=72127,oob.mark=0,oob.ifindex_out=1,oob.hook=3,oob.family=2,oob.protocol=0,raw.label=0,ip.saddr=<eth0>,ip.daddr=<remote_IP_eth1_subnet>,ip.protocol=1,ip.tos=192,ip.ttl=64,ip.totlen=576,ip.ihl=5,ip.csum=31876,ip.id=53893,ip.fragoff=0,icmp.type=3,icmp.code=1,icmp.csum=30221,oob.protocol=0,o.ip.saddr=<remote_IP_eth1_subnet>,o.ip.daddr=<external_IP>,o.ip.protocol=6,o.ip.tos=0,o.ip.ttl=63,o.ip.totlen=638,o.ip.ihl=5,o.ip.csum=15844,o.ip.id=42550,o.ip.fragoff=16384,o.tcp.sport=38327,o.tcp.dport=443,o.tcp.seq=3400886979,o.tcp.ackseq=4068520201,o.tcp.window=166,o.tcp.offset=0,o.tcp.reserved=0,o.tcp.urg=0,o.tcp.ack=1,o.tcp.psh=1,o.tcp.rst=0,o.tcp.syn=0,o.tcp.fin=0,o.tc p.res1=0,o.tcp.res2=0,o.tcp.csum=26701,oob.in=,oob.out=lo,ip.saddr.str=<eth0>,ip.daddr.str=<remote_IP_eth1_subnet>,oob.protocol=0 You will notice that the output interface is the loopback and the zone is fw2local, even though the destination address has nothing whatsoever to do with the "local" zone or 127.0.0.0/8. ------------------------------------------------------------------------------ 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
Dash Four wrote:> > Tom Eastep wrote: >> Not true! The loopback interface is used for ANY packet sent from the >> host to itself. > That''s a fair comment. However, in my case one address is "local", the > other one is remove - that will never reach its destination and should > have never been routed through the loopback, or am I missing something? > > Here is one example of what I get (all "o.*" properties are for the > original connection for which the icmp message was issued; "<eth0>" is > my external-facing IP on eth0, "<remote_IP_eth1_subnet>" is remote > internal IP which has the same subnet as eth1, "<external_IP>" is a > remote host): > > timestamp=2013/10/09-00:04:57,raw.pktlen=576,raw.pktcount=1,oob.prefix=Shorewall:fw2local:DROP:,oob.time.sec=1381273497,oob.time.usec=72127,oob.mark=0,oob.ifindex_out=1,oob.hook=3,oob.family=2,oob.protocol=0,raw.label=0,ip.saddr=<eth0>,ip.daddr=<remote_IP_eth1_subnet>,ip.protocol=1,ip.tos=192,ip.ttl=64,ip.totlen=576,ip.ihl=5,ip.csum=31876,ip.id=53893,ip.fragoff=0,icmp.type=3,icmp.code=1,icmp.csum=30221,oob.protocol=0,o.ip.saddr=<remote_IP_eth1_subnet>,o.ip.daddr=<external_IP>,o.ip.protocol=6,o.ip.tos=0,o.ip.ttl=63,o.ip.totlen=638,o.ip.ihl=5,o.ip.csum=15844,o.ip.id=42550,o.ip.fragoff=16384,o.tcp.sport=38327,o.tcp.dport=443,o.tcp.seq=3400886979,o.tcp.ackseq=4068520201,o.tcp.window=166,o.tcp.offset=0,o.tcp.reserved=0,o.tcp.urg=0,o.tcp.ack=1,o.tcp.psh=1,o.tcp.rst=0,o.tcp.syn=0,o.tcp.fin=0,o.tcp.res1=0,o.tcp.res2=0,o.tcp.csum=26701,oob.in=,oob.out=lo,ip.saddr.str=<eth0>,ip.daddr.str=<remote_IP_eth1_subnet>,oob.protocol=0> > > You will notice that the output interface is the loopback and the zone > is fw2local, even though the destination address has nothing > whatsoever to do with the "local" zone or 127.0.0.0/8.Any thoughts on this? Provided the above should not happen and is a bug, I am assuming it is netfilter-related, is that correct? ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
On 11/13/2013 6:12 AM, Dash Four wrote:> Dash Four wrote: >> >> Tom Eastep wrote: >>> Not true! The loopback interface is used for ANY packet sent from the >>> host to itself. >> That''s a fair comment. However, in my case one address is "local", the >> other one is remove - that will never reach its destination and should >> have never been routed through the loopback, or am I missing something? >> >> Here is one example of what I get (all "o.*" properties are for the >> original connection for which the icmp message was issued; "<eth0>" is >> my external-facing IP on eth0, "<remote_IP_eth1_subnet>" is remote >> internal IP which has the same subnet as eth1, "<external_IP>" is a >> remote host): >> >> timestamp=2013/10/09-00:04:57,raw.pktlen=576,raw.pktcount=1,oob.prefix=Shorewall:fw2local:DROP:,oob.time.sec=1381273497,oob.time.usec=72127,oob.mark=0,oob.ifindex_out=1,oob.hook=3,oob.family=2,oob.protocol=0,raw.label=0,ip.saddr=<eth0>,ip.daddr=<remote_IP_eth1_subnet>,ip.protocol=1,ip.tos=192,ip.ttl=64,ip.totlen=576,ip.ihl=5,ip.csum=31876,ip.id=53893,ip.fragoff=0,icmp.type=3,icmp.code=1,icmp.csum=30221,oob.protocol=0,o.ip.saddr=<remote_IP_eth1_subnet>,o.ip.daddr=<external_IP>,o.ip.protocol=6,o.ip.tos=0,o.ip.ttl=63,o.ip.totlen=638,o.ip.ihl=5,o.ip.csum=15844,o.ip.id=42550,o.ip.fragoff=16384,o.tcp.sport=38327,o.tcp.dport=443,o.tcp.seq=3400886979,o.tcp.ackseq=4068520201,o.tcp.window=166,o.tcp.offset=0,o.tcp.reserved=0,o.tcp.urg=0,o.tcp.ack=1,o.tcp.psh=1,o.tcp.rst=0,o.tcp.syn=0,o.tcp.fin=0,o.tcp.res1=0,o.tcp.res2=0,o.tcp.csum=26701,oob.in=,oob.out=lo,ip.saddr.str=<eth0>,ip.daddr.str=<remote_IP_eth1_subnet>,oob.protocol=0 >> >> >> You will notice that the output interface is the loopback and the zone >> is fw2local, even though the destination address has nothing >> whatsoever to do with the "local" zone or 127.0.0.0/8. > Any thoughts on this? Provided the above should not happen and is a bug, > I am assuming it is netfilter-related, is that correct?That would be my guess. Either that, or ''that is just the way it works''. -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 \________________________________________________ ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk