I believe I may have a solution to your RAS routing problem:
First, upgrade to RRAS. The information below is based upon RRAS and I do
not know how/if it effects an un-upgraded RAS server. Perhaps just the
upgrade to RRAS will solve your problem, since it is an "enhancement" to
basic RAS functionality.
The issue you are experiencing seems to relate to a RRAS router being able
to detect a Dead Default Gateway. This is referred to as Dead Gateway
Detection (DGD).
According to RRAS sources: The reason for this inability to fail-over is
that DGD relies on TCP transmission in order to activate it. When an RRAS
server is behaving as a router, as it is in this case, it never parses the
IP packet beyond the IP layer. Instead, it determines if the packet should
be routed, and then either routes the packet or drops the packet.
Dead Gateway Detection only is activated by a server when it is the
"initiator" of the TCP connection. RRAS is not the source or initiator of
the TCP session, and so is "unaware" that TCP sessions are not working
correctly. Again, because the RRAS server does not "look" above the IP
header when acting as a router, it never "sees" whether a packet is a UDP or
TCP packet. That is why RRAS will never fail-over to the original default
gateway.
Because Microsoft Windows NT RRAS is a single-route router, it only supports
one default gateway - which should be configured to be the DOD connection.
It is expected that the router will learn about dead gateways through a
routing protocol, such as Routing Information Protocol (RIP) or Open
Shortest Path First (OSPF).
I do not know if RIP or OSPF are installable on a server only running RAS.
However they do come with RRAS.
KB article Q235489 <How to Use Routing Information Protocol Over Routing and
Remote Access Service Dial On Demand and Virtual Private Network
Connections> should be able to get you started.
HTH
| -----Original Message-----
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]]On Behalf Of McEve
| Sent: Saturday, February 26, 2000 5:38 AM
| To: [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]
| Subject: RE: Firewall1 problem -reply
|
|
|
| Thank you Michael!
|
| Do you know if this problem is fixed with RRAS? All the machines
| that I have
| experiencing this problem are desktops.
|
| Eve
| -----Original Message-----
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]]On Behalf Of Micheal Espinola Jr
| Sent: 24. februar 2000 18:47
| To: [EMAIL PROTECTED]; McEve
| Cc: [EMAIL PROTECTED]
| Subject: RE: Firewall1 problem -reply
|
|
| In Windows (especially NT) this is an issue when the client is
| multi-homed
| with a NIC and with a modem - for those that carry laptops.
|
| A sure-fire way to prevent this issue is to set up hardware
| profiles (those
| that are selectable during the boot process) for if the user is
| on the local
| LAN, or dialed-up.
|
| For some reason (don't know if its fixed with Win2K), NT4 either
| screws up
| the routes or uses both (but the LAN one first) with RAS.
|
| In the "Dialup" hardware profile, have the NIC disabled. That
| will disable
| its routing table too.
|
| Cant say if this is your issue, but its the closest thing I have
| ever had to
| deal with.
|
| | -----Original Message-----
| | From: [EMAIL PROTECTED]
| | [mailto:[EMAIL PROTECTED]]On Behalf Of
| | [EMAIL PROTECTED]
| | Sent: Sunday, February 20, 2000 3:09 PM
| | To: McEve
| | Cc: [EMAIL PROTECTED]
| | Subject: RE: Firewall1 problem -reply
| |
| |
| | OK...
| | Basically, it appears your accountants are using what is called
| | Dial-On-Demand Routing, but the route that is established from the
| | Dial-On-Demand is not removed after the remote connection is
| | disconnected.
| | So that is where your problem is.
| |
| | /cheers
| |
| | /m
| |
| |
| |
| |
| | "McEve" <[EMAIL PROTECTED]>
| | Sent by: [EMAIL PROTECTED]
| | 02/20/00 11:04 AM
| |
| |
| | To: <[EMAIL PROTECTED]>
| | cc:
| | Subject: RE: Firewall1 problem -reply
| |
| |
| |
| | Thank you mark,
| |
| | It helped me a bit further down the track to a solution. So
| it's not the
| | firewall scanning, and discovering our hosts IP. I'm really
| stumped as to
| | what is causing the route to appear in the routingtable tho. When it's
| | manually deleted, the dialup session is successful - but when
| | disconnecting
| | the blasted thing is back again, causing the next dialup
| attempt to fail.
| | Not very elegant solution having accountants going into the
| | route table to
| | manually delete a route before every dialup attempt...
| |
| | Where to look next....
| |
| | thank you again Mark, for eliminating Firewall1 as the culprit,
| | that's one
| | step closer to a solution anyways :)
| | c
| | Eve
| |
| | -----Original Message-----
| | From: [EMAIL PROTECTED]
| | [mailto:[EMAIL PROTECTED]]On Behalf Of
| | [EMAIL PROTECTED]
| | Sent: 21. februar 2000 19:06
| | To: McEve
| | Cc: [EMAIL PROTECTED]
| | Subject: Re: Firewall1 problem -reply
| |
| |
| | Checkpoint FW-1 does not scan traffic originating from a
| modem. One way
| | of handling this is to install a terminal server/modem pool
| that has some
| | security features to observe traffic originating from the modem. The
| | second approach is to attempt to eliminate all modem transaction based
| | applications and speak with the vendor to see if the applications are
| | compatible with a modem pool or a modem server.
| |
| |
| | If you are accessing IBM Advantis/Mainframe network, IBM
| acquired IVANS a
| | while back which distributed a product called IBM Passport.
| IBM Passport
| | has both Async and TCP/IP options available. It works quite
| well with a
| | modem server for the Async portion and the TCP/IP addresses
| are routeable
| | through a commercial firewall.
| |
| | If you are accessing legacy mainframe application through
| dial-up modems,
| | there are some common transparent modem shims available that work with
| | some of the medium sized modem servers. Basically the modem
| shim is an
| | application that is installed on the pc that tricks the pc in
| thinking a
| | physical modem is still attached. In other words, a
| Communication port
| | redirector.
| |
| | Before scenario:
| |
| |
| | After scenario:
| |
| | Modem Shim application resides on the Client PC.
| |
| | Most of the common modem shim applications can utilize NT
| Authentication
| | databases, which provides authentication and authorization. If
| | implemented correctly, you can also log to a central system logging
| | facility.
| |
| | Hope this helps,
| |
| | /mht
| |
| |
| |
| |
| |
| | "McEve" <[EMAIL PROTECTED]>
| | Sent by: [EMAIL PROTECTED]
| | 02/20/00 09:21 AM
| |
| |
| | To: <[EMAIL PROTECTED]>
| | cc:
| | Subject: Firewall1 problem
| |
| |
| |
| |
| | Hello
| |
| | Typical scenario is this:
| |
| | A LAN, connected to the internett through a leased line, Firewall1
| | installed
| | to scan all traffic going through the leased line. Some
| workstations also
| | have modems installed. Is it possible for Firewall1 to pick
| up and scan
| | the
| | traffic from and to the workstations when they connect using
| the modem,
| | through a different line?
| |
| | background for my question:
| | I do support for an application that connects to a mainframe for data
| | transfer. This application will not be able to communicate
| with our host
| | if
| | there is a proxy or firewall between the client and our host,
| so they use
| | the modem to connect instead of the leased line. However,
| some customers
| | are
| | still unable to connect to the mainframe, and upon further
| investigation,
| | we
| | find a route in the routingtable pointing out host straight
| to the IP of
| | the
| | firewall.
| |
| | I don't know Firewall1, and can't find an answer to how this route
| | appears,
| | effectively causing the communication to the mainframe to
| fail. Anybody
| | with
| | knowledge of firewall1 that can expain to me how we can avoid
| this route
| | being created in the route table? Configuration in Firewall1?
| or with the
| | client?
| |
| | Any help would be great
| |
| | thank you
| |
| |
| | Eve
| |
| | -
| | [To unsubscribe, send mail to [EMAIL PROTECTED] with
| | "unsubscribe firewalls" in the body of the message.]
| |
| |
| | -
| | [To unsubscribe, send mail to [EMAIL PROTECTED] with
| | "unsubscribe firewalls" in the body of the message.]
| |
| | -
| | [To unsubscribe, send mail to [EMAIL PROTECTED] with
| | "unsubscribe firewalls" in the body of the message.]
| |
| |
| | -
| | [To unsubscribe, send mail to [EMAIL PROTECTED] with
| | "unsubscribe firewalls" in the body of the message.]
|
| -
| [To unsubscribe, send mail to [EMAIL PROTECTED] with
| "unsubscribe firewalls" in the body of the message.]
|
| -
| [To unsubscribe, send mail to [EMAIL PROTECTED] with
| "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
