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

Reply via email to