I'm perhaps a bit hazy on my RFC1918 rules, but the Shorewall list I see Matt reporting includes a lot of Class A blocks that I did not know were part of the RFC1918 exclusions. One of them is what is catching the example packet Matt posts.
The example packet is:
Sep 16 09:12:31 hub kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT=eth1 SRC=82.82.76.144 DST=10.2.3.4 LEN=48 TOS=0x00 PREC=0x00 TTL=109 ID=29083 DF PROTO=TCP SPT=4535 DPT=6885 WINDOW=30370 RES=0x00 SYN URGP=0
The rule that catches it is this one, which matches the *source* address:
209 11072 logdrop ah -- * * 82.0.0.0/7 0.0.0.0/0
The destination address -- which, as I indicated in my prior response, has 10.2.3.4 in it because that's how the prerouting (or it is PREROUTING?) table does port forwarding -- has nothing to do with the DROP.
So ... why *is* 82.0.0.0/7 blocked by an RFC1918 rule? What am I forgetting?
At 05:00 PM 9/16/2003 -0700, Matt Schalit wrote:
Tom Eastep wrote:On Tue, 2003-09-16 at 09:36, Matt Schalit wrote:
I had to subscribe to leaf-user for this one, which maybe I don't understand because shorewall doesn't log every piece of information? I don't know, but here's the log entry and the details:
Sep 16 09:12:31 hub kernel: Shorewall:rfc1918:DROP:IN=eth0 OUT=eth1 SRC=82.82.76.144 DST=10.2.3.4 LEN=48 TOS=0x00 PREC=0x00 TTL=109 ID=29083 DF PROTO=TCP SPT=4535 DPT=6885 WINDOW=30370 RES=0x00 SYN URGP=0
Please forward the output from "shorewall show rfc1918".
Thanks for the reply, Tom. I probably shouldn't have called this Bizzare Shorewall Drops, because I don't think Shorewall is acting odd. It's more like I don't understand how I was getting DST=10.2.3.4, which violates my intuition on routing.
# shorewall show rfc1918 Shorewall-1.3.11a Chain rfc1918 at hub - Tue Sep 16 16:33:49 PDT 2003
Counters reset Fri Sep 5 18:29:15 PDT 2003
Chain rfc1918 (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN ah -- * * 255.255.255.255 0.0.0.0/0
0 0 DROP ah -- * * 169.254.0.0/16 0.0.0.0/0
5 446 logdrop ah -- * * 172.16.0.0/12 0.0.0.0/0
0 0 logdrop ah -- * * 192.0.2.0/24 0.0.0.0/0
17 4852 logdrop ah -- * * 192.168.0.0/16 0.0.0.0/0
0 0 logdrop ah -- * * 0.0.0.0/7 0.0.0.0/0
0 0 logdrop ah -- * * 2.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 5.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 7.0.0.0/8 0.0.0.0/0
22 1520 logdrop ah -- * * 10.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 23.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 27.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 31.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 36.0.0.0/7 0.0.0.0/0
0 0 logdrop ah -- * * 39.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 41.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 42.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 58.0.0.0/7 0.0.0.0/0
0 0 logdrop ah -- * * 60.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 70.0.0.0/7 0.0.0.0/0
0 0 logdrop ah -- * * 72.0.0.0/5 0.0.0.0/0
209 11072 logdrop ah -- * * 82.0.0.0/7 0.0.0.0/0
0 0 logdrop ah -- * * 84.0.0.0/6 0.0.0.0/0
0 0 logdrop ah -- * * 88.0.0.0/5 0.0.0.0/0
0 0 logdrop ah -- * * 96.0.0.0/3 0.0.0.0/0
0 0 logdrop ah -- * * 127.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 197.0.0.0/8 0.0.0.0/0
0 0 logdrop ah -- * * 222.0.0.0/7 0.0.0.0/0
0 0 logdrop ah -- * * 240.0.0.0/4 0.0.0.0/0
Details: ========== * I'm running BitTorrent, a p2p downloading application
* ports 6881-6889 are opened to new inbound connections and forwarded to 10.2.3.4.
* My ip is 63.194.213.179
* Proper BT traffic would be DST=63.194.213.179 6881:6889 SYN and of course responses to that from me.
I can't for the life of me figure out how this traffic gets here. I mean it's a SYN for pete's sake. Unless is was specifically routed purely with MAC addresses, it makes no sense.
Questions: =========== 1) How on earth is traffic destined for 10.2.3.4 getting all the way from 82.82.76.144 to me, i.e. How is it passing through so many internet routers to me? There should be no route. My ISP has no idea that I use 10.2.3.4 in a NAT setup.
DNAT has already been applied by the time that the rfc1918 chain has been traversed.
Okay, but to let you know, I do successfully use BitTorrent, and have gigabytes of traffic with DST=63.194.213.179 and DPT 6881-6899. It's just that rarely I see this sort of log entry, definitely the exception to Bering's rather boring behavior of working perfectly ;-)
2) Does shorewall not tell me if there is MAC addressing involved?Look at the raw message log to see MAC addressing -- see below.
Maybe I don't understand, but I checked messages, syslog, and kern.log, and they all show the exact same data. Did I miss something?
okey, thanks again for patiently answering my questions. Matt
3) And if it was routed using MAC addresses only (which is the way the net works, correct?)
No.
then why doesn't Shorewall give me the MAC skinny?
If you use "shorewall show log", /sbin/shorewall suppresses the MAC information.
4) And who has 10.2.3.4 in their ARP cache besides Bering. You can't tell me that 10.2.3.4 is ARP all the way through the internet to me?
Again, I suspect that the original destination was 63.194.213.179 but I need to see the "shorewall show rfc1918" output in order to understand more of what is going on. -Tom
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
