|
发表于 2005-8-2 13:55:53
|
显示全部楼层
m0n0wall 1.2b9
和WallWatcher3.23
不能正常工作!
Monomon检测流量的没有问题!
这里应该有答案,还没有来的及研究:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To: "WallWatcher Support"
From: "Quark IT - Hilton Travis"
Subject: RE: WallWatcher & m0n0wall
Date: Sun, 13 Feb 2005 13:05:44 +1000
Hi Dan,
I've forwarded this also to the monowall-dev list to see if someone on
there can provide better answers than I can - I'm not totally clued up
on all aspects of m0n0wall, and totally clueless on others.
I'll answer your laso post inline...
--
Regards,
Hilton Travis Phone: +61 (0)7 3344 3889
(Brisbane, Australia) Phone: +61 (0)419 792 394
Manager, Quark IT http://www.quarkit.com.au
Quark AudioVisual http://www.quarkav.net
http://www.threatcode.com/ -----Original Message-----
> From: WallWatcher Support [mailto:support at wallwatcher dot com]
> Sent: Sunday, 13 February 2005 11:46
>
> Hi Hilton,
>
> Your m0n0wall records are different in several respects from the
> other samples I've seen:
>
> 1. the others tended to occur in pairs: LAN-to-Router, then
> Router-to-Remote. WW reports the first one and ignores the
> second one. I didn't see any such pairs in your samples. It
> doesn't affect anything, just a difference.
This may be a result of my running 1.2b3 and your previous users running
version 1.1 of m0n0wall. I hope someone on the m0n0wall list can
further comment on this.
> 2. some of the "flags" that indicate what was done with the
> packets are different in your samples than in the others. For
> example, I don't know what your router did with the three
> packets reported by these two log records:
>
> (1)
> Feb 13 00:08:25 ipmon[77]: 00:08:25.040616 ng0 @0:21 b
> 194.177.179.75,57347 -> 220.240.217.84,135 PR tcp len 20 48 -S IN
>
> (2)
> Feb 13 00:08:33 ipmon[77]: 00:08:33.866907 ng0 @0:21 b
> 222.88.173.5,12056 -> 220.240.217.84,1026 PR udp len 20 668 IN
>
> (3)
> Feb 13 00:07:40 ipmon[77]: 00:07:40.717625 sis0 @0:19 b
> 192.168.69.120,2753 -> 64.69.76.10,80 PR tcp len 20 40 -AF IN
Again, this may be because of later versions of the firewalling apps in
m0n0wall 1.2b3 compared to the 1.1 release, and again I hope someone
with more clue than I can help out here.
> The first two came IN from the 'net. The flag is "-S".
> Based on previous samples, I believe the first one was dropped,
> and WW currently reports it that way: as an Inbound.
It was - according to the m0n0wall webGUI. As it should have been.
> The second one contains neither your real IP address nor any
> of your LAN addresses, but the "Length" fields indicate content
> beyond just headers. There are no flags, which never occurred
> in other people's samples. WW currently reports it as a dropped
> Inbound.
It, too, was and should have been dropped.
> The third one is an Outbound from a LAN station to a Remote
> IP. The flags are "-AF", and I don't know what they mean. WW
> currently reports it as a blocked Outbound.
That's weird - it appears to be a reguler outbound packet to a web
server, so I have no idea why this was blocked. I have also confirmed
that I have no firewall rules with this IP, and no firewall rules
blocking any traffic to any external web servers. Unfortunately, due to
the limited logging capacity of m0n0wall, I cannot confirm what m0n0wall
saw this as.
> Last year, I did review some m0n0wall documentation, but its
> description of the status flags didn't necessary match the data
> samples. (They never do, regardless of the router.) So, if you
> know what the flags actually mean, or what the router actually
> did with such records, please let me know.
Anyone got some info on this? It'd be nice if the latest online
documentation matched the actual packages. The issue - again - will be
if there's a big difference between m0n0wall 1 1 and m0n0wall 1.2b3.
> Another point: other people's samples had a "blocked/passed"
> indicator; all of yours contain only a "blocked" indicator: the
> stand-alone letter "b". ("p" would be "passed", of course).
Maybe my m0n0wall isn't reporting "passed" packets, or maybe it is just
a little constipated? I have no issues browsing or anything else,
and don't otherwise notice blocked outbound traffic issues.
> Combining all of these differences, WW finds no "passed
> Outbounds" (green "O"s) in your RAW files. Since I'm sure you
> did some successful browsing and/or email checking while those
> samples were being collected, this means one of two things: the
> router is not reporting "passed" packets, or WW is not
> recognizing them. (There aren't any "Passed Inbounds" either,
> but that's normal unless you're running a Server.)
We have an SMTP server here, so should be definitely seeing passed
:25/TCP traffic. Unless, of course, m0n0wall isn't reporting these to
WW.
> Can you let me know which is the case? If there are
> "passed Outbounds", can you tell me what their flags or other
> characteristics are?
>
> Regards,
> Dan Tseng
> http://www.wallwatcher.com
>
>
> ----- Original Message -----
> From: "Quark IT - Hilton Travis"
> Sent: Friday, February 11, 2005 11:58 PM
>
>
> > Hi Dan,
> >
> > Thanks for this. It now seems to be consistent, the settings
> > I made originally have not been changed, but it is reporting
> > the traffic going in the wrong direction - it is seeing the
> > m0n0wall LAN as the WAN and its WAN as its LAN. So, its
> > consistent, but now 100% wrong compared to the m0n0wall webGUI
> > interface, that is!
> >
> > --
> >
> > Regards,
> >
> > Hilton Travis Phone: +61 (0)7 3344 3889
> > (Brisbane, Australia) Phone: +61 (0)419 792 394
> > Manager, Quark IT http://www.quarkit.com.au
> > Quark AudioVisual http://www.quarkav.net
> >
> > http://www.threatcode.com/ > into writing code that is acceptable for use on today's networks
> >
> > War doesn't determine who is right. War determines who is left.
> >
> > > -----Original Message-----
> > > From: WallWatcher Support [mailto:support at wallwatcher dot com]
> > > Sent: Saturday, 12 February 2005 17:48
> > >
> > > Hi Hilton,
> > >
> > > Fixed: http://www.wallwatcher.com/WW.zip (3.2.1501)
> > >
> > > 1. download the link to the WW folder
> > > 2. stop ww if it's running
> > > 3. unzip the download
> > > 4. restart WW
> > >
> > > Should be OK immediately, but check the Router menu to make
> > > sure the values are still correct.
> > >
> > > Please let me know one way or the other whether all is OK
> > > now.
> > >
> > > Regards,
> > > Dan Tseng
> > >
> > >
> > > ----- Original Message -----
> > > From: "Quark IT - Hilton Travis"
> > > Sent: Friday, February 11, 2005 11:00 PM
> > >
> > >
> > > Hi Dan,
> > >
> > > I'm running 3.2.14(11) and the router's LAN address is
> > > configured correctly. Please find attached the files you
> > > requested. I hope this helps locate and fix this bug.
> > >
> > > --
> > >
> > > Regards,
> > >
> > > Hilton Travis Phone: +61 (0)7 3344 3889
> > > (Brisbane, Australia) Phone: +61 (0)419 792 394
> > > Manager, Quark IT http://www.quarkit.com.au
> > > Quark AudioVisual http://www.quarkav.net
> > >
> > > http://www.threatcode.com/ > > into writing code that is acceptable for use on today's networks
> > >
> > > War doesn't determine who is right. War determines who is left.
> > >
> > > > -----Original Message-----
> > > > From: WallWatcher Support [mailto:support at wallwatcher dot com]
> > > > Sent: Saturday, 12 February 2005 16:53
> > > >
> > > > Hi Hilton,
> > > >
> > > > It does look as though WW is sometimes reversing the local
> > > > and remote information. If you are running WW version
> > > > 3.2.13 or higher, please make sure the router's LAN
> > > > address on the ROUTER menu is correct, and change it if
> > > > it's wrong.
> > > >
> > > > If you're running an earlier version of WW, please
> > > > download the current version, stop WW if it's running,
> > > > unzip the download, restart WW (no SETUP needed), and
> > > > check that LAN address.
> > > >
> > > > If the LAN address is correct and the interfaces are
> > > > identified correctly, but WW continues to reverse the
> > > > information, please collect some data to send me:
> > > >
> > > > 1. on WW's SPECIAL menu, turn on 'Capture', then click OK.
> > > > 2. let WW run until you've seen some good and some bad
> > > > entries in the Events list.
> > > > 3. turn off 'Capture' and click OK
> > > > 4. send me (zipped, if possible):
> > > >
> > > > * WallWatcher.Ini
> > > > * RAW yyyy-mm-dd.DAT (the date you do this; the RAW
> > > > file will be in the main WW folder, not in the
> > > > DATLOGS folder)
> > > >
> > > > Those files will let me recreate the error here and,
> > > > hopefully, correct it.
> > > >
> > > > Regards,
> > > > Dan Tseng
> > > > http://www.wallwatcher.com
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Quark IT - Hilton Travis"
> > > > To:
> > > > Sent: Friday, February 11, 2005 9:53 PM
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I just came across WallWatcher when investigating software
> > > > options for Linksys WRT54G/GS WiFi routers. It looks like
> > > > it could be quite useful as I have a m0n0wall firewall
> > > > here (version 1.2b3) on a Soekris net4501 embedded PC. I
> > > > like the functionality, and the fact that this is nice,
> > > > small, and runs on Windows is a big bonus!
> > > >
> > > > The one thing I have noted is that with my net4501 which
> > > > has 3 SIS LAN ports on board (sis0, sis1, sis2) is that no
> > > > matter what I put in as the LAN and WAN NICs, the display
> > > > that WallWatcher gives does not match with the log listing
> > > > that m0n0wall shows. By default, sis0 is LAN, sis1 is
> > > > WAN and sis2 is DMZ - and this is definitely how my
> > > > net4501 is configured. I double-checked the cabling and
> > > > the cabling matches this. As does the "Interfaces" page
> > > > in the m0n0wall configuration. I currently have an IP and
> > > > network assigned to the DMZ (sis2) but there is nothing
> > > > connected to this NIC.
> > > >
> > > > I have changed the interface assignment back to default,
> > > > cleared the WallWatcher display, and here's a screen
> > > > capture of the results. My m0n0wall's external IP is
> > > > 220.240.217.84 and its internal interface is assigned
> > > > 192.168.69.254/24 - the machine I'm running WallWatcher
> > > > on is 192.168.69.120/24. Below this is a capture of the
> > > > same entries in the m0n0wall "Firewall" log, and below
> > > > that is a capture of the Interface assignment in m0n0wall.
> > > >
> > > > So, right now, I'm kinda stumped as to where to go from
> > > > here. I've tried using "sis2" in both WallWatcher fields
> > > > - basically tried all combinations - and haven't found a
> > > > combination that matches the output from m0n0wall. Any
> > > > ideas, smacks in the side of the head, or whatever will be
> > > > appreciated.
> > > >
> > > > - HiltonT |
|