So, you had a multi-gateway environment, and needing a route is exactly what I would expect.
I have an environment like that at $WORK, though I'm fixing it this weekend. Currently, the default gateway for our Engineering subnet is 192.168.13.1, but the router for the Engineering lab is on 192.168.13.2. After this weekend, that will no longer be the case. I finally have the equipment and configuration in place to support a more supportable/understandable environment. Kurt On Wed, Apr 27, 2011 at 19:32, Richard Stovall <[email protected]> wrote: > I also thought I saw a request for the server's routing table somewhere > along the line, but perhaps I misremember. > Anyway, to Kurt's post. This is certainly a corner case, but for several > years we had one server with a persistent route to an IP outside our > firewall that specified a gateway other than the default. This occurred > when we moved to a new building and added a second ISP on a second firewall > which became our default route to the internet. The server in question > transferred a file over an IPSEC VPN to a partner company once a day, and > public endpoint IPs were part of the configuration. When we moved, we kept > the old ISP as a backup, added a faster one as primary, and it made sense to > have the default gateway change to the new ISP. The one VPN, however, still > needed to go out over the old ISP. Separate firewalls handled the ISP > connections, so I just added a persistent route on the one server that > specified the backup firewall (not the default gateway anymore), and it > continued to work until we finally got rid of the VPN altogether. > And yes, we could have modified the VPN config, but the partner company is > HUGE, with HUGE company change control procedures, and it would have taken a > very long time. Management decided that since we were keeping the original > ISP and IP space, we should just configure a persistent route and be done > with it. > So, rare as they may be, there are circumstances in which a machine that > isn't multi-homed might need an abby-normal routing table. > > On Wed, Apr 27, 2011 at 6:32 PM, Kurt Buff <[email protected]> wrote: >> >> Just out of simple curiosity, why did you need route statements for >> these machines? I don't remember seeing in the earlier discussion >> anything about these machines being multi-homed, so I'm wondering if >> you have a multi-gateway environment, and if so, why? >> >> If not affected servers are not multi-homed, and not a mult-gateway >> environment, then I'd be scratching my head on this. >> >> Kurt >> >> On Wed, Apr 27, 2011 at 07:17, G.Waleed Kavalec <[email protected]> wrote: >> > OK >> > Everybody prepare to laugh. >> > >> > Removed the ROUTE on server R1. >> > Re-added the ROUTE on server R1. >> > >> > Problem gone. >> > >> > >> > >> > On Mon, Apr 25, 2011 at 12:57 PM, G.Waleed Kavalec <[email protected]> >> > wrote: >> >> >> >> Servers R1 and R2 have been up for months, but until recently access >> >> from >> >> subnet B was not tested. >> >> I added IP address 192.168.2.142 and it gives the same results. >> >> So I move 192.168.2.142 to (working) server R3 and nMap says. . . >> >> Starting Nmap 5.51 ( http://nmap.org ) at 2011-04-25 12:53 Central >> >> Daylight Time >> >> >> >> Nmap scan report for 192.168.2.142 >> >> Host is up (0.0097s latency). >> >> PORT STATE SERVICE >> >> 137/tcp closed netbios-ns >> >> 138/tcp closed netbios-dgm >> >> 139/tcp closed netbios-ssn >> >> 445/tcp open microsoft-ds >> >> 1433/tcp open ms-sql-s >> >> Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds >> >> >> >> The problem occurs ONLY on R1 and R2, even with a different IP >> >> So, I am missing how this can be on the router? >> >> Thanks! >> >> >> >> >> >> On Mon, Apr 25, 2011 at 11:37 AM, Kim Longenbaugh >> >> <[email protected]> wrote: >> >>> >> >>> Hi, >> >>> >> >>> >> >>> >> >>> I may have missed the question about “is this a new setup, or an >> >>> existing >> >>> one that broke?” if it was working before, when did it break, and >> >>> what >> >>> changed? >> >>> >> >>> >> >>> >> >>> If it is a new setup, then the ACLs and/or firewall settings others >> >>> have >> >>> suggested are the best candidates for the culprit. >> >>> >> >>> >> >>> >> >>> From: G.Waleed Kavalec [mailto:[email protected]] >> >>> Sent: Saturday, April 23, 2011 7:43 PM >> >>> >> >>> To: NT System Admin Issues >> >>> Subject: frustrating network issue on two servers >> >>> >> >>> >> >>> >> >>> Two sites, R and B. Same domain, different subnets. >> >>> >> >>> >> >>> >> >>> All R servers can see all B servers >> >>> >> >>> All B servers can see all R servers - EXCEPT TWO >> >>> >> >>> >> >>> >> >>> R1 and R2 see all B servers, browse folders etc. >> >>> >> >>> >> >>> >> >>> B servers can PING R1 and R2 just fine; R1 and R2 can PING B >> >>> servers just >> >>> fine. >> >>> >> >>> >> >>> >> >>> But B cannot browse R1 or R2 folders for nothing. >> >>> >> >>> >> >>> >> >>> Diagnose gives "file and print sharing resource R1 is online but isn't >> >>> responding to connection attempts" >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Other R servers can browse R1 and R2 no problem. >> >>> Other R servers can connect to R1 and R2 sql instances just fine. >> >>> >> >>> >> >>> >> >>> B servers can can browse other R servers no problem. >> >>> >> >>> B servers can can connect to other R servers sql instances just fine. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Firewalls OFF, route statements confirmed (see: ping) >> >>> >> >>> >> >>> >> >>> All machines 2008 R2 up-to-date on patches. >> >>> >> >>> >> >>> >> >>> I **think** I have verified all necessary services are up. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Arrrrggh ! >> >>> >> >>> -- >> >>> >> >>> >> >>> >> >>> __________________ >> >>> >> >>> Gregory Waleed Kavalec >> >>> --------------------------------------------- >> >>> >> >>> G.O.P. stands for "George Orwell Prediction" >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> >>> >> >>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >>> >> >>> --- >> >>> To manage subscriptions click here: >> >>> http://lyris.sunbelt-software.com/read/my_forums/ >> >>> or send an email to [email protected] >> >>> with the body: unsubscribe ntsysadmin >> >>> >> >>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> >>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >>> >> >>> --- >> >>> To manage subscriptions click here: >> >>> http://lyris.sunbelt-software.com/read/my_forums/ >> >>> or send an email to [email protected] >> >>> with the body: unsubscribe ntsysadmin >> >> >> >> >> >> -- >> >> >> >> __________________ >> >> Gregory Waleed Kavalec >> >> --------------------------------------------- >> >> G.O.P. stands for "George Orwell Prediction" >> >> >> >> >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> >> >> --- >> >> To manage subscriptions click here: >> >> http://lyris.sunbelt-software.com/read/my_forums/ >> >> or send an email to [email protected] >> >> with the body: unsubscribe ntsysadmin >> > >> > >> > -- >> > >> > __________________ >> > Gregory Waleed Kavalec >> > --------------------------------------------- >> > G.O.P. stands for "George Orwell Prediction" >> > >> > >> > >> > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> > >> > --- >> > To manage subscriptions click here: >> > http://lyris.sunbelt-software.com/read/my_forums/ >> > or send an email to [email protected] >> > with the body: unsubscribe ntsysadmin >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
