[ previous ] [ next ] [ threads ]
 
 From:  "Quark IT - Hilton Travis" <hilton at quarkit dot com dot au>
 To:  "WallWatcher Support" <support at wallwatcher dot com>
 Cc:  <m0n0wall dash dev at lists dot m0n0 dot ch>
 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/ <-- its now time to shame poor coders 
into writing code that is acceptable for use on today's networks

War doesn't determine who is right.  War determines who is left.

This document and any attachments are for the intended recipient 
  only.  It may contain confidential, privileged or copyright 
     material which must not be disclosed or distributed. 

> -----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)
> <132>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)
> <132>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)
> <132>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" <hilton at quarkit dot com dot au>
> 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/ <-- its now time to shame poor coders
> > 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" <hilton at quarkit dot com dot au>
> > > 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/ <-- its now time to shame poor coders
> > > 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" <hilton at quarkit dot com dot au>
> > > > To: <support at wallwatcher dot com>
> > > > 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