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

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)

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

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?

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.

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/ [...] ESCracker/
 
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)

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.) ?

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)

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

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)

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.)

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)