Re: WinRoute Pro
From: bargepole (jbhur@hotmail.com)Date: 02/03/02
- Next message: Chris: "3-legged firewalls, routing between legs, the "DMZ""
- Previous message: tracker: "Questions about your computer- Download a Port Scanner"
- In reply to: L. Walker: "Re: WinRoute Pro"
- Next in thread: L. Walker: "Re: WinRoute Pro"
- Reply: L. Walker: "Re: WinRoute Pro"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "bargepole" <jbhur@hotmail.com> Date: Sun, 03 Feb 2002 06:40:28 GMT
If a RST is sent to a TCP protocol host, the entry is removed immediately.
If there's no interaction with a host within the allotted time, the entry is
then deleted. You can prove this to yourself by checking the Winroute Debug
Log Show>NAT Table.
1/ Check the NAT table.
2/ Open a TCP connection to a host using a port tool.
3/ Check the NAT table. You'll see your new TCP entry.
4/ Close the connection
5/ Check the NAT table. The entry is gone.
6/ Open another connection.
7/ Check the NAT table
8/ Let the connection sit idle.
9/ Continuing checking the NAT table and once the default timeout elapses,
the entry is removed.
If you were to send data on the connection at, say, halfway through the
timeout period and then check the NAT table, you'd see the time remaining to
timeout has been reset to the value in Settings>Advanced>Misc. Options >NAT
table default timeout for TCP protocol.
Interestingly, use of Winroute's services (HTTP proxy, DNS, mail) by clients
does not show any NAT table entries. There's other weird stuff in the NAT
table log that I haven't figured out (like ICMP port numbers!).
The TCP inactivity timeout setting refers to the LAN or unNATted interface,
I think. It's there that you can specify when to release dead connections
made to the Winroute services (DNS, mail, admin, etc.) from the LAN. Not too
sure about that, though.
Winroute's logs are no substitute for a decent packet sniffer. Though
they're good for trouble shooting and getting a feel for how your networks
are communicating, filtering is awkward and there's no ability to copy
entries right out of the log interface (that really bugs me).
"L. Walker" <k_aneda@yahoo.com> wrote in message
news:Pine.LNX.4.44.0202031541530.279-100000@myst.puzzle...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Under Settings->Advanced->Misc. Info, you can set how long packets stay in
> the NAT table for I believe.
>
> Defaults are 40 minutes for TCP, 8 for UDP. Either that or I changed my
> settings and believe they're default now :P And the test I did was with
> one client + gateway, so I definetly didn't eat up the table limit of
> 1400.
>
> Yeh, packet logging shows some nice information but other times the
> logging in Winroute frustrates me, so I bring in tcpdump and use a linux
> box to dial-in. However I have found that under Debug Info, showing the
> information for DNS packets is quite a good little tool... :P
>
> - --
> L. Walker
> IRC: K_aneda @ AustNET, #rna
> - --
> If one wants to be a policeman, one must learn how to be a thief.
> - --
> That's why we spend so much time trying to understand our own
> motivations and those of others. That's what makes life so
> interesting.
> -- Kaji, Evangelion Ep 18
> - --
>
> On Sun, 3 Feb 2002, bargepole wrote:
>
> > I think Winroute unloads the connection from its NAT table so quickly
> > because it's designed to share a limited resource among many users.
There's
> > a limit of 1400 table entries, so the quicker one is removed, the faster
> > it's available to other users.
> > As you've shown, it's so quick to purge its table that the reply packets
> > from a previously connected host are unrecognized.
> >
> > I read somewhere that Tiny refers to the Settings>Advanced>Security
Options
> > as a "wizard", intended as a quick and easy way to setup firewall
response
> > in a general way. Using packet filter rules with logging offers far
more
> > granularity in determining what is to be logged. Personally, I prefer
> > logging on filter rules, one reason being that each detection uses only
1
> > line, rather than 2, at the expense of slightly less information (packet
> > length).
> >
> > If you have a catchall packet filter rule, maybe you could try turning
> > logging on and turn off the logging in Security Options.
> > For example:
> > Incoming
> > Internet Interface
> > ...
> > Drop IP Any host -> Any host Log
> >
> > This may give you what you want, filling your logs at half the rate. Of
> > course, you could be more selective by adding individual rules for
specific
> > protocols (ICMP, IGMP, TCP, UDP, etc.)
> >
> > "L. Walker" <k_aneda@yahoo.com> wrote in message
> > news:Pine.LNX.4.44.0202031145410.674-100000@myst.puzzle...
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > I am sharing the internet using WinRoute Pro 4.1.27 and
> > > turned on the following log features:
> > >
> > > Log incoming packets that have no record in the NAT table [All]
> > >
> > > Normally I had it on SYN packets only but realised that it would be
handy
> > > to pick up on ACK scans, etc.
> > >
> > > Since having the new logging settings, I have noticed odd things...
> > > Using diagram:
> > >
> > > Webserver <---> Gateway with Winroute <---> Client
> > >
> > > I think I was able to work it out this far, but I thought I'd ask to
see
> > > what you people on the newsgroup think.
> > >
> > > Whenever client uses a webbrowser (only tested with Internet Explorer
and
> > > Outlook Express), when the connection is torn down from the client
side
> > > (send fin ack/ack packet, im a bit rusty with TCP... correct me if im
> > > wrong please), the connection drops out of the NAT table... and then
the
> > > server sends a ACK packet back and since the connection is dropped
from
> > > the NAT table it lists it as a "incoming packet with no entry in the
NAT
> > > table".
> > >
> > > Side note: Another thing I noticed was that masqueraded packets always
had
> > > a source port (from the gateway/NAT box doing the masquerading) of
above
> > > 61000, this helps to filter out the packets when going thru large
logs...
> > >
> > > This is filling up my logs and is becoming rather annoying... anyone
got a
> > > workaround, apart from logging only incoming SYN packets that have no
> > > record in the NAT table...
> > >
> > > Small excerpt from log while browsing yahoo.com:
> > >
> > > 11:54:27 NAT: Detected TCP packet which has no entry in the NAT
table....
> > > 11:54:27 NAT: + proto:TCP, len:54, ip+port:216.115.102.78:80 ->
> > > 203.19.xxx.xxx:61498, flags: FIN ACK...
> > > 11:54:30 NAT: Detected TCP packet which has no entry in the NAT
table....
> > > 11:54:30 NAT: + proto:TCP, len:1514, ip+port:216.115.102.78:80 ->
> > > 203.19.xxx.xxx:61498, flags: ACK...
> > >
> > > - --
> > > L. Walker
> > > IRC: K_aneda @ AustNET, #rna
> > > - --
> > > If one wants to be a policeman, one must learn how to be a thief.
> > > - --
> > > That's why we spend so much time trying to understand our own
> > > motivations and those of others. That's what makes life so
> > > interesting.
> > > -- Kaji, Evangelion Ep 18
> > > - --
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.0.6 (GNU/Linux)
> > > Comment: For info see http://www.gnupg.org
> > >
> > > iD8DBQE8XIuUBJ6saYuOFLgRAqPBAJ9Uae+K2yy8XC4TWrFhmEnYQI66TgCdHjhd
> > > ktuxZDA8VjaCDDYdt+HlaIc=
> > > =sl4V
> > > -----END PGP SIGNATURE-----
> > >
> >
> >
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE8XMBBBJ6saYuOFLgRAlW7AJ9+OtBgImbpu7FHz7PC0Ch0UI8JAgCdEIYF
> JLlSYwL45Rad+1l9QLs1O1o=
> =ZP8m
> -----END PGP SIGNATURE-----
>
- Next message: Chris: "3-legged firewalls, routing between legs, the "DMZ""
- Previous message: tracker: "Questions about your computer- Download a Port Scanner"
- In reply to: L. Walker: "Re: WinRoute Pro"
- Next in thread: L. Walker: "Re: WinRoute Pro"
- Reply: L. Walker: "Re: WinRoute Pro"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
