Re: Multi-homing with win2k srv

From: Fatboyslimro (fatboyslimro_at_hotmail.com)
Date: 03/04/04


Date: Thu, 4 Mar 2004 15:40:58 +0200

Here is a post from a "sysop" from another forum.
Please tell me what is your opinion.
" Interesting but somewhat complex. First, let me exercise my right as an
unpaid answerer to offer some unhelpful advice<g>. You should abandon your
plan! You would (probably) get much better results from paying one of the
very professional web server companies that have REALLY good systems and
quite inexpensive services.

The big web service companies (usually) have all the security issues sorted
out, whereas you will have to spend the rest of your life wondering if your
server has been hacked. For a fee, they can offer much better speeds and
load balancing than you can achieve. Now, back to your problem...

I trust you have W2000 SP4 and visit Windows Update and take all the
Critical Updates (only) each week. You should also have a firewall on each
interface that connects to the Internet (two hardware firewalls).

For more thorough testing with the pings, use the -w 8000 (wait 8 seconds)
option. From the 202.1.1.1 client:

ping -w 8000 213.5.6.7

I expect this to fail, but you should check.

I would install Network Monitor and capture packets on each external
interface. The NetMon provided with W2000 Server is fine. You would have to
run it twice (at the same time). In one instance, use the Capture menu to
select NIC2. In the other instance, select NIC3. Run 'ipconfig /all' at
command prompt to help learn which NIC is which.

I am very confident that NetMon would confirm the following.

When 202.1.1.1 issues 'ping 213.5.6.7', the ping would arrive on NIC3
because ISP2 routes all traffic for destination 213.5.6.7 to your interface
that is connected to ISP2.

Your computer will send a reply to 202.1.1.1. The reply is routed by your IP
software and it has no regard for how the packet arrived. The reply will be:
>From source 213.5.6.7 to destination 202.1.1.1.

The destination does not match any specific route so it will be sent to your
default gateway (via NIC2 to ISP1). I suspect that filtering performed by
ISP1 will drop your packet because ISP1 is not supposed to send spoofed or
otherwise stupid packets to the Internet.

Similarly, when client 62.1.1.1 pings 194.1.2.3, the ping will arrive at
NIC2 from ISP1, but the reply will exit from NIC3 to ISP2 (because of your
route for network 62.0.0.0). ISP2 will drop the packet because it is from
194.1.2.3.

You are attempting to have two connections to the Internet. The proper way
to do this is to negotiate with each ISP and explain what you want. A
transfer of money will be involved (from you to them<g>). You would need
quite an expensive system using the BGP routing protocol. I haven't done
this but I suspect that the costs involved would be much more than paying
for a professional (and much better) web hosting service.

Sorry, but I think you have a problem that can't be fixed by adjustments at
your end. It is possible that using a moderately sophisticated router would
overcome most of your issues. It would have three interfaces: ISP1, ISP2,
your server. Some routers can be configured with elaborate routing tables
and could possibly use the incoming interface for a reply (pretty tricky)."

"Herb Martin" <news@LearnQuick.com> wrote in message
news:OZWMr7dAEHA.212@TK2MSFTNGP12.phx.gbl...
>
>
> --
> Herb Martin
> "Fatboyslimro" <fatboyslimro@hotmail.com> wrote in message
> news:#g16Q#cAEHA.2300@TK2MSFTNGP10.phx.gbl...
> > Let's forget about the second goal.
> > Let's forget about having static routes.
> > Lets's focus on the visibility from internet.
> > So now the configuration is: default GW to ISP1 and no static routes to
> > ISP2.
> > Now if we go to ANY Internet host and ping the interface connected to
ISP2
> > we will get "request timed out" ( here is how I see the situation:
packets
> > come to interface connected to ISP2 but are leaving on the interface
> > connected to ISP1; the Internet host receives ICMP echo reply from IP
> > address connected to ISP1 and not from that connected to ISP2, so it
does
> > not see that the host is alive - that's how I see the situation )
> > or
>
> This should be irrelevant. Something else is happening (like
> that network is filtering ICMP or some such.)
>
> There is no rule -- in fact NO GUARANTEE whatsoever -- that any
> IP packet will follow a particular route, just because the incoming packet
> did.
>
> > The packets (with source address being the IP address of the interface
> > connected to ISP2) are leaving on the interface connected to ISP1, but
> ISP1
> > has filering that do not allow packets coming from other networks exept
> > those that they own to pass through.
>
> Perfectly normal as long as that network supports the traffic.
>
> > Do you agree that one of the situation is present ?
> > and if this is the situation why packets aren't routed to the same
> interface
> > that received the request ? ( I think this is the main problem that
needs
> to
> > be troubleshooted )
>
> No.
>
> > thanks
> >
> > "Herb Martin" <news@LearnQuick.com> wrote in message
> > news:eD$pN6XAEHA.3004@TK2MSFTNGP10.phx.gbl...
> > > "Fatboyslimro" <fatboyslimro@hotmail.com> wrote in message
> > > news:uEz7JtTAEHA.580@TK2MSFTNGP11.phx.gbl...
> > > > thanks for the effort
> > > > OK let me try to be more specific
> > > > I have 2 Internet connections with different ISPs ( broadband cable
on
> > > each
> > > > connection ).
> > > > The primary goal is to provide complete visibility from Internet to
> our
> > > web
> > > > site through this 2 ISPs ( for redundancy )
> > >
> > > That part is easy, if you advertise (through DNS) both IP addresses.
> > > Note: this part is dependent on the requests.
> > > Of course, you will also have to configure the web sites to support
> > > both addresses but that is either automatic or trivial.
> > >
> > > > The secondary goal is to provide some kind of load balancing of the
> > total
> > > > Internet bandwidth for users on the LAN ( or better said to use both
> > > > Internet connections in the same time ).
> > >
> > > Not likely to work with Windows as the router. This is not an
> > > included feature.
> > >
> > > One of the folks here did write a script for SWITCHING the
> > > default gateway when one of the paths goes down, but that
> > > only provides redundancy.
> > >
> > > I played around with using the one of the (rather large, Roadrunner)
> > > ISPs address range in manual routes, 24.0.0.0/8 out through the
> > > Roadrunner and everything else out through the DSL.
> > >
> > > It did very minimal load "adjustment" (not good enough to call
> > > "balancing" <grin>)
> > >
> > > --
> > > Herb Martin
> > > > - Nic1 - LAN - IP address 192.168.0.1 - mask 255.255.255.0 - default
> GW
> > > > field empty
> > > > - Nic2 - WAN to ISP1 - IP address 194.1.2.3 - mask 255.255.255.0 -
> > default
> > > > GW 194.1.2.1 ( provided by the ISP1 )
> > > > - Nic3 - WAN to ISP2 - IP address 213.5.6.7 - mask 255.255.255.0 -
> > default
> > > > GW field empty
> > > > - IIS for the web site
> > > > - DNS for holding the adcdef.ro domain zone and for resolving DNS
> > queries
> > > > from users
> > > > - RRAS with NAT enabled ( all of the interfaces are present in the
NAT
> > > > configuration portion in IP Routing from RRAS snap-in )
> > > > - static routes for "load balancing" ( each static route is created
> with
> > > > "New static route..." option from Static Routes from RRAS snap-in,
> like
> > > > this: select the interface name Nic3 - WAN to ISP2, then Destination
> > > > 62.0.0.0., then Network Mask 255.0.0.0 and then the GW 213.5.6.1 -
> > > provided
> > > > by ISP2 )
> > > > - the routing table looks like this( Destination - Netmask -
Gateway -
> > > > Interface ):
> > > > 0.0.0.0 - 0.0.0.0 - 194.1.2.1 - 194.1.2.3
> > > > 62.0.0.0 - 255.0.0.0 - 213.5.6.1 - 213.5.6.7
> > > > 127.0.0.0 - 255.0.0.0 - 127.0.0.1 - 127.0.0.1
> > > > 192.168.0.0 - 255.255.255.0 - 192.168.0.1 - 192.168.0.1
> > > > 192.168.0.1 - 255.255.255.255 - 127.0.0.1 - 127.0.0.1
> > > > 192.168.0.255 - 255.255.255.255 - 192.168.0.1 - 192.168.0.1
> > > > 194.1.2.0 - 255.255.255.0 - 194.1.2.3 - 194.1.2.3
> > > > 194.1.2.3 - 255.255.255.255 - 127.0.0.1 - 127.0.0.1
> > > > 194.1.2.255 - 255.255.255.255 - 194.1.2.3 - 194.1.2.3
> > > > 213.5.6.0 - 255.255.255.0 - 213.5.6.7 - 213.5.6.7
> > > > 213.5.6.7 - 255.255.255.255 - 127.0.0.1 - 127.0.0.1
> > > > 213.5.6.255 - 255.255.255.255 - 213.5.6.7 - 213.5.6.7
> > > > 255.255.255.255 - 255.255.255.255 - 192.168.0.1 - 192.168.0.1
> > > > Default Gateway:194.1.2.1
> > > > Persistent Routes: None
> > > > I didn't mentioned all of the static routes that I use because they
> are
> > > the
> > > > same as the one earlier created ( and also I omitted the routes that
> > begin
> > > > with 224 ).
> > > > - complete visibility is a must as I have the 2 IP addresses
> registered
> > as
> > > > primary NS and secondary NS ( also in my DNS records host "www" is
> > > assigned
> > > > to both addresses) , and when a user from Internet tries to resolve
> > > > www.abcdef.ro if it gets the IP address that it cannot be pinged
from
> > that
> > > > location neither the web browsing to our web site will work ).
> > > > Testing:
> > > > pinging from an Internet host ( 202.1.1.1):
> > > > ping 194.1.2.3 --> ok
> > > > ping 213.5.6.7 --> request timed out
> > > >
> > > > pinging from another Internet host ( 62.1.1.1 ):
> > > > ping 194.1.2.3 --> request timed out
> > > > ping 213.5.6.7 --> ok
> > > > ( normally, if I remove the static route to 62... the request time
out
> > > will
> > > > be obtained by pinging 213.5.6.7 and ok if pinging 194.1.2.3)
> > > >
> > > > I think the situation is somthing like this: answers are not
returned
> on
> > > the
> > > > same interface that received the request ( but why ? ).
> > > > Hope there is enough information to troubleshoot.
> > > >
> > > >
> > > >
> > > > "Herb Martin" <news@LearnQuick.com> wrote in message
> > > > news:OP9kiSRAEHA.1212@TK2MSFTNGP12.phx.gbl...
> > > > > > I hope I've made myself understood.
> > > > >
> > > > > It's real hard to discover your PROBLEM in all the verbage.
> > > > > (Which may be important, but do try to put the problem first.)
> > > > >
> > > > > Several ideas: Use tracert to determine which paths are being
taken
> > > > > (Instead of simple ping.)
> > > > >
> > > > > Don't feel that every NIC must have a (different) default gateway.
> > > > > And if you do make them different, don't expect to guess the order
> > > > > without paying very careful attention to the BINDING order of the
> > > > > NICs.
> > > > > And if you do make them different, don't expect an automatic
> > > > > fail over unless the ADJACENT router fails completely (as opposed
> > > > > to something later in the path which is common with DSL and Cable
> > > > > modems.)
> > > > >
> > > > > > Is this a normal behavior in Windows 2000 Server or is this an
> issue
> > ?
> > > > > >
> > > > > > Here is the situation :
> > > > > >
> > > > > > - Windows 2000 Server sp4
> > > > > > - NIC1 LAN ( 192.168.x.x , default GW field empty)
> > > > > > - NIC2 WAN ( 194.x.x.y , default GW 194.x.x.1 )
> > > > > > - NIC3 WAN ( 213.x.x.z , default GW field empty)
> > > > > > - RRAS with NAT enabled
> > > > > > - no static routes
> > > > > > So, with this configuration the default route is set to
194.x.x.1
> > > > > > The visibility from Internet is as follows:
> > > > > > - pinging 194.x.x.y from any host ( any IP address ) the result
is
> > ok
> > > > > > - pinging 213.x.x.z from any host ( any IP address ) the result
is
> > > > > "Request timed out" !!!
> > > > > >
> > > > > > If I add to this configuration a static route on NIC3 with
> > destination
> > > > > 62.0.0.0 mask 255.0.0.0 the visibility from Internet is as
follows:
> > > > > > - pinging 194.x.x.y from a host with an IP address like 62.x.x.x
> the
> > > > > result is "Request timed out"
> > > > > > - pinging 213.x.x.z from a host with an IP address like 62.x.x.x
> the
> > > > > result is ok
> > > > > > - pinging 194.x.x.y from any host ( excepting 62.x.x.x like
> > address )
> > > > the
> > > > > result is ok
> > > > > > - pinging 213.x.x.z from any host ( excepting 62.x.x.x like
> > address )
> > > > the
> > > > > result is "Request timed out"
> > > > > >
> > > > > > If I make 213.x.x.1 the default GW on NIC3 ( and the static
route
> > also
> > > > in
> > > > > NIC3 ) the result is inversed.
> > > > > >
> > > > > > So I made up a "definition": The result from pinging a
multi-homed
> > > host
> > > > > with Windows 2000 Server OS will be ok only if you are pinging the
> IP
> >
> > > > > address that is the default way for your IP address from that
router
> > to
> > > > your
> > > > > host.
> > > > > >
> > > > > > I've posted a similar message on other forums and I've got an
> answer
> > > > that
> > > > > said that Windows 2000 Server doesn't use "source routing" that
will
> > > > resolve
> > > > > my problem ( and that Linux does use this feature ).
> > > > > > I didn't found anything about "source routing" and Windows 2000
> > > Server.
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Herb Martin
> > > > > >
> > > > > > thanks
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



Relevant Pages

  • Re: strange packets from 192.168.1.126
    ... external interface from the 192.168.1.0/24 network. ... local machines on this network and the packets are coming in on my WAN ... that is connected to the ISP, rather than a network under your (or ...
    (comp.security.firewalls)
  • RE: Running public IPs inside an RFC 1597 network
    ... > I'm running a typical Class C RFC 1597 network in my lab. ... know or care if we humans designate a subnet as public or private. ... is the absolute most general route there is for a machine. ... In a correctly configured system when you define an interface, ...
    (freebsd-questions)
  • Re: Nmap questions concering my router
    ... It's a bit off topic - but down at the Ethernet level, the packets are ... so your router masquerades for you. ... it may differ from other applications - we just send data to a network ... >> the Ethernet header is the MAC address of the 10.0.0.138 interface. ...
    (comp.security.firewalls)
  • Re: 2 Subnets on 1 Lan
    ... # Now add a route if you need it. ... have to add a route on any other machine in the 10.10.10.x network ... why not use the standard network configuration setup instead ... interface by using the route-eth0 form. ...
    (Fedora)
  • Re: interface bonding
    ... > account the new interface metrics. ... Hi Antoine, Gernot, and Brian! ... engineers do not improve products as fast as network engineers. ... a 1 MIPS computer was able to process packets on any ...
    (comp.unix.bsd.netbsd.misc)