I'm not sure if it needs the static routes or not at this point. The WinGate proxy 
server did require the static routes to pass traffic back to the other subnets when it 
was operational (I know because I fought this battle with the Wingate when I installed 
it and the static routes were the solution).

I wish I had access to the routers between the subnets as I think the root problem may 
be there, but the routers are serviced by another company that supports an AS/400 on 
one of their subnets - they threaten to not support the AS/400 if anyone touches their 
routers.. :(

-----Original Message-----
From: Glen L. Bowes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2003 7:08 AM
To: NT 2000 Discussions
Subject: RE: Routing 101


Does the ZyWall need to be aware of the other subnets i.e. have static
routes applied to it?

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Kuhn - MCSE
Sent: Monday, June 23, 2003 8:53 PM
To: NT 2000 Discussions
Subject: OT: Routing 101


I am trying to finish up a ZyWall 10-II Firewall installation and have
one remaining issue..

My customer has 3 subnets spread between 3 towns connected via 64K Frame
relay using IBM routers. Subnets are 10.77.154.0, 10.77.153.0,
10.77.152.0 with mask 255.255.255.0.

Each has a router at on their respective 10.77.15x.3 address. These had
been the default gateways for all machines on their respective subnets
prior to the installation of the ZyWall.

Originally we had a WinGate proxy server at 10.77.154.45 that all
machines specified as their proxy server in IE and all worked well for
all subnets.

We have replaced the WinGate with the ZyWall on a hub on the 10.77.154.0
network at 10.77.154.45 mask 255.255.255.0. I have set that as the
default gateway for the machines on the 10.77.154.0 network and everyone
on the 10.77.154.0 network can access the internet w/no problem. 

I have added static routes on the 10.77.154.0 machines that point to the
10.77.154.3 router for traffic to the other subnets. I have added those
static routes to the Zywall as well. The 10.77.154.0 machines (computers
anyway - not sure about the ZyWall) have no problem communicating with
machines on the other subnets.

We have set IE to not use a proxy server and not detect settings.

We have added static routes on machines on the remote subnets pointing
to their respective routers for traffic to the other subnets. We have
defined the default gateway on those machines as 10.77.154.45 (the
ZyWall).

Machines on the remote subnets (10.77.153.0 and 10.77.152.0) can
communicate with machines on the other subnets. They can ping the ZyWall
successfully. They can't communicate with the internet using IE or
Tracert or FTP or NSLOOKUP. Tracert fails on the first hop (Destination
address cannot be reached).

To me it appears that the ZyWall is not returning traffic to the
machines on the remote subnets. I'm wondering if it is treating the
remote subnets as external address and maybe is returning traffic to
them via the WAN port? 

I talked to the guy who supports the IBM routers for my customer and he
spent some time on it and is stumped.

Life would be simple if the customer would realize that they would be
much better off getting local internet access at their remote locations
rather than stuffing internet traffic into their already overloaded 64K
circuits but listening isn't a strong point in this situation.

Any suggestions? What am I missing?

------
You are subscribed as [EMAIL PROTECTED]
Web Interface:
http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=nt2000&text_mode=&la
ng=english
To unsubscribe send a blank email to %%email.unsub%%


------
You are subscribed as [EMAIL PROTECTED]
Web Interface: 
http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=nt2000&text_mode=&lang=english
To unsubscribe send a blank email to %%email.unsub%%


------
You are subscribed as [EMAIL PROTECTED]
Web Interface: 
http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=nt2000&text_mode=&lang=english
To unsubscribe send a blank email to [EMAIL PROTECTED]

Reply via email to