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 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. 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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
