Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG] - SCO

This is a discussion on Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG] - SCO ; First let me say I am sorry for the length of this but I wanted to provide as much info as possible. I have a client that has a Compaq system running SCO Unix 5.0.7 system in conjunction with a ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG]

  1. Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG]

    First let me say I am sorry for the length of this but I wanted to provide as
    much info as possible. I have a client that has a Compaq system running SCO
    Unix 5.0.7 system in conjunction with a Win2k System providing VPN access.

    #uname -X

    System = SCO_SV
    Node = theirnode
    Release = 3.2v5.0.7
    KernelID = 2003-02-18
    Machine = Xeon
    BusType = ISA
    Serial = XXXXXXXXXXX
    Users = 30
    OEM# = 0
    Origin# = 1
    NumCPU = 1

    The bulk of their processing is done via dumb terminal connections but they
    also have a few in-house workstations connected via ethernet and then DSL
    access via Windows VPN. There is a Netopia DSL modem, a Linksys DSL/Broadband
    hub (acting as a Hub, router and gateway), a Linksys wireless Access Point and
    a Windows 2000 system which is the VPN Server and also handles some DNS
    functions. The Windows 2k machine has 2 NICS - one classed as WAN and one as
    LAN but they are on the same subnet (as you will see). Our problem is that
    while the internal network connections all work flawlessly the connections via
    the VPN are really a hit and miss sort of thing. It always seems and my
    testing seems to confirm that we can get to the VPN server on the Win2k box and
    get an IP address (using DHCP via the VPN) but then we will only be able to
    ping the NIC cards the Win2k machine possesses or the Linksys routers (which we
    had to go through to get to the VPN Box anyways) but our access to the SCO Unix
    box will fail while trying to connect - pings will fail as well. As I say it
    is hit and miss - sometimes connecting to SCO works without a hitch but then
    others it seems there are either extensive pauses or no connect at all. It
    seems we can always see the Win2k machine and when attempting to reach the SCO
    machine if it fails - several attempts (full disconnect and reconnect) will
    ultimately get you in. It also seems as if we can ping one of the Win2k NIC but
    not the other - this I wonder as well if it is because they are on the same
    subnet.

    The entire network is currently setup to run on the 192.168.1. subnet but I
    have gotten several opinions and found some research indicating that for the
    entire network to be on the one subnet with the type configuration they have is
    a poor setup and that it should be broken into 2 or more subnets because of the
    VPN, the Wireless DHCP connections and the internal fixed IP addresses. The
    following network configuration and IP addresses will I think make this clear
    to many of you who are more network savvy than we are why we are into that
    thought process. We also found several Microsoft Knowledge Base articles which
    seem to confirm issues with VPN when used with DNS and DHCP on the same server
    in a Microsoft environment when all the devices are on the same subnet.

    The clients network configuration is as follows and except where noted (the VPN
    on the Win2k machine) all Network setup uses a netmask of 255.255.255.0:
    DSL line into Netopia/Cayman 3347W modem

    Ethernet from modem to Linksys BEFSR11 wired router (192.168.1.254) this is a
    two port device - one port for the WAN in and one for Ethernet out. Gateway
    mode, handles DHCP requests for the network (Range 192.168.1.100 for 50 ports)
    and also acts as DNS with its DNS set to itself.

    Ethernet from router to Linksys BEFW11S4 wireless router (192.168.1.250) This
    is a 4 port device - one port for the wan and 4 for ethernet. Gateway mode.
    DNS set to point to .254.

    Ethernet from wireless router to HPJ3289A hub

    SCO Unix machine (192.168.1.245) is connected to hub, Gateway set to .254 and
    uses resolv.conf for DNS and also pointing at .254.

    Both NICs on the Windows 2k machine connected to hub:
    192.168.1.252 LAN Uses a gateway of .254 but set to use itself for DNS.
    192.168.1.253 WAN Uses .254 for the Gateway and for DNS
    192.168.1.192 is the target IP for the VPN with a mask of 255.255.255.224 and
    the range of VPN IP addresses is from 192.168.1.200 to 192.168.1.219 with the
    200 being reserved for the VPN Server IP. I noticed the target IP in
    Microsoft VPN during a check of their configuration and after some research
    using various subnet calc programs it appears that that IP is chosen because it
    it the low address in the subnet range we requested for the VPN. It appears
    Windows bases the target IP and netmask on our selected range of a start and
    end of 192.168.1.200 to 192.168.1.219 - not sure why this is or how it impacts
    the setup but that is what it does and as I say the numbers do appear to
    coincide with making a small network (subnet) within the larger 192.168.1
    network.

    I am told that both the WAN and the LAN NIC on the same subnet is a problem and
    it makes sense to me why it would be - not sure why it was set up this way in
    the first place. I also imagine the LAN NIC set to use itself for DNS is
    probably also a problem and the VPN on the same subnet could also be confusing.

    My apologies but I honestly cannot remember which but one of the Linksys
    devices handles the port forwarding to get the VPN traffic to the Win2k machine
    as it needs to be but I know one is set for port forwarding and they are both
    capable.

    As I said at times you can access (IE Ping for testing ) the Linksys (.254) and
    one of the Windows WAN (.253) and LAN (.252) but you cannot get to the SCO
    Machine (.245) and then at times all is well. Now I have also been connected
    via the VPN when I cannot connect to the SCO machine and called someone on-site
    and had them ping the SCO machine from the Windows Server and the ping is
    successful so the Windows 2k machine and SCO Unix Machine are still talking but
    it appears the VPN is failing. Obviously I think the problem is with the VPN
    software and research of Microsoft Knowledge Base articles would seem to
    confirm that. There are several articles that reference Windows machines being
    the PDC and doing DNS and VPN and using a subnet within the existing subnet
    ("On Subnet"). According to Knowledge base article 171185 from Microsoft having
    an "On Subnet" Vpn is acceptable. It also mentions that this is commonly
    accomplished by letting VPN IP addresses be handed out using DHCP. However
    there also appears to be connection issues when the Windows server handling VPN
    is also a DNS server or the PDC (Primary Domain Controller). According to
    Microsoft Knowledge base articles 292822, 830063 and 289735 there have been
    various types of connection issues when the above is true. Among other
    suggestions (some involving the registry) there is also one advising to change
    the IP Static Address range for the VPN to an "Off Subnet" network. This is in
    some cases part of a larger fix and in one of the Articles it was actually an
    alternate fix.

    Two thoughts I had on eliminating some of the potential problem was 1) reassign
    the DHCP range to the 150 range or so and put the VPN below it at 100 or 50 or
    something and then we can reassign netmasks on the rest of the network so we
    end up with two subnets not one inside the other - all the dhcp and vpn on a
    low subnet and the servers on a high subnet. Since our servers and routers are
    at the high end this would allow two subnets but it would also require a
    netmask change on the SCO machine - that I am not thrilled with. 2) I had also
    thought about simply moving the VPN to say the 192.168.2.200 to 192.168.2.219
    subnet and see if that helps but then I am sure I will run into routing issues
    getting connections to and from the SCO Unix box to the VPN Connections since
    Windows will probably not handle the routing between its own VPN and its LAN
    NIC which would be on 192.168.1. I have also thought that in addition to that
    I would move the WAN NIC of the Windows machine and the Linksys Routers
    (actually only one and loose the other - we do not need them both) to the
    192.168.3 subnet but then that really compounds my routing issues as I will now
    have 3 subnets but my thoughts on this from what I have read is that this is
    the best way to go.

    I had thought I would attempt the VPN change first (#2 above) and then
    depending on the results I would consider (if still necessary) changing the WAN
    NIC and the Linksys Router and changing my routes and Gateways accordingly. I
    really am trying to stay away from mucking with the SCO IP addresses and
    netmask.

    I am hoping someone can offer some further insight as to the most appropriate
    changes to make and what routes I need or someplace I can go to research how
    you determine routes and then I would also like some discussion on their
    network setup as a whole and how to improve or eliminate these glitches.


    Thanks to all for any suggestions , insight, and info.

    bk


  2. Re: Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG]


    "Brian Keener" wrote in message
    news:VA.000012bd.007a2e42@thesoftwaresource.com...
    > First let me say I am sorry for the length of this but I wanted to provide

    as
    > much info as possible. I have a client that has a Compaq system running

    SCO
    > Unix 5.0.7 system in conjunction with a Win2k System providing VPN access.
    >
    > #uname -X
    >
    > System = SCO_SV
    > Node = theirnode
    > Release = 3.2v5.0.7
    > KernelID = 2003-02-18
    > Machine = Xeon
    > BusType = ISA
    > Serial = XXXXXXXXXXX
    > Users = 30
    > OEM# = 0
    > Origin# = 1
    > NumCPU = 1
    >
    > The bulk of their processing is done via dumb terminal connections but

    they
    > also have a few in-house workstations connected via ethernet and then DSL
    > access via Windows VPN. There is a Netopia DSL modem, a Linksys

    DSL/Broadband
    > hub (acting as a Hub, router and gateway), a Linksys wireless Access Point

    and
    > a Windows 2000 system which is the VPN Server and also handles some DNS
    > functions. The Windows 2k machine has 2 NICS - one classed as WAN and one

    as
    > LAN but they are on the same subnet (as you will see). Our problem is

    that
    > while the internal network connections all work flawlessly the connections

    via
    > the VPN are really a hit and miss sort of thing. It always seems and my
    > testing seems to confirm that we can get to the VPN server on the Win2k

    box and
    > get an IP address (using DHCP via the VPN) but then we will only be able

    to
    > ping the NIC cards the Win2k machine possesses or the Linksys routers

    (which we
    > had to go through to get to the VPN Box anyways) but our access to the SCO

    Unix
    > box will fail while trying to connect - pings will fail as well. As I say

    it
    > is hit and miss - sometimes connecting to SCO works without a hitch but

    then
    > others it seems there are either extensive pauses or no connect at all.

    It
    > seems we can always see the Win2k machine and when attempting to reach the

    SCO
    > machine if it fails - several attempts (full disconnect and reconnect)

    will
    > ultimately get you in. It also seems as if we can ping one of the Win2k

    NIC but
    > not the other - this I wonder as well if it is because they are on the

    same
    > subnet.
    >
    > The entire network is currently setup to run on the 192.168.1. subnet but

    I
    > have gotten several opinions and found some research indicating that for

    the
    > entire network to be on the one subnet with the type configuration they

    have is
    > a poor setup and that it should be broken into 2 or more subnets because

    of the
    > VPN, the Wireless DHCP connections and the internal fixed IP addresses.

    The
    > following network configuration and IP addresses will I think make this

    clear
    > to many of you who are more network savvy than we are why we are into that
    > thought process. We also found several Microsoft Knowledge Base articles

    which
    > seem to confirm issues with VPN when used with DNS and DHCP on the same

    server
    > in a Microsoft environment when all the devices are on the same subnet.
    >
    > The clients network configuration is as follows and except where noted

    (the VPN
    > on the Win2k machine) all Network setup uses a netmask of 255.255.255.0:
    > DSL line into Netopia/Cayman 3347W modem
    >
    > Ethernet from modem to Linksys BEFSR11 wired router (192.168.1.254) this

    is a
    > two port device - one port for the WAN in and one for Ethernet out.

    Gateway
    > mode, handles DHCP requests for the network (Range 192.168.1.100 for 50

    ports)
    > and also acts as DNS with its DNS set to itself.
    >
    > Ethernet from router to Linksys BEFW11S4 wireless router (192.168.1.250)

    This
    > is a 4 port device - one port for the wan and 4 for ethernet. Gateway

    mode.
    > DNS set to point to .254.
    >
    > Ethernet from wireless router to HPJ3289A hub
    >
    > SCO Unix machine (192.168.1.245) is connected to hub, Gateway set to .254

    and
    > uses resolv.conf for DNS and also pointing at .254.
    >
    > Both NICs on the Windows 2k machine connected to hub:
    > 192.168.1.252 LAN Uses a gateway of .254 but set to use itself for DNS.
    > 192.168.1.253 WAN Uses .254 for the Gateway and for DNS
    > 192.168.1.192 is the target IP for the VPN with a mask of 255.255.255.224

    and
    > the range of VPN IP addresses is from 192.168.1.200 to 192.168.1.219 with

    the
    > 200 being reserved for the VPN Server IP. I noticed the target IP in
    > Microsoft VPN during a check of their configuration and after some

    research
    > using various subnet calc programs it appears that that IP is chosen

    because it
    > it the low address in the subnet range we requested for the VPN. It

    appears
    > Windows bases the target IP and netmask on our selected range of a start

    and
    > end of 192.168.1.200 to 192.168.1.219 - not sure why this is or how it

    impacts
    > the setup but that is what it does and as I say the numbers do appear to
    > coincide with making a small network (subnet) within the larger 192.168.1
    > network.


    Try changing the subnet mask for the VPN to 255.255.255.0 .
    Now all VPN addresses will be able to reach any other address in 192.168.1.x
    ,
    assuming you've set that option on the Win2K VPN server.

    >
    > I am told that both the WAN and the LAN NIC on the same subnet is a

    problem and
    > it makes sense to me why it would be - not sure why it was set up this way

    in
    > the first place. I also imagine the LAN NIC set to use itself for DNS is
    > probably also a problem and the VPN on the same subnet could also be

    confusing.
    >
    > My apologies but I honestly cannot remember which but one of the Linksys
    > devices handles the port forwarding to get the VPN traffic to the Win2k

    machine
    > as it needs to be but I know one is set for port forwarding and they are

    both
    > capable.
    >
    > As I said at times you can access (IE Ping for testing ) the Linksys

    (.254) and
    > one of the Windows WAN (.253) and LAN (.252) but you cannot get to the SCO
    > Machine (.245) and then at times all is well. Now I have also been

    connected
    > via the VPN when I cannot connect to the SCO machine and called someone

    on-site
    > and had them ping the SCO machine from the Windows Server and the ping is
    > successful so the Windows 2k machine and SCO Unix Machine are still

    talking but
    > it appears the VPN is failing. Obviously I think the problem is with the

    VPN
    > software and research of Microsoft Knowledge Base articles would seem to
    > confirm that. There are several articles that reference Windows machines

    being
    > the PDC and doing DNS and VPN and using a subnet within the existing

    subnet
    > ("On Subnet"). According to Knowledge base article 171185 from Microsoft

    having
    > an "On Subnet" Vpn is acceptable. It also mentions that this is commonly
    > accomplished by letting VPN IP addresses be handed out using DHCP.

    However
    > there also appears to be connection issues when the Windows server

    handling VPN
    > is also a DNS server or the PDC (Primary Domain Controller). According to
    > Microsoft Knowledge base articles 292822, 830063 and 289735 there have

    been
    > various types of connection issues when the above is true. Among other
    > suggestions (some involving the registry) there is also one advising to

    change
    > the IP Static Address range for the VPN to an "Off Subnet" network. This

    is in
    > some cases part of a larger fix and in one of the Articles it was actually

    an
    > alternate fix.
    >
    > Two thoughts I had on eliminating some of the potential problem was 1)

    reassign
    > the DHCP range to the 150 range or so and put the VPN below it at 100 or

    50 or
    > something and then we can reassign netmasks on the rest of the network so

    we
    > end up with two subnets not one inside the other - all the dhcp and vpn on

    a
    > low subnet and the servers on a high subnet. Since our servers and

    routers are
    > at the high end this would allow two subnets but it would also require a
    > netmask change on the SCO machine - that I am not thrilled with. 2) I had

    also
    > thought about simply moving the VPN to say the 192.168.2.200 to

    192.168.2.219
    > subnet and see if that helps but then I am sure I will run into routing

    issues
    > getting connections to and from the SCO Unix box to the VPN Connections

    since
    > Windows will probably not handle the routing between its own VPN and its

    LAN
    > NIC which would be on 192.168.1. I have also thought that in addition to

    that
    > I would move the WAN NIC of the Windows machine and the Linksys Routers
    > (actually only one and loose the other - we do not need them both) to the
    > 192.168.3 subnet but then that really compounds my routing issues as I

    will now
    > have 3 subnets but my thoughts on this from what I have read is that this

    is
    > the best way to go.
    >
    > I had thought I would attempt the VPN change first (#2 above) and then
    > depending on the results I would consider (if still necessary) changing

    the WAN
    > NIC and the Linksys Router and changing my routes and Gateways

    accordingly. I
    > really am trying to stay away from mucking with the SCO IP addresses and
    > netmask.
    >
    > I am hoping someone can offer some further insight as to the most

    appropriate
    > changes to make and what routes I need or someplace I can go to research

    how
    > you determine routes and then I would also like some discussion on their
    > network setup as a whole and how to improve or eliminate these glitches.
    >
    >
    > Thanks to all for any suggestions , insight, and info.


    Bob



  3. Re: Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG]

    Bob Bailin wrote:
    > > the setup but that is what it does and as I say the numbers do appear to
    > > coincide with making a small network (subnet) within the larger 192.168.1
    > > network.

    >
    > Try changing the subnet mask for the VPN to 255.255.255.0 .
    > Now all VPN addresses will be able to reach any other address in 192.168.1.x
    > ,
    > assuming you've set that option on the Win2K VPN server.


    Once again Bob thanks for your assistance - I will try to get the customer to
    try this in the next day or so and be back in touch.

    bk


  4. Re: Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG]

    In article , Brian
    Keener wrote:

    >First let me say I am sorry for the length of this but I wanted
    >to provide as much info as possible. I have a client that has a
    >Compaq system running SCO Unix 5.0.7 system in conjunction with a
    >Win2k System providing VPN access.


    >#uname -X


    >System = SCO_SV
    >Node = theirnode
    >Release = 3.2v5.0.7
    >KernelID = 2003-02-18
    >Machine = Xeon
    >BusType = ISA
    >Serial = XXXXXXXXXXX
    >Users = 30
    >OEM# = 0
    >Origin# = 1
    >NumCPU = 1


    > The bulk of their processing is done via dumb terminal
    >connections but they also have a few in-house workstations
    >connected via ethernet and then DSL access via Windows VPN. There
    >is a Netopia DSL modem, a Linksys DSL/Broadband hub (acting as a
    >Hub, router and gateway), a Linksys wireless Access Point and a
    >Windows 2000 system which is the VPN Server and also handles some
    >DNS functions. The Windows 2k machine has 2 NICS - one classed as
    >WAN and one as LAN but they are on the same subnet (as you will
    >see). Our problem is that while the internal network connections
    >all work flawlessly the connections via the VPN are really a hit
    >and miss sort of thing. It always seems and my testing seems to
    >confirm that we can get to the VPN server on the Win2k box and
    >get an IP address (using DHCP via the VPN) but then we will only
    >be able to ping the NIC cards the Win2k machine possesses or the
    >Linksys routers (which we had to go through to get to the VPN
    >Box anyways) but our access to the SCO Unix box will fail while
    >trying to connect - pings will fail as well. As I say it is hit
    >and miss - sometimes connecting to SCO works without a hitch but
    >then others it seems there are either extensive pauses or no
    >connect at all. It seems we can always see the Win2k machine and
    >when attempting to reach the SCO machine if it fails - several
    >attempts (full disconnect and reconnect) will ultimately get you
    >in. It also seems as if we can ping one of the Win2k NIC but not
    >the other - this I wonder as well if it is because they are on
    >the same subnet.


    All of my comments will be SWAGs as it's sort of hard to envision
    everything. I'm a hands on type person :-)

    The first suggestion I'll make is to forget DHCP and go with static
    addresses. Or set your DHCP up to always give the servers the same
    IP addresses and the same for the routers.

    A brief story. I had a client [took them 4 years to migrate from
    SCO as their SW vendor couldn't get things working right].

    They were using a Netgear router setup so the owner and the office
    manager could come in and work on the machine on the weekend.

    However the company that processed all the prescriptions required
    a SonicWall - which they set up and sent to the client. Since the
    vendor bought it and shipped it to the client they couldn't even
    get Sonic help.

    But the SW vendor [ the one who couldn't seem to get the database
    converted as they couldn't seem to understand the concept of two
    companies in one database ] told them all they had to do was unplug
    the Sonic and plug in the Netgear.

    The problem was that on Monday nothing would work so they always
    restarted the SCO. [They eventually called me and I showed them you
    only had to stop/start TCP].

    THe problem is a server likes to hang onto it's MAC/IP mapping for
    awhile. Since the IP of both the Netgear and the Sonic were the
    same, there Netgear and SCO would get in sync by the time they
    needed to use it on the weekend, but on Monday when they swapped
    things out it wouldn't connect.

    It seems the company that recommended this did not understand that
    the IP address is used only to get the MAC address and that all
    communcation is MAC to MAC. So depending on how long the servers
    retain the mapping you can wait and wait and wait. On larger
    routers such as the old 7513 I used to maintain, the timeout
    on the arp=cache was 4 hours. This may seem excessive but it was
    designed to be an edge router and was capable of having 8 four-port
    ethernet connections, so you don't want to spend a lot of time
    expiring and refreshing the cache.

    Since you say that eventually things connect I suspect you are
    seeing the same thing that the above client did - that the old
    IP/MAC mapping is sticking around for awhile and when it finally
    expires then a broadcast looking for the IP will get the correct
    MAC address and put it in the apr tables.

    >The entire network is currently setup to run on the 192.168.1.
    >subnet but I have gotten several opinions and found some research
    >indicating that for the entire network to be on the one subnet
    >with the type configuration they have is a poor setup and that it
    >should be broken into 2 or more subnets because of the VPN, the
    >Wireless DHCP connections and the internal fixed IP addresses.


    You didn't say how machine are on your network. But beware of
    opions like that unless they can give you reasons why.

    I break one VPN in the middle only for convenience so that the top
    half goes out the VPN tunnel to another office about 100 miles
    away.

    They are all on the 192.168.1.0 block but the netmask is
    255.255.255.128 - so the far city is using IPs above
    192.168.1.130. One of the other cities is connected by a bridge.
    It is much closer so it is very convenient for someone to set up a
    machine in the local office and just have someone take it over on
    the next bi-weekly trip and plug it in.

    One thing to be aware of when splitting blocks with a netmask as
    above. Microsoft uses what they call a 'natural netmask' [I think
    they invented that bogus name] so that anthing in the block of
    256 address will be seen no matter what the netmask is. They may
    have changed that.

    When I was setting up fairly large networks with small allocated
    blocks so we knew where the machines were located - I could make a
    small block of 8 IPs [6 useable] on MS machines, and they would
    find the bottom address in the card in the Cisco. However all
    other devices - routers, MACs, etc., understood how masks
    worked and I'd have to lay aliases on top of the main NIC in the
    router with an address inside the 8-address block and use one of
    the 6 useable IPs as a gateway - which was aliased on the outgoing
    NIC.

    >The following network configuration and IP addresses will I
    >think make this clear to many of you who are more network savvy
    >than we are why we are into that thought process. We also found
    >several Microsoft Knowledge Base articles which seem to confirm
    >issues with VPN when used with DNS and DHCP on the same server
    >in a Microsoft environment when all the devices are on the same
    >subnet.


    That jibes with what I said above because MS does not handle
    the TCP/IP environment correctly. But if you forget DHCP and go
    static addressing your problems should disappear.

    I've seen more than one environment when DHCP was setup because it
    was 'easy' [a loose translation for "I don't know what the hell I'm
    doing so I'll let the SW do it all for me"]

    >The clients network configuration is as follows and except where
    >noted (the VPN on the Win2k machine) all Network setup uses a
    >netmask of 255.255.255.0: DSL line into Netopia/Cayman 3347W
    >modem


    >Ethernet from modem to Linksys BEFSR11 wired router
    >(192.168.1.254) this is a two port device - one port for the WAN
    >in and one for Ethernet out. Gateway mode, handles DHCP requests
    >for the network (Range 192.168.1.100 for 50 ports) and also acts
    >as DNS with its DNS set to itself.


    Are the main servers excluded from the DHCP?

    >Ethernet from router to Linksys BEFW11S4 wireless router
    >(192.168.1.250) This is a 4 port device - one port for the wan
    >and 4 for ethernet. Gateway mode. DNS set to point to .254.


    >Ethernet from wireless router to HPJ3289A hub


    >SCO Unix machine (192.168.1.245) is connected to hub, Gateway set
    >to .254 and uses resolv.conf for DNS and also pointing at .254.


    >Both NICs on the Windows 2k machine connected to hub:
    >192.168.1.252 LAN Uses a gateway of .254 but set to use itself
    >for DNS. 192.168.1.253 WAN Uses .254 for the Gateway and for
    >DNS 192.168.1.192 is the target IP for the VPN with a mask
    >of 255.255.255.224 and the range of VPN IP addresses is from
    >192.168.1.200 to 192.168.1.219 with the 200 being reserved for
    >the VPN Server IP.


    Why is the W2K machine using itself for DNS and not the .254
    address as all other machines are. Could the DNS in the machines
    not be consitant. That could cause problems.

    >I noticed the target IP in Microsoft VPN during a check of their
    >configuration and after some research using various subnet calc
    >programs it appears that that IP is chosen because it it the low
    >address in the subnet range we requested for the VPN. It appears
    >Windows bases the target IP and netmask on our selected range of
    >a start and end of 192.168.1.200 to 192.168.1.219 - not sure why
    >this is or how it impacts the setup but that is what it does and
    >as I say the numbers do appear to coincide with making a small
    >network (subnet) within the larger 192.168.1 network.


    I've given up trying to understand why MS does what they do.
    However setting the address to the lowest availabe IP is quite
    common. I always prefered that to the way others always use
    the highest IP. But that's just me.

    >I am told that both the WAN and the LAN NIC on the same subnet is
    >a problem and it makes sense to me why it would be - not sure why
    >it was set up this way in the first place.


    Yes that can be a problem. Particularly in light of what I said
    about about NS'es "natural netmask" that doesn't respect smaller
    masks. I've seen more than one system where I wondered what was
    going through someones mind when they set things up. Another
    client got a new HW support team who were going to set up remote
    video monitoring and they wanted the client to get rid of the
    SonicWall routers [with 24x7 support] for Linksys - as they new how
    to configure them.

    It reminds me of a quote I read to today when Pauline Kiel [film
    critic at the NYT at one time] was lecturing to a class at
    a well known southern university. "It's true that probably
    90 percent of the people in every profession are incompetent"
    From what I've seen at times, I could almost think that number was
    conservative.

    >I also imagine the LAN NIC set to use itself for DNS is probably
    >also a problem and the VPN on the same subnet could also be
    >confusing.


    I'd personally go for ONE DNS - so you can always check it's
    integrity.

    >My apologies but I honestly cannot remember which but one of
    >the Linksys devices handles the port forwarding to get the VPN
    >traffic to the Win2k machine as it needs to be but I know one is
    >set for port forwarding and they are both capable.


    >As I said at times you can access (IE Ping for testing ) the
    >Linksys (.254) and one of the Windows WAN (.253) and LAN (.252)
    >but you cannot get to the SCO Machine (.245) and then at times
    >all is well.


    That could go along with having more than one DNS and the DHCP.
    And jibes with my original story of swapping routers.

    >Now I have also been connected via the VPN when I cannot connect
    >to the SCO machine and called someone on-site and had them
    >ping the SCO machine from the Windows Server and the ping is
    >successful so the Windows 2k machine and SCO Unix Machine are
    >still talking but it appears the VPN is failing.


    That to me is an indication that the VPN has the wrong IP/MAC
    mapping And it oculd be the result of too many DNS servers.

    ....

    >Two thoughts I had on eliminating some of the potential problem
    >was 1) reassign the DHCP range to the 150 range or so and put the
    >VPN below it at 100 or 50 or something and then we can reassign
    >netmasks on the rest of the network so we end up with two subnets
    >not one inside the other - all the dhcp and vpn on a low subnet
    >and the servers on a high subnet.


    From my comment on MS not honoring subnets properly that may not
    help. I don't know if MS has fixed it but that's the way it used
    to be.

    ....

    >I am hoping someone can offer some further insight as to the most
    >appropriate changes to make and what routes I need or someplace I
    >can go to research how you determine routes and then I would also
    >like some discussion on their network setup as a whole and how to
    >improve or eliminate these glitches.


    To reiterate - my first thought is to get only one DNS running if
    at all possible.

    Sorry for rambling on - but as others know - that's my style :-)

    Bill

    --
    Bill Vermillion - bv @ wjv . com

  5. Re: Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG]

    Bill Vermillion wrote:
    > All of my comments will be SWAGs as it's sort of hard to envision
    > everything. I'm a hands on type person :-)


    I understand completely - SWAG's are perfectly acceptable and it is hard to
    picture - I've seen it several times and still had to get them to confirm a
    couple things for me even though I had it diagramed notes. And its real hard
    to explain visually.

    > The first suggestion I'll make is to forget DHCP and go with static
    > addresses. Or set your DHCP up to always give the servers the same
    > IP addresses and the same for the routers.


    I'll go ahhead and answer one question here - yes all the servers have fixed IP
    addresses, some/all of the workstations that connect via Ethernet also now have
    fixed IP, same with the Linksys devices as well. Only thing that currently use
    DHCP would be some workstation via ethernet or a wireless connection and then
    the VPN connections using the VPN server and its IP range.

    > I've seen more than one environment when DHCP was setup because it
    > was 'easy' [a loose translation for "I don't know what the hell I'm
    > doing so I'll let the SW do it all for me"]


    ditto

    > >Both NICs on the Windows 2k machine connected to hub:
    > >192.168.1.252 LAN Uses a gateway of .254 but set to use itself
    > >for DNS. 192.168.1.253 WAN Uses .254 for the Gateway and for
    > >DNS 192.168.1.192 is the target IP for the VPN with a mask
    > >of 255.255.255.224 and the range of VPN IP addresses is from
    > >192.168.1.200 to 192.168.1.219 with the 200 being reserved for
    > >the VPN Server IP.

    >
    > Why is the W2K machine using itself for DNS and not the .254
    > address as all other machines are. Could the DNS in the machines
    > not be consitant. That could cause problems.


    That was one of my concerns as well and with the way they are cabled and to be
    on the same subnet and then one is supposed to be a WAN and one a LAN
    connection they really blow my mind.

    > It reminds me of a quote I read to today when Pauline Kiel [film
    > critic at the NYT at one time] was lecturing to a class at
    > a well known southern university. "It's true that probably
    > 90 percent of the people in every profession are incompetent"
    > From what I've seen at times, I could almost think that number was
    > conservative.


    ditto

    > >I also imagine the LAN NIC set to use itself for DNS is probably
    > >also a problem and the VPN on the same subnet could also be
    > >confusing.

    >
    > I'd personally go for ONE DNS - so you can always check it's
    > integrity.


    I can do that - I thought about doing it last time I was looking at it but got
    cold feet. Their network does work although not as well as it should

    > To reiterate - my first thought is to get only one DNS running if
    > at all possible.


    I can do that.

    > Sorry for rambling on - but as others know - that's my style :-)


    I am grateful for the input - your not rambling to me.


  6. Re: Win2k Ras/VPN and a SCO Unix Machine and some difficulty getting to the SCO Machine [LONG]

    In article ,
    Brian Keener wrote:
    >Bill Vermillion wrote:
    >> All of my comments will be SWAGs as it's sort of hard to envision
    >> everything. I'm a hands on type person :-)


    >I understand completely - SWAG's are perfectly acceptable and it
    >is hard to picture - I've seen it several times and still had to
    >get them to confirm a couple things for me even though I had it
    >diagramed notes. And its real hard to explain visually.


    [ huge hunks deleted - wjv]


    >> Why is the W2K machine using itself for DNS and not the .254
    >> address as all other machines are. Could the DNS in the machines
    >> not be consitant. That could cause problems.


    >That was one of my concerns as well and with the way they are
    >cabled and to be on the same subnet and then one is supposed to
    >be a WAN and one a LAN connection they really blow my mind.


    I've seen some bizarre things too. But everything is working at
    times - so the cabling should be OK.

    I run a pair of name-servers for a small ISP. On my machine I use
    to access the net I put those in first position in the resolver
    files. I trust them. But I also have 4 other DNS machines
    in there, so I can just comment out mine to test with others.
    I've also been known to ssh into a client machine to check.

    When someone has a connectivity problem I'll perform lookups
    through my servers, Sprint/Earthlink servers, and one client's
    RoadRunner servers.

    I've found inconsistancies among them - such as some not being
    updated correctly - and others being reachable through one
    connection and not another. So that's why I suggest
    one DNS.

    When you have problems why not perform a lookup using first one
    server, and then use the other DNS server.

    I also am conservative on my name servers - even though one is
    listed as a secondary I really have two primaries.

    I do this so that when I add or change things, I can restart one
    and make sure things are OK, and then I'll just send the files to
    the other machine. If I had the second as a secondary then any
    error on the primary will get proagated to the secondary and then
    nothing works.

    This scenario has been seen when major tranport providers upgrade
    their routers all at one time, and the entrie network falls over.

    The ONLY time I had a problem was when one of our clients who had
    about 1000 domains he was serving wanted a name added for a site
    that had a European registrar - and when they tested they found
    that my secondary was not a true secondary so they wouldn't point
    to our DNS. Since the client was selling $9.95 sites he just
    blew that one off.

    ...

    >> I'd personally go for ONE DNS - so you can always check it's
    >> integrity.


    >I can do that - I thought about doing it last time I was looking
    >at it but got cold feet. Their network does work although not as
    >well as it should


    Depending on what you use to test with it's easy to point to
    another NS. If you use a Unix system it's just a matter of
    commenting out the nameserver line and trying again. Testing via
    the MS way takes a bit more effort.

    Bill

    --
    Bill Vermillion - bv @ wjv . com

+ Reply to Thread