Networking Forums

Networking Forums > Computer Networking > Broadband > Odd - Turnpike News & DrayTek 2600 firewall

Reply
Thread Tools Display Modes

Odd - Turnpike News & DrayTek 2600 firewall

 
 
bof
Guest
Posts: n/a

 
      01-08-2004, 12:44 PM

I have a PC running Win ME and Zone Alarm connected via NAT through a
DrayTek 2600 the PC also runs Turnpike 6 for news collection from
news.cis.dfn.de.

Today Zone Alarm registered a connection attempt to port 1099 from port
119 on remote IP address 130.133.1.4 (uni berlin) when I closed the Zone
Alarm alert Turnpike's News Database became corrupt and needed to be
rebuild.

Any thoughts as to what occurred? I wouldn't have expected any such
connection attempt to pass through the NAT on the router, nothing else
has in the many months the router's been connected. Was the Turnpike
news database corruption just coincidence, I don't recall that occurring
on the machine before? Any thoughts welcome.


--
bof at bof dot me dot uk
 
Reply With Quote
 
 
 
 
John Underwood
Guest
Posts: n/a

 
      01-08-2004, 01:26 PM
On Thu, 8 Jan 2004 at 13:44:50, bof wrote in demon.ip.support.turnpike
(Reference: <TlVWoUFS7V$$(E-Mail Removed)>)


>Today Zone Alarm registered a connection attempt to port 1099 from port
>119 on remote IP address 130.133.1.4 (uni berlin) when I closed the
>Zone Alarm alert Turnpike's News Database became corrupt and needed to
>be rebuild.


Port 119 is the common port for NNTP - the news protocol. If you block
that then your news will not arrive.

Blocking it midstream is highly likely to have unpredictable effects,
but I am surprised that database corruption was among them. (Though I
would not blame the program designers for failing to realise that
someone would cut off the stream mid-packet).

The documentation for several applications on your news server's web
site makes it quite clear that you must be able to receive on Port 119.

You can rely on your NAT router, provided it has been configured
properly and if you have not changed any of its default settings (which
you unlikely to need to do if you receive mail by SMTP or run other
servers) it will not pass any packets that do not match a request - this
is simply because without a previous packet from an internal address to
which an incoming packet is a response, it has no idea where to send the
incoming packet.

You should ask yourself what Zone Alarm thinks it is doing flagging such
an error. I would also question whether there is any point in running
Zone Alarm as an outward looking firewall when it sits behind a reliable
hardware firewall such as you have.

There may be a purpose in using a software firewall to protect your
machine against intrusion from other machines on your network. You may
also want to use the inward looking packet authorisation check if you
think that is worth having. You do need more than trivial knowledge for
that function to cause less trouble than it might save provided you have
other protection such as the real firewall you have and, above all, a
reliable and up to date virus checker.
--
John Underwood
Do not change the Reply-To: address -it will work if you use it within 30 days.
After that visit <http://theunderwoods.org.uk/contact.html> for a current
contact address. Do not write to the From: address.
 
Reply With Quote
 
bof
Guest
Posts: n/a

 
      01-08-2004, 02:54 PM
In message <l6a4H4RDiW$$(E-Mail Removed)> , John
Underwood <(E-Mail Removed)> writes
>On Thu, 8 Jan 2004 at 13:44:50, bof wrote in demon.ip.support.turnpike
>(Reference: <TlVWoUFS7V$$(E-Mail Removed)>)
>
>
>>Today Zone Alarm registered a connection attempt to port 1099 from
>>port 119 on remote IP address 130.133.1.4 (uni berlin) when I closed
>>the Zone Alarm alert Turnpike's News Database became corrupt and
>>needed to be rebuild.

>
>Port 119 is the common port for NNTP - the news protocol. If you block
>that then your news will not arrive.


Indeed, it's not blocked, or at least shouldn't be, the machine's been
happily collecting news for months and is now once again happily
collecting news.

I can only assume ZA for some reason suddenly decided to block port 119,
my surprise and consternation at seeing ZA flag a block caused me to
misinterpret what it was telling me as though it had blocked an incoming
connection attempt (which would have had to have passed through the
router's firewall)

>
>Blocking it midstream is highly likely to have unpredictable effects,
>but I am surprised that database corruption was among them. (Though I
>would not blame the program designers for failing to realise that
>someone would cut off the stream mid-packet).
>
>The documentation for several applications on your news server's web
>site makes it quite clear that you must be able to receive on Port 119.
>
>You can rely on your NAT router, provided it has been configured
>properly and if you have not changed any of its default settings (which
>you unlikely to need to do if you receive mail by SMTP or run other
>servers) it will not pass any packets that do not match a request -
>this is simply because without a previous packet from an internal
>address to which an incoming packet is a response, it has no idea where
>to send the incoming packet.
>
>You should ask yourself what Zone Alarm thinks it is doing flagging
>such an error. I would also question whether there is any point in
>running Zone Alarm as an outward looking firewall when it sits behind a
>reliable hardware firewall such as you have.
>
>There may be a purpose in using a software firewall to protect your
>machine against intrusion from other machines on your network. You may
>also want to use the inward looking packet authorisation check if you
>think that is worth having. You do need more than trivial knowledge for
>that function to cause less trouble than it might save provided you
>have other protection such as the real firewall you have and, above
>all, a reliable and up to date virus checker.


Indeed, the system's been set up and working fine for around eight
months, ZA is there to monitor outgoing connection attempts and it
shouldn't have flagged or blocked Turnpike's NNTP connection
(historically it hasn't and now it isn't), in retrospect I think ZA just
had a temporary glitch.

Thanks for the reply.

--
bof at bof dot me dot uk
 
Reply With Quote
 
Peter R Cook
Guest
Posts: n/a

 
      01-08-2004, 06:17 PM
In message <TlVWoUFS7V$$(E-Mail Removed)>, bof
<(E-Mail Removed)> writes
>
>I have a PC running Win ME and Zone Alarm connected via NAT through a
>DrayTek 2600 the PC also runs Turnpike 6 for news collection from
>news.cis.dfn.de.
>
>Today Zone Alarm registered a connection attempt to port 1099 from port
>119 on remote IP address 130.133.1.4 (uni berlin) when I closed the
>Zone Alarm alert Turnpike's News Database became corrupt and needed to
>be rebuild.
>
>Any thoughts as to what occurred? I wouldn't have expected any such
>connection attempt to pass through the NAT on the router, nothing else
>has in the many months the router's been connected. Was the Turnpike
>news database corruption just coincidence, I don't recall that
>occurring on the machine before? Any thoughts welcome.
>
>

Just a thought - could be the cause was the other way round and what you
saw was a timing effect?

If Tpk was connected out on 1099 to 119 at uni berlin, ZA and the
DrayTek would both have this flagged as legitimate traffic.

Tpk has a hiccough (caused by a transient disk error etc. that caused
the database to be corrupted) which causes it to drop the connection
(close 1099) after sending a request for news, but before uni berlin had
responded. If ZA deleted 1099 from its "expected traffic list" (no idea
what the proper title is for this) before the DrayTek then response
traffic from uni berlin directed at the (now closed ) 1099 port would
penetrate the DrayTek, but get caught as a "connection attempt" by ZA.

I might expect ZA to expire 1099 if it saw the port closed by Tpk, while
the DrayTek (presumably) has to depend on time-outs to cope with
problems like this.

Regards
--
Peter R Cook
 
Reply With Quote
 
Brian Morrison
Guest
Posts: n/a

 
      01-08-2004, 07:02 PM
On Thu, 08 Jan 2004 19:17:25 +0000, in article
<Nty32UCFza$$Ew+(E-Mail Removed)> Peter R Cook
<(E-Mail Removed)> wrote:

> In message <TlVWoUFS7V$$(E-Mail Removed)>, bof
> <(E-Mail Removed)> writes
>>
>>I have a PC running Win ME and Zone Alarm connected via NAT through a
>>DrayTek 2600 the PC also runs Turnpike 6 for news collection from
>>news.cis.dfn.de.
>>
>>Today Zone Alarm registered a connection attempt to port 1099 from port
>>119 on remote IP address 130.133.1.4 (uni berlin) when I closed the
>>Zone Alarm alert Turnpike's News Database became corrupt and needed to
>>be rebuild.
>>
>>Any thoughts as to what occurred? I wouldn't have expected any such
>>connection attempt to pass through the NAT on the router, nothing else
>>has in the many months the router's been connected. Was the Turnpike
>>news database corruption just coincidence, I don't recall that
>>occurring on the machine before? Any thoughts welcome.
>>
>>

> Just a thought - could be the cause was the other way round and what you
> saw was a timing effect?
>
> If Tpk was connected out on 1099 to 119 at uni berlin, ZA and the
> DrayTek would both have this flagged as legitimate traffic.
>
> Tpk has a hiccough (caused by a transient disk error etc. that caused
> the database to be corrupted) which causes it to drop the connection
> (close 1099) after sending a request for news, but before uni berlin had
> responded. If ZA deleted 1099 from its "expected traffic list" (no idea
> what the proper title is for this) before the DrayTek then response
> traffic from uni berlin directed at the (now closed ) 1099 port would
> penetrate the DrayTek, but get caught as a "connection attempt" by ZA.
>
> I might expect ZA to expire 1099 if it saw the port closed by Tpk, while
> the DrayTek (presumably) has to depend on time-outs to cope with
> problems like this.


Personally I think it is far more likely that ZA threw a wobbly and
decided that the legit incoming traffic to port 1099 was in need of
blocking. ZA is not at all bright because it cannot deal with programs
that want more than the port they use when first detected. It wouldn't
surprise me if ZA screwed it up for you, possibly even mangling the
packets and confusing TP.

I'd get a proper software firewall if you want to keep using one.

--

Brian Morrison

please observe reply-to address

 
Reply With Quote
 
Jim Crowther
Guest
Posts: n/a

 
      01-08-2004, 11:46 PM
In message <Nty32UCFza$$Ew+(E-Mail Removed)>, Peter R Cook
<(E-Mail Removed)> writes:

>In message <TlVWoUFS7V$$(E-Mail Removed)>, bof
><(E-Mail Removed)> writes
>>
>>I have a PC running Win ME and Zone Alarm connected via NAT through a
>>DrayTek 2600 the PC also runs Turnpike 6 for news collection from
>>news.cis.dfn.de.
>>
>>Today Zone Alarm registered a connection attempt to port 1099 from
>>port 119 on remote IP address 130.133.1.4 (uni berlin) when I closed
>>the Zone Alarm alert Turnpike's News Database became corrupt and
>>needed to be rebuild.
>>
>>Any thoughts as to what occurred? I wouldn't have expected any such
>>connection attempt to pass through the NAT on the router, nothing else
>>has in the many months the router's been connected. Was the Turnpike
>>news database corruption just coincidence, I don't recall that
>>occurring on the machine before? Any thoughts welcome.
>>
>>

>Just a thought - could be the cause was the other way round and what
>you saw was a timing effect?


Very likely. Sometimes a server might be very tardy in replying (NIN
usually isn't, but Demon servers can be) and some TP time-out may well
have occurred. In these cases ZA(P) does its job.

--
Jim Crowther "It's MY computer" (tm SMG)
Avoid more swen by dumping your old Usenet addresses, and
put 'spam' or 'delete' somewhere in the Reply-to: header.
Help yourself avoid the spam: <http://keir.net/k9.html>
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
VPN FROM behind Draytek 2600 Mike Broadband 0 12-23-2004 04:49 PM
Draytek 2600 Firewall setup TX2 Broadband 8 10-20-2003 01:01 PM
Draytek 2600 firewall settings Kev Parkin Broadband 1 10-02-2003 07:23 PM
Speedtouch 510 v4 Vs Draytek Vigor 2600 (firewall) tHatDudeUK Home Networking 8 08-26-2003 12:04 AM
Speedtouch 510 v4 Vs Draytek Vigor 2600 (firewall) tHatDudeUK Broadband 8 08-26-2003 12:04 AM



1 2 3 4 5 6 7 8 9 10 11