3-site VPN implementation w/Terminal Server

Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

Hello,

I am a catch-all IT consultant in Southern California with very little
practical VPN experience (but learning quickly). I am therefore
seeking guidance and affirmation from the gurus in this forum, if you
would be so kind.

I have a client with a small medical practice who would like to
consolidate his patient data into one location. He has 3 sites (2
medical offices, 1 billing office), each with their own self-contained
instances of 2 core DB apps. Each site has their own LAN, workgroup,
router, and DSL Service of varying speeds/equipment. The medical
offices have 9 total users (4 and 5, respectively), while the billing
office has only 3. All client PCs have either XP Pro SP2 or XP Home
SP2. There are no "servers", only workstations hosting the DB data over
standard file sharing.

Office growth has reached a plateau; there is no anticipated user
increase for the forseeable future. Money is always a factor, but I
have been told that special consideration can be made for an
"appropriate" price/performance solution. The main goal is to
consolidate the patient data from all 3 sites into 1 central location
so that all users are viewing the same tables. The DB app support
techs will perform the data merges, I need to design and implement the
infrastructure.

My proposal:
- 12 total users (5,4,2)
- the 5 user site becomes the "HQ"
- New Windows 2003 Domain Controller at HQ site will host the
consolidated DB Data and MS License server
- New Windows 2003 Terminal Server at HQ site will host the 2 DB apps
- Standardize all 3 sites to highest ADSL Service w/static IP
addressing
(SBC Yahoo!® DSL Pro-S -
Speed: 1.5-3.0Mbps downstream/384-512Kbps upstream
IP Address: 5 Static
Price: $74.99/mo)
- Standardize all 3 sites to same make/model of VPN router
- Establish tunnels into the HQ site from the 2 other sites (non-mesh)
- All clients will access the 2 DB apps on the Terminal Server at HQ
Site via RDP

VPN Questions:

1) After reading posts here and elsewhere, I am inclined to go with 3
Netopia VPN Routers, either 3386-ENT or 3387WG-ENT (the doctors have
wireless laptops). Will this hardware be sufficient to provide a
reliable connection between the sites? Anyone have any other
recommendations?

2) Will this ISP package be sufficient or will we need something
beefier (SDSL,T1, etc)?

General Questions:

3) As far as the beefiness of the servers, I am inclined to go heavier
on the Terminal server (2P, 2G RAM) than on the DC (1P 1G RAM), given
their required tasks. Am I making the correct assumptions?

4) Are there any "gotchas" I need to keep in mind? Is there a better
arrangement for this type of situation?

Any insight would be greatly appreciated.

Thanks,

-Vince
13 answers Last reply
More about site implementation terminal server
  1. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Vince wrote:
    > Hello,
    >
    > I am a catch-all IT consultant in Southern California with very little
    > practical VPN experience (but learning quickly). I am therefore
    > seeking guidance and affirmation from the gurus in this forum, if you
    > would be so kind.
    >
    > I have a client with a small medical practice who would like to
    > consolidate his patient data into one location. He has 3 sites (2
    > medical offices, 1 billing office), each with their own self-contained
    > instances of 2 core DB apps. Each site has their own LAN, workgroup,
    > router, and DSL Service of varying speeds/equipment. The medical
    > offices have 9 total users (4 and 5, respectively), while the billing
    > office has only 3. All client PCs have either XP Pro SP2 or XP Home
    > SP2. There are no "servers", only workstations hosting the DB data over
    > standard file sharing.
    >
    > Office growth has reached a plateau; there is no anticipated user
    > increase for the forseeable future. Money is always a factor, but I
    > have been told that special consideration can be made for an
    > "appropriate" price/performance solution. The main goal is to
    > consolidate the patient data from all 3 sites into 1 central location
    > so that all users are viewing the same tables. The DB app support
    > techs will perform the data merges, I need to design and implement the
    > infrastructure.
    >
    > My proposal:
    > - 12 total users (5,4,2)
    > - the 5 user site becomes the "HQ"
    > - New Windows 2003 Domain Controller at HQ site will host the
    > consolidated DB Data and MS License server
    > - New Windows 2003 Terminal Server at HQ site will host the 2 DB apps
    > - Standardize all 3 sites to highest ADSL Service w/static IP
    > addressing
    > (SBC Yahoo!® DSL Pro-S -
    > Speed: 1.5-3.0Mbps downstream/384-512Kbps upstream
    > IP Address: 5 Static
    > Price: $74.99/mo)
    > - Standardize all 3 sites to same make/model of VPN router
    > - Establish tunnels into the HQ site from the 2 other sites (non-mesh)
    > - All clients will access the 2 DB apps on the Terminal Server at HQ
    > Site via RDP
    >
    > VPN Questions:
    >
    > 1) After reading posts here and elsewhere, I am inclined to go with 3
    > Netopia VPN Routers, either 3386-ENT or 3387WG-ENT (the doctors have
    > wireless laptops). Will this hardware be sufficient to provide a
    > reliable connection between the sites? Anyone have any other
    > recommendations?
    >
    > 2) Will this ISP package be sufficient or will we need something
    > beefier (SDSL,T1, etc)?
    >
    > General Questions:
    >
    > 3) As far as the beefiness of the servers, I am inclined to go heavier
    > on the Terminal server (2P, 2G RAM) than on the DC (1P 1G RAM), given
    > their required tasks. Am I making the correct assumptions?
    >
    > 4) Are there any "gotchas" I need to keep in mind? Is there a better
    > arrangement for this type of situation?
    >
    > Any insight would be greatly appreciated.
    >
    > Thanks,
    >
    > -Vince
    >

    Looks fine. The connection speeds should be fine for terminal services
    and the number of users. If you wanted a bit more sophistication you
    could consider Citrix Presentation server on top of plain terminal
    services but there is not likely any critical reason why you would need
    to use Citrix PS.

    Gotchas that you need to consider are communication backup in case the
    ADSL links go down. For some people that simply means delaying data
    entry until it's back online, for others that may mean having some
    modems available to do an ad hoc dial-in on either a dedicated phone
    line or by stealing a line from a fax machine somewhere when required.
    I'm guessing that SBC doesn't exactly run to the rescue as soon as you
    call them with a problem so you need to expect that in a bad case you
    could be down for over a week.


    --
    WARNING! Email address has been altered for spam resistance.
    Please remove the -deletethispart-. section before replying directly.
    Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)
  2. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Hi,

    Just based on the information you have provided, I think you
    could simplify to something like this:

    - 1 Server at HQ site performing all functions

    - no VPN, just low-cost router/firewalls

    - Dynamic ips at remote sites if it saves substantial amount
    per month, and depending on security needs. For example,
    Verizon DSL is only $29.95/month for the speed you
    mention w/dynamic ip, but is $79.95/month for same speed
    with static ip, maybe SBC has similar pricing?

    - If printing is very heavy or graphicly intense at the remote
    offices, you may need more outgoing bandwidth at the HQ
    location, and/or a universal printer software package that
    helps cut down on the size of each print job.

    Now, I'll explain reasons why I suggest the above:

    1. Higher performance--you mentioned the app uses standard
    file sharing, so it would run faster if the files were being accessed
    directly on the server instead of on a separate file server like
    you proposed. The difference is usually VERY noticable when
    running reports, but also can speed data entry, depending on the
    application.

    2. Lower cost--obviously, only one server is necessary so the
    hardware and software costs are much lower. The ongoing
    maintenance costs are lower as well, because there is only one
    server to maintain.

    3. A single server can EASILY handle the workload for what
    you are describing, plus much more.

    One question I have for you is what is the primary reason
    for a VPN? Are you planning on having the workstations in
    the remote office authenticate to the domain, over a
    [relatively] slow connection to the HQ DC? I wouldn't think
    you would want this because the traffic would slow your TS
    connections, slow logons for remote local logons, etc.

    Is there some other need for the VPN?

    If you are concerned about preventing someone who is not physically
    located in one of the offices to connect via TS, you could set the
    firewall to only allow certain ips. The TS connection is already
    fully encrypted.

    Please let me know if you have any questions.

    Thanks.

    -TP

    Vince wrote:
    > Hello,
    >
    > I am a catch-all IT consultant in Southern California with very little
    > practical VPN experience (but learning quickly). I am therefore
    > seeking guidance and affirmation from the gurus in this forum, if you
    > would be so kind.
    >
    > I have a client with a small medical practice who would like to
    > consolidate his patient data into one location. He has 3 sites (2
    > medical offices, 1 billing office), each with their own self-contained
    > instances of 2 core DB apps. Each site has their own LAN, workgroup,
    > router, and DSL Service of varying speeds/equipment. The medical
    > offices have 9 total users (4 and 5, respectively), while the billing
    > office has only 3. All client PCs have either XP Pro SP2 or XP Home
    > SP2. There are no "servers", only workstations hosting the DB data
    > over standard file sharing.
    >
    > Office growth has reached a plateau; there is no anticipated user
    > increase for the forseeable future. Money is always a factor, but I
    > have been told that special consideration can be made for an
    > "appropriate" price/performance solution. The main goal is to
    > consolidate the patient data from all 3 sites into 1 central location
    > so that all users are viewing the same tables. The DB app support
    > techs will perform the data merges, I need to design and implement the
    > infrastructure.
    >
    > My proposal:
    > - 12 total users (5,4,2)
    > - the 5 user site becomes the "HQ"
    > - New Windows 2003 Domain Controller at HQ site will host the
    > consolidated DB Data and MS License server
    > - New Windows 2003 Terminal Server at HQ site will host the 2 DB apps
    > - Standardize all 3 sites to highest ADSL Service w/static IP
    > addressing
    > (SBC Yahoo!® DSL Pro-S -
    > Speed: 1.5-3.0Mbps downstream/384-512Kbps upstream
    > IP Address: 5 Static
    > Price: $74.99/mo)
    > - Standardize all 3 sites to same make/model of VPN router
    > - Establish tunnels into the HQ site from the 2 other sites (non-mesh)
    > - All clients will access the 2 DB apps on the Terminal Server at HQ
    > Site via RDP
    >
    > VPN Questions:
    >
    > 1) After reading posts here and elsewhere, I am inclined to go with 3
    > Netopia VPN Routers, either 3386-ENT or 3387WG-ENT (the doctors have
    > wireless laptops). Will this hardware be sufficient to provide a
    > reliable connection between the sites? Anyone have any other
    > recommendations?
    >
    > 2) Will this ISP package be sufficient or will we need something
    > beefier (SDSL,T1, etc)?
    >
    > General Questions:
    >
    > 3) As far as the beefiness of the servers, I am inclined to go heavier
    > on the Terminal server (2P, 2G RAM) than on the DC (1P 1G RAM), given
    > their required tasks. Am I making the correct assumptions?
    >
    > 4) Are there any "gotchas" I need to keep in mind? Is there a better
    > arrangement for this type of situation?
    >
    > Any insight would be greatly appreciated.
    >
    > Thanks,
    >
    > -Vince
  3. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    TP and Mike D.,

    Thanks for the suggestions. I was actually considering scaling down to
    1 beefier server, given the anticipated number of users.

    I might need to clarify the current file sharing aspects: the Apps in
    question are 1) custom FileMaker Pro app, running on v.5., and 2) NDC
    Medisoft v.8. Network ed. The XP workstations hosting the FileMaker
    Pro app's data are using FileMaker's "server" capabilities to advertise
    its availability over the network. The same applies to the XP
    workstations hosting Medisoft's "Advantage" DB. I'm not sure of the
    overhead impact, but they are currently running on 1P 2.x Ghz P4's
    which are also full-time workstations, with acceptable performance.

    If a single Dell PowerEdge 2P box w/2G RAM can handle all functions, I
    am inclined to go that route.

    TP, to answer your question on VPN, the purpose would be HIPAA
    compliance for transmitting patient data over a network. Might be
    overkill, but I thought it would be better to have too much than too
    little. I was not planning on doing any domain authentication other
    than the user's RDP connection, no local logon authentication, (if
    that's even possible - I'm an AD/TS noob, but reading like crazy).

    What do you think? Am I still in the ballpark?
  4. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Mike D., hopefully you can answer this one for me:

    I received 1 of my 3 Netopia 3386-ENT routers yesterday (2 are
    backordered - they seem to be constrained right now), and I'm digesting
    the documentation and familiarizing myself with the telnet interface. I
    have a question about the IPSec w/IKE configuration. In Netopia's
    documentation, they "strongly" recommend have the "VPN accelerator card
    option" if I choose 3DES instead of DES for the encryption. I assume
    this was in reference to the older R-series routers which had that
    option. My question is, what can I expect to lose as far as
    performance if I go with 3DES, given that the 3386 doesn't have the
    built-in accelerator like the 4000 series? Is the gain in security
    enough to justify the drop in performance? (I know my mileage will
    vary, I'm more interested in the experience of others - keep in mind it
    will be primarily RDP traffic passing over the VPN links)

    As always, any insight is appreciated.
  5. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Mike,

    Thanks for the feedback. I will setup the IPSEC w/3DES as soon as I
    get the other routers and report back.

    You mentioned that the DES keys are changed when the phase 1 connection
    is renegotiated. If I have a persistent 24-hour scheduled connection
    for the tunnel, would the phase 1 keys theoretically not change until
    it was "bounced" by external factors (power, ISP burp etc.) ?
  6. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Vince wrote:
    > Mike D., hopefully you can answer this one for me:
    >
    > I received 1 of my 3 Netopia 3386-ENT routers yesterday (2 are
    > backordered - they seem to be constrained right now), and I'm digesting
    > the documentation and familiarizing myself with the telnet interface. I
    > have a question about the IPSec w/IKE configuration. In Netopia's
    > documentation, they "strongly" recommend have the "VPN accelerator card
    > option" if I choose 3DES instead of DES for the encryption. I assume
    > this was in reference to the older R-series routers which had that
    > option. My question is, what can I expect to lose as far as
    > performance if I go with 3DES, given that the 3386 doesn't have the
    > built-in accelerator like the 4000 series? Is the gain in security
    > enough to justify the drop in performance? (I know my mileage will
    > vary, I'm more interested in the experience of others - keep in mind it
    > will be primarily RDP traffic passing over the VPN links)
    >
    > As always, any insight is appreciated.

    It's not likely that you would see a drop in performance at all
    depending on how fast your WAN connection is. For most cable and DSL
    speed connections the unit is able to encrypt data faster than the
    upstream WAN speed of the connection.

    The manuals are obviously adapted from the original R series. That's
    where the incorrect info is coming from.

    Your connection would be safe from low level attack with just DES but it
    is not great. A hacker could spend the time to crack this level of
    encryption with brute force methods though I do not know of any easily
    automated tools to do this against IPSEC sessions so you would not
    likely see a widespread level of attack. It would require someone very
    dedicated and knowledgable with a very clear desire to breach the
    communications systems of your network. The time element for a hacker
    to breach this level of encryption is measured in weeks with standard
    equipment and days with specialized equipment such as the DES cracker
    hardware build by the EFF for the RSA DES challenge:
    http://www.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/

    Even though the RDP protocol is encrypted, I don't this it would help
    slow a hackers ability to decrypt a DES packet. They would likely look
    for TCP Header information to tell if they have guessed the correct key.

    One other point. The way that IPSEC works, there are actually 2
    separate encryptions happening. The phase 1 connection is made with
    slightly different encryption algorithms, this layer of encryption is
    slower to process so they just use it to exchange symetric DES keys
    which can be encrypted and decrypted faster for the phase 2 connection.
    The hacker would need to know the encryption key for the phase 1
    transaction to be able to establish a new spoofed connection. Just
    knowing the DES key would give him the ability to decrypt packets in
    that particular session but when the phase 1 connected is renegotiated,
    those keys are changed.


    --
    WARNING! Email address has been altered for spam resistance.
    Please remove the -deletethispart-. section before replying directly.
    Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)
  7. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Vince wrote:
    > Mike,
    >
    > Thanks for the feedback. I will setup the IPSEC w/3DES as soon as I
    > get the other routers and report back.
    >
    > You mentioned that the DES keys are changed when the phase 1 connection
    > is renegotiated. If I have a persistent 24-hour scheduled connection
    > for the tunnel, would the phase 1 keys theoretically not change until
    > it was "bounced" by external factors (power, ISP burp etc.) ?
    >

    There is a setting in the Phase 1 configuration that will determine the
    length of time or amount of data before a rekey event. Default settings
    are for 28800 seconds and no data amount restriction. It's in the
    advanced IKE Phase 1 options screen. I cannot remember exactly, but I
    believe that the keys are renegotiated sometime before they actually
    expire similar to a DHCP lease, since this would be disruptive to the
    link if it waited until the limits. There is a preference to use the
    new security association (key) immediately after it's established or to
    wait until the old one expires. I don't know that it makes much
    difference except in the case where you are trying to tweak a connection
    between the routers of two different manufacturers.


    --
    WARNING! Email address has been altered for spam resistance.
    Please remove the -deletethispart-. section before replying directly.
    Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)
  8. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    I am having a serious problem with my 3-site VPN configuration. For
    some reason, even though the IPSec tunnels are created, I can't ping
    addresses on the remote subnets.

    All sites are using ADSL, w/fixed IP addresses, although 2 sites have
    underlying PPPOE encapsulation.

    Each site is using a Netopia 3386-ENT router w/latest Firmware (8.5).
    No firewall filter sets (perhaps this is an issue?). 3DES IPSec IKE
    tunnels config'd in mesh between sites.

    The computers at each site connect fine to the Internet; the routers
    are using the first fixed IP of the ISP-provided address range, NAT'ing
    for all hosts behind the router. It _appears_ that the IPSec tunnels
    pass IKE Phase 2 negotiation, as indicated by my "WAN Event History"
    log, but for some reason, I cannot ping the remote routers' IP
    addresses or any other active IP hosts on the remote subnets. The
    bizarre thing is, when I setup sites A and B with the IPSec tunnels, I
    experienced the same symptoms (no IP pingability across the tunnel) for
    about 3 hours, then all of a sudden, traffic was moving fine (hosts
    were pingable between the 2 sites, rdp session established across the
    VPN). Great! Or so I thought. It remained fine overnight. The next
    day, when I attempted to create the mesh tunnelling to site C, IP
    traffic stopped passing through the tunnels between sites A and B. Now
    I have all 3 sites telling me that the IPSec tunnels are created, but I
    can't get any traffic to travel across them. I've got the tunnels
    "nailed" w/Timeouts of 0 and 24-hour "scheduled" connections.

    Here is the router status info from site B (actual fixed IPs masked for
    my protection):

    Quick View

    Default IP Gateway: 71.138.2xx.xx
    Primary DNS Server: 206.13.29.12 Gateway installed -- Primary
    Secondary DNS Server: 206.13.30.12 Domain Name: sbcglobal.net

    ----------------MAC Address--------IP
    Address-------Status--------------------
    Ethernet LAN: 00-0f-cc-20-6b-f4 192.168.1.1
    Ethernet WAN1: 00-0f-cc-20-6b-f6 71.138.2xx.xx 100Mbps Full Duplex


    Current WAN Connection Status
    Profile Name--------Rate------%Use--Remote Address-----Est-More
    Info----------
    Easy Setup Profile IP 127.0.0.2 Lsd NAT
    71.138.2xx.xx


    VPN QuickView
    LED Status
    -PWR---------WAN Link
    ---------------ETHERNET-----------+--------LEDS---------
    1 2 3 4 | '-'= Off
    'G'= Green
    G G G G G G | 'R'= Red
    'F'= Flash


    VPN Quick View

    Profile Name----------Type----Rx Pckts---Tx Pckts--RxDiscard--Remote
    Address--
    Easy Setup Profile PPPoE 2029 1782 347
    127.0.0.2
    BtoA IPsec 26 451 0
    71.138.1xx.xx
    BtoC IPsec 61 0 0
    66.125.3x.xx


    WAN Event History
    Current Date -- 9/25/05
    04:56:35 PM

    -Date-----Time-----Event------------------------------------------------------
    ----------------------------------SCROLL
    UP-----------------------------------
    09/25/05 16:56:32 IKE: phase 2 complete sg 66.125.3x,xx
    09/25/05 16:55:30 IKE: phase 2 complete sg 71.138.1xx.xx
    09/25/05 16:54:25 IKE: phase 2 complete sg 66.125.3x.xx
    09/25/05 16:53:59 IKE: phase 2 complete sg 71.138.1xx.xx
    09/25/05 16:53:32 IKE: phase 2 complete sg 66.125.3x,xx
    09/25/05 16:53:26 IKE: phase 2 complete sg 66.125.3x.xx
    09/25/05 16:52:49 IKE: phase 2 complete sg 71.138.1xx.xx
    09/25/05 16:52:46 IKE: phase 2 complete sg 66.125.3x.xx
    09/25/05 16:52:32 IKE: phase 2 complete sg 66.125.3x.xx
    09/25/05 16:52:30 IKE: phase 2 complete sg 71.138.1xx.xx
    09/25/05 16:52:25 IKE: phase 2 complete sg 66.125.3x.xx
    09/25/05 16:52:23 IKE: phase 2 complete sg 66.125.3x.xx
    09/25/05 16:52:20 IKE: phase 2 complete sg 66.125.3x.xx
    09/25/05 16:52:19 IKE: phase 2 complete sg 66.125.3x.xx
    ---------------------------------SCROLL
    DOWN----------------------------------
    Clear History...

    (Should the phase 2 re-negotiation take place so frequently?)


    Here's the IPSec tunnel info:

    Site A
    IPSec TunnelA-B
    Local Subnet: 192.168.0.0
    Local SNM: 255.255.255.0
    Remote Subnet: 192.168.1.0
    Remote SNM: 255.255.255.0
    Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site B static ip)

    IPSec TunnelA-C
    Local Subnet: 192.168.0.0
    Local SNM: 255.255.255.0
    Remote Subnet: 192.168.2.0
    Remote SNM: 255.255.255.0
    Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site C static ip)

    Site B
    IPSec TunnelB-A
    Local Subnet: 192.168.1.0
    Local SNM: 255.255.255.0
    Remote Subnet: 192.168.0.0
    Remote SNM: 255.255.255.0
    Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site A static ip)

    IPSec TunnelB-C
    Local Subnet: 192.168.1.0
    Local SNM: 255.255.255.0
    Remote Subnet: 192.168.2.0
    Remote SNM: 255.255.255.0
    Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site C static ip)

    Site C
    IPSec TunnelC-A
    Local Subnet: 192.168.2.0
    Local SNM: 255.255.255.0
    Remote Subnet: 192.168.0.0
    Remote SNM: 255.255.255.0
    Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site A static ip)

    IPSec TunnelC-B
    Local Subnet: 192.168.2.0
    Local SNM: 255.255.255.0
    Remote Subnet: 192.168.1.0
    Remote SNM: 255.255.255.0
    Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site B static ip)

    If anyone can offer insight to my dilemma (paging Mike Dreschler....),
    I would greatly appreciate any

    help you can provide.

    Please let me know if I need to post more info about my config's.

    Thanks in advance,

    Vince
  9. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Mike,

    Thanks for the reply. All routers ahve the same settings for the
    Advanced IPSec Options:
    Advanced IPsec Options

    SA Lifetime seconds: 28800
    SA Lifetime Kbytes: 0
    Perfect Forward Secrecy: Yes
    Dead Peer Detection: No
    Maximum Packet Size: 1500

    These are the defaults, I did not alter them at all during setup.
    Should I alter them, or toggle Dead Peer Detection and have it ping the
    remote router LAN IP's?

    (From Firmware 8.5 user guide -
    Note:
    · ICMP Dead Peer Detection is not available when using manual
    re-keying.
    · ICMP Dead Peer Detection does not initiate a series of phase 2
    exchanges instead initiates a new phase 1 negotiation, followed by a
    new phase 2 negotiation
    has been re-established.
    · If you are using Multiple Network IPsec, the IP address of the
    ICMP Dead Peer
    constrained to the set of network ranges defined for the IPsec profile.)
  10. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Vince wrote:
    > I am having a serious problem with my 3-site VPN configuration. For
    > some reason, even though the IPSec tunnels are created, I can't ping
    > addresses on the remote subnets.
    >
    > All sites are using ADSL, w/fixed IP addresses, although 2 sites have
    > underlying PPPOE encapsulation.
    >
    > Each site is using a Netopia 3386-ENT router w/latest Firmware (8.5).
    > No firewall filter sets (perhaps this is an issue?). 3DES IPSec IKE
    > tunnels config'd in mesh between sites.
    >
    > The computers at each site connect fine to the Internet; the routers
    > are using the first fixed IP of the ISP-provided address range, NAT'ing
    > for all hosts behind the router. It _appears_ that the IPSec tunnels
    > pass IKE Phase 2 negotiation, as indicated by my "WAN Event History"
    > log, but for some reason, I cannot ping the remote routers' IP
    > addresses or any other active IP hosts on the remote subnets. The
    > bizarre thing is, when I setup sites A and B with the IPSec tunnels, I
    > experienced the same symptoms (no IP pingability across the tunnel) for
    > about 3 hours, then all of a sudden, traffic was moving fine (hosts
    > were pingable between the 2 sites, rdp session established across the
    > VPN). Great! Or so I thought. It remained fine overnight. The next
    > day, when I attempted to create the mesh tunnelling to site C, IP
    > traffic stopped passing through the tunnels between sites A and B. Now
    > I have all 3 sites telling me that the IPSec tunnels are created, but I
    > can't get any traffic to travel across them. I've got the tunnels
    > "nailed" w/Timeouts of 0 and 24-hour "scheduled" connections.
    >
    > Here is the router status info from site B (actual fixed IPs masked for
    > my protection):
    >
    > Quick View
    >
    > Default IP Gateway: 71.138.2xx.xx
    > Primary DNS Server: 206.13.29.12 Gateway installed -- Primary
    > Secondary DNS Server: 206.13.30.12 Domain Name: sbcglobal.net
    >
    > ----------------MAC Address--------IP
    > Address-------Status--------------------
    > Ethernet LAN: 00-0f-cc-20-6b-f4 192.168.1.1
    > Ethernet WAN1: 00-0f-cc-20-6b-f6 71.138.2xx.xx 100Mbps Full Duplex
    >
    >
    > Current WAN Connection Status
    > Profile Name--------Rate------%Use--Remote Address-----Est-More
    > Info----------
    > Easy Setup Profile IP 127.0.0.2 Lsd NAT
    > 71.138.2xx.xx
    >
    >
    >
    > VPN QuickView
    > LED Status
    > -PWR---------WAN Link
    > ---------------ETHERNET-----------+--------LEDS---------
    > 1 2 3 4 | '-'= Off
    > 'G'= Green
    > G G G G G G | 'R'= Red
    > 'F'= Flash
    >
    >
    >
    >
    > VPN Quick View
    >
    > Profile Name----------Type----Rx Pckts---Tx Pckts--RxDiscard--Remote
    > Address--
    > Easy Setup Profile PPPoE 2029 1782 347
    > 127.0.0.2
    > BtoA IPsec 26 451 0
    > 71.138.1xx.xx
    > BtoC IPsec 61 0 0
    > 66.125.3x.xx
    >
    >
    > WAN Event History
    > Current Date -- 9/25/05
    > 04:56:35 PM
    >
    > -Date-----Time-----Event------------------------------------------------------
    > ----------------------------------SCROLL
    > UP-----------------------------------
    > 09/25/05 16:56:32 IKE: phase 2 complete sg 66.125.3x,xx
    > 09/25/05 16:55:30 IKE: phase 2 complete sg 71.138.1xx.xx
    > 09/25/05 16:54:25 IKE: phase 2 complete sg 66.125.3x.xx
    > 09/25/05 16:53:59 IKE: phase 2 complete sg 71.138.1xx.xx
    > 09/25/05 16:53:32 IKE: phase 2 complete sg 66.125.3x,xx
    > 09/25/05 16:53:26 IKE: phase 2 complete sg 66.125.3x.xx
    > 09/25/05 16:52:49 IKE: phase 2 complete sg 71.138.1xx.xx
    > 09/25/05 16:52:46 IKE: phase 2 complete sg 66.125.3x.xx
    > 09/25/05 16:52:32 IKE: phase 2 complete sg 66.125.3x.xx
    > 09/25/05 16:52:30 IKE: phase 2 complete sg 71.138.1xx.xx
    > 09/25/05 16:52:25 IKE: phase 2 complete sg 66.125.3x.xx
    > 09/25/05 16:52:23 IKE: phase 2 complete sg 66.125.3x.xx
    > 09/25/05 16:52:20 IKE: phase 2 complete sg 66.125.3x.xx
    > 09/25/05 16:52:19 IKE: phase 2 complete sg 66.125.3x.xx
    > ---------------------------------SCROLL
    > DOWN----------------------------------
    > Clear History...
    >
    > (Should the phase 2 re-negotiation take place so frequently?)
    >
    >
    > Here's the IPSec tunnel info:
    >
    > Site A
    > IPSec TunnelA-B
    > Local Subnet: 192.168.0.0
    > Local SNM: 255.255.255.0
    > Remote Subnet: 192.168.1.0
    > Remote SNM: 255.255.255.0
    > Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site B static ip)
    >
    > IPSec TunnelA-C
    > Local Subnet: 192.168.0.0
    > Local SNM: 255.255.255.0
    > Remote Subnet: 192.168.2.0
    > Remote SNM: 255.255.255.0
    > Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site C static ip)
    >
    > Site B
    > IPSec TunnelB-A
    > Local Subnet: 192.168.1.0
    > Local SNM: 255.255.255.0
    > Remote Subnet: 192.168.0.0
    > Remote SNM: 255.255.255.0
    > Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site A static ip)
    >
    > IPSec TunnelB-C
    > Local Subnet: 192.168.1.0
    > Local SNM: 255.255.255.0
    > Remote Subnet: 192.168.2.0
    > Remote SNM: 255.255.255.0
    > Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site C static ip)
    >
    > Site C
    > IPSec TunnelC-A
    > Local Subnet: 192.168.2.0
    > Local SNM: 255.255.255.0
    > Remote Subnet: 192.168.0.0
    > Remote SNM: 255.255.255.0
    > Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site A static ip)
    >
    > IPSec TunnelC-B
    > Local Subnet: 192.168.2.0
    > Local SNM: 255.255.255.0
    > Remote Subnet: 192.168.1.0
    > Remote SNM: 255.255.255.0
    > Remote Tunnel Endpoint: xxx.xxx.xxx.xxx (Site B static ip)
    >
    > If anyone can offer insight to my dilemma (paging Mike Dreschler....),
    > I would greatly appreciate any
    >
    > help you can provide.
    >
    > Please let me know if I need to post more info about my config's.
    >
    > Thanks in advance,
    >
    > Vince
    >

    On the surface things look ok except that the Phase 2 connections are
    renegotiating constantly. Go into the WAN connection profiles and take
    a look at things like Emulation options->Advanced IPsec options to make
    sure the lifetime values look sane. You can either set them to 0 on
    both sides to make the Phase 2 connections last until the Phase 1 level
    connection expires or pick something rational like 8 hours (28800
    seconds).


    --
    WARNING! Email address has been altered for spam resistance.
    Please remove the -deletethispart-. section before replying directly.
    Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)
  11. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Mike,

    Thanks for the info. I'll try to dump the settings tonight and post
    what I find. On a related note, is there a way to externally view a
    Netopia config that was dumped via TFTP? I have the config's saved off
    for safe keeping, and it would be convenient to be able to view (or
    even modify) the config file to check for errors when I'm unable tor
    reach the routers themselves.
  12. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Vince wrote:
    > Mike,
    >
    > Thanks for the reply. All routers ahve the same settings for the
    > Advanced IPSec Options:
    > Advanced IPsec Options
    >
    > SA Lifetime seconds: 28800
    > SA Lifetime Kbytes: 0
    > Perfect Forward Secrecy: Yes
    > Dead Peer Detection: No
    > Maximum Packet Size: 1500
    >
    > These are the defaults, I did not alter them at all during setup.
    > Should I alter them, or toggle Dead Peer Detection and have it ping the
    > remote router LAN IP's?
    >
    > (From Firmware 8.5 user guide -
    > Note:
    > · ICMP Dead Peer Detection is not available when using manual
    > re-keying.
    > · ICMP Dead Peer Detection does not initiate a series of phase 2
    > exchanges instead initiates a new phase 1 negotiation, followed by a
    > new phase 2 negotiation
    > has been re-established.
    > · If you are using Multiple Network IPsec, the IP address of the
    > ICMP Dead Peer
    > constrained to the set of network ranges defined for the IPsec profile.)
    >

    That should be fine.

    You can change it to 0 if you like, but it won't make any difference.

    I suspect that something in your configuration is not correct.
    If you want a quick way of dumping the configuration you can go into the
    main menu and hit CTRL+N to drop into command line mode.

    type:
    "show config cp"
    will dump out all the connection profile settings
    Type:
    "show config ike"
    will dump out all the phase 1 ike details

    If you want to be more specific you can just dump a single entry by typing
    "show config cp 2"
    "show config ike phase1 2"
    Will dump entry number 2 for the connection profiles and IKE settings
    respectively.

    typing CTRL+N returns you to menu mode or you can type exit to drop the
    telnet connection or reset to restart the device. Some other useful
    commands are "show ip route" to show the routing table. "ping
    192.168.1.1" is a quick way to run a ping test.


    --
    WARNING! Email address has been altered for spam resistance.
    Please remove the -deletethispart-. section before replying directly.
    Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)
  13. Archived from groups: comp.dcom.vpn,microsoft.public.windows.terminal_services (More info?)

    Vince wrote:
    > Mike,
    >
    > Thanks for the info. I'll try to dump the settings tonight and post
    > what I find. On a related note, is there a way to externally view a
    > Netopia config that was dumped via TFTP? I have the config's saved off
    > for safe keeping, and it would be convenient to be able to view (or
    > even modify) the config file to check for errors when I'm unable tor
    > reach the routers themselves.
    >

    tftp backups are not human readable.

    --
    WARNING! Email address has been altered for spam resistance.
    Please remove the -deletethispart-. section before replying directly.
    Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)
Ask a new question

Read More

VPN Networking Product