| Author |
Message |
Vince
Guest
|
 Posted:
Thu Aug 18, 2005 12:20 am Post subject:
3-site VPN implementation w/Terminal Server |
|
|
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 |
|
| Back to top |
|
 |
Mike Drechsler - SPAM PRO
Guest
|
| Posted:
Thu Aug 18, 2005 12:20 am Post subject:
Re: 3-site VPN implementation w/Terminal Server |
|
|
Vince wrote:
| Quote: | 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) |
|
| Back to top |
|
|
TP
Guest
|
| Posted:
Thu Aug 18, 2005 9:50 pm Post subject:
Re: 3-site VPN implementation w/Terminal Server |
|
|
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:
| Quote: | 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 |
|
|
| Back to top |
|
|
Vince
Guest
|
| Posted:
Fri Aug 19, 2005 12:20 am Post subject:
Re: 3-site VPN implementation w/Terminal Server |
|
|
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? |
|
| Back to top |
|
|
Vince
Guest
|
| Posted:
Fri Aug 26, 2005 11:34 pm Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
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. |
|
| Back to top |
|
|
Mike Drechsler - SPAM PRO
Guest
|
| Posted:
Sat Aug 27, 2005 12:20 am Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
Vince wrote:
| Quote: | 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) |
|
| Back to top |
|
|
Vince
Guest
|
| Posted:
Sat Aug 27, 2005 12:20 am Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
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.) ? |
|
| Back to top |
|
|
Mike Drechsler - SPAM PRO
Guest
|
| Posted:
Mon Aug 29, 2005 8:20 am Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
Vince wrote:
| Quote: | 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) |
|
| Back to top |
|
|
Vince
Guest
|
| Posted:
Mon Sep 26, 2005 8:20 am Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
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 |
|
| Back to top |
|
|
Mike Drechsler - SPAM PRO
Guest
|
| Posted:
Mon Sep 26, 2005 3:58 pm Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
Vince wrote:
| Quote: | 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) |
|
| Back to top |
|
|
Vince
Guest
|
| Posted:
Mon Sep 26, 2005 4:20 pm Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
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.) |
|
| Back to top |
|
|
Mike Drechsler - SPAM PRO
Guest
|
| Posted:
Mon Sep 26, 2005 10:44 pm Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
Vince wrote:
| Quote: | 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) |
|
| Back to top |
|
|
Vince
Guest
|
| Posted:
Tue Sep 27, 2005 12:57 am Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
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. |
|
| Back to top |
|
|
Mike Drechsler - SPAM PRO
Guest
|
| Posted:
Tue Sep 27, 2005 4:42 am Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
Vince wrote:
| Quote: | 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) |
|
| Back to top |
|
|
Vince
Guest
|
| Posted:
Fri Sep 30, 2005 10:41 pm Post subject:
Re: 3-site VPN implementation w/Terminal Server - Netopia up |
|
|
OK, here's where I stand with this frustrating setup.
Site A: phase2 renegotiation with Site B takes place every few
seconds. Can ping router addresses
ate sites B and C, but can only ping remote host IP addresses at site
C.
Site B: phase2 renegotiation with Site A takes place every few
seconds. Can ping router addresses
ate sites A and C, but can't ping remote host IP addresses at sites A
or C.
Site C: phase1 and 2 renegotiations occur at scheduled intervals. Can
ping router addresses
ate sites A and B, but can't ping remote host IP addresses at sites A
or B.
If anyone can offer insight to what I am doing wrong, I would greatly
appreciate it. Mike, I am in
dire need of your wisdom.
Here's a recap of the tunnel info, along with my router config dumps:
Site A (207)
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: 71.138.2xx.xx (Site B static ip)
cp 2 tag AtoB
cp 2 enable yes
cp 2 dle ipsec
cp 2 ipsec dead-peer-detection enable yes
cp 2 ipsec dead-peer-detection ping-address 192.168.1.1
cp 2 ipsec dead-peer-detection ping-retry 5
cp 2 ipsec dead-peer-detection ping-reply-timeout 90
cp 2 ipsec idle-timeout 0
cp 2 ipsec ike phase1 2
cp 2 ipsec ip remote members 192.168.1.0/24 sg 71.138.2xx.xx local
members 19\
2.168.0.0/24 ;[Net 0]
cp 2 ipsec mtu 1500
cp 2 ipsec pfs yes
cp 2 ipsec key-manager ike
cp 2 ipsec sa lifetime seconds 28800
cp 2 ipsec sa lifetime kbytes none
cp 2 ipsec spi 2 44636 4 9299
cp 2 ipsec suite encapsulation esp encryption 3des authentication esp
hmac-md5\
-96
cp 2 ip enable yes
cp 2 ip address local 0.0.0.0/0
cp 2 ip address remote 192.168.1.0/24
cp 2 ip addressing unnumbered
cp 2 ip dhcp client mode standard
cp 2 ip mask local 0.0.0.0
cp 2 ip mask remote 255.255.255.0
cp 2 ip nat enable no
cp 2 ip nat map-list "Easy-PAT List"
cp 2 ip nat server-list Easy-Servers
cp 2 ip negotiate-lan no
cp 2 ip netbios proxy enable yes
cp 2 ip rip receive no
cp 2 ip rip transmit no
cp 2 ip state-insp enable no
cp 2 interface-group any
cp 2 bridge enable no
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: 66.125.3x.xxx (Site C static ip)
cp 3 yes
cp 3 tag SBCto805
cp 3 enable yes
cp 3 dle ipsec
cp 3 ipsec dead-peer-detection enable yes
cp 3 ipsec dead-peer-detection ping-address 192.168.2.1
cp 3 ipsec dead-peer-detection ping-retry 5
cp 3 ipsec dead-peer-detection ping-reply-timeout 90
cp 3 ipsec idle-timeout 0
cp 3 ipsec ike phase1 2
cp 3 ipsec ip remote members 192.168.2.0/24 sg 66.125.3x.xxx local
members 192.\
168.0.0/24 ;[Net 0]
cp 3 ipsec mtu 1500
cp 3 ipsec pfs yes
cp 3 ipsec key-manager ike
cp 3 ipsec sa lifetime seconds 28800
cp 3 ipsec sa lifetime kbytes none
cp 3 ipsec spi 2 44636 4 9299
cp 3 ipsec suite encapsulation esp encryption 3des authentication esp
hmac-md5\
-96
cp 3 ip enable yes
cp 3 ip address local 0.0.0.0/0
cp 3 ip address remote 192.168.2.0/24
cp 3 ip addressing unnumbered
cp 3 ip dhcp client mode standard
cp 3 ip mask local 0.0.0.0
cp 3 ip mask remote 255.255.255.0
cp 3 ip nat enable no
cp 3 ip nat map-list "Easy-PAT List"
cp 3 ip nat server-list Easy-Servers
cp 3 ip negotiate-lan no
cp 3 ip netbios proxy enable yes
cp 3 ip rip receive no
cp 3 ip rip transmit no
cp 3 ip state-insp enable no
cp 3 interface-group any
cp 3 bridge enable no
Site B (Montebello)
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: 71.138.1xx.xxx (Site A static ip)
cp 4 yes
cp 4 tag BtoA
cp 4 enable yes
cp 4 dle ipsec
cp 4 ipsec dead-peer-detection enable yes
cp 4 ipsec dead-peer-detection ping-address 192.168.0.1
cp 4 ipsec dead-peer-detection ping-retry 5
cp 4 ipsec dead-peer-detection ping-reply-timeout 90
cp 4 ipsec idle-timeout 0
cp 4 ipsec ike phase1 2
cp 4 ipsec ip remote members 192.168.0.0/24 sg 71.138.1xx.xxx local
members 192\
..168.1.0/24 ;[Net 0]
cp 4 ipsec mtu 1500
cp 4 ipsec pfs yes
cp 4 ipsec key-manager ike
cp 4 ipsec sa lifetime seconds 28800
cp 4 ipsec sa lifetime kbytes none
cp 4 ipsec spi 2 44636 4 48675
cp 4 ipsec suite encapsulation esp encryption 3des authentication esp
hmac-md5\
-96
cp 4 ip enable yes
cp 4 ip address local 0.0.0.0/0
cp 4 ip address remote 192.168.0.0/24
cp 4 ip addressing unnumbered
cp 4 ip dhcp client mode standard
cp 4 ip mask local 0.0.0.0
cp 4 ip mask remote 255.255.255.0
cp 4 ip nat enable no
cp 4 ip nat map-list "Easy-PAT List"
cp 4 ip nat server-list Easy-Servers
cp 4 ip negotiate-lan no
cp 4 ip netbios proxy enable yes
cp 4 ip rip receive no
cp 4 ip rip transmit no
cp 4 ip state-insp enable no
cp 4 interface-group any
cp 4 bridge enable no
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: 66.125.3x.xxx (Site C static ip)
cp 3 yes
cp 3 tag BtoC
cp 3 enable yes
cp 3 dle ipsec
cp 3 ipsec dead-peer-detection enable yes
cp 3 ipsec dead-peer-detection ping-address 192.168.2.1
cp 3 ipsec dead-peer-detection ping-retry 5
cp 3 ipsec dead-peer-detection ping-reply-timeout 90
cp 3 ipsec idle-timeout 0
cp 3 ipsec ike phase1 2
cp 3 ipsec ip remote members 192.168.2.0/24 sg 66.125.3x.xxx local
members 192.\
168.1.1/24 ;[Net 0]
cp 3 ipsec mtu 1500
cp 3 ipsec pfs yes
cp 3 ipsec key-manager ike
cp 3 ipsec sa lifetime seconds 28800
cp 3 ipsec sa lifetime kbytes none
cp 3 ipsec spi 2 44636 4 48675
cp 3 ipsec suite encapsulation esp encryption 3des authentication esp
hmac-md5\
-96
cp 3 ip enable yes
cp 3 ip address local 0.0.0.0/0
cp 3 ip address remote 192.168.2.0/24
cp 3 ip addressing unnumbered
cp 3 ip dhcp client mode standard
cp 3 ip mask local 0.0.0.0
cp 3 ip mask remote 255.255.255.0
cp 3 ip nat enable no
cp 3 ip nat map-list "Easy-PAT List"
cp 3 ip nat server-list Easy-Servers
cp 3 ip negotiate-lan no
cp 3 ip netbios proxy enable yes
cp 3 ip rip receive no
cp 3 ip rip transmit no
cp 3 ip state-insp enable no
cp 3 interface-group any
cp 3 bridge enable no
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: 71.138.1xx.xxx (Site A static ip)
cp 3 yes
cp 3 tag CtoA
cp 3 enable yes
cp 3 dle ipsec
cp 3 ipsec dead-peer-detection enable yes
cp 3 ipsec dead-peer-detection ping-address 192.168.0.1
cp 3 ipsec dead-peer-detection ping-retry 5
cp 3 ipsec dead-peer-detection ping-reply-timeout 90
cp 3 ipsec idle-timeout 0
cp 3 ipsec ike phase1 2
cp 3 ipsec ip remote members 192.168.0.0/24 sg 71.138.1xx.xxx local
members 192\
..168.2.0/24 ;[Net 0]
cp 3 ipsec mtu 1500
cp 3 ipsec pfs yes
cp 3 ipsec key-manager ike
cp 3 ipsec sa lifetime seconds 28800
cp 3 ipsec sa lifetime kbytes none
cp 3 ipsec spi 2 44636 4 18515
cp 3 ipsec suite encapsulation esp encryption 3des authentication esp
hmac-md5\
-96
cp 3 ip enable yes
cp 3 ip address local 0.0.0.0/0
cp 3 ip address remote 192.168.0.0/24
cp 3 ip addressing unnumbered
cp 3 ip dhcp client mode standard
cp 3 ip mask local 0.0.0.0
cp 3 ip mask remote 255.255.255.0
cp 3 ip nat enable no
cp 3 ip nat map-list "Easy-PAT List"
cp 3 ip nat server-list Easy-Servers
cp 3 ip negotiate-lan no
cp 3 ip netbios proxy enable yes
cp 3 ip rip receive no
cp 3 ip rip transmit no
cp 3 ip state-insp enable no
cp 3 interface-group any
cp 3 bridge enable no
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: 71.138.2xx.xx (Site B static ip)
cp 2 yes
cp 2 tag CtoB
cp 2 enable yes
cp 2 dle ipsec
cp 2 ipsec dead-peer-detection enable yes
cp 2 ipsec dead-peer-detection ping-address 192.168.1.1
cp 2 ipsec dead-peer-detection ping-retry 5
cp 2 ipsec dead-peer-detection ping-reply-timeout 90
cp 2 ipsec idle-timeout 0
cp 2 ipsec ike phase1 2
cp 2 ipsec ip remote members 192.168.1.0/24 sg 71.138.2xx.xx local
members 19\
2.168.2.0/24 ;[Net 0]
cp 2 ipsec mtu 1500
cp 2 ipsec pfs yes
cp 2 ipsec key-manager ike
cp 2 ipsec sa lifetime seconds 28800
cp 2 ipsec sa lifetime kbytes none
cp 2 ipsec spi 2 44636 4 18515
cp 2 ipsec suite encapsulation esp encryption 3des authentication esp
hmac-md5\
-96
cp 2 ip enable yes
cp 2 ip address local 0.0.0.0/0
cp 2 ip address remote 192.168.1.0/24
cp 2 ip addressing unnumbered
cp 2 ip dhcp client mode standard
cp 2 ip mask local 0.0.0.0
cp 2 ip mask remote 255.255.255.0
cp 2 ip nat enable no
cp 2 ip nat map-list "Easy-PAT List"
cp 2 ip nat server-list Easy-Servers
cp 2 ip negotiate-lan no
cp 2 ip netbios proxy enable yes
cp 2 ip rip receive no
cp 2 ip rip transmit no
cp 2 ip state-insp enable no
cp 2 interface-group any
cp 2 bridge enable no
The IKE config is identical on all 3 routers, as determined by using
Beyond Compare:
ike phase1 2 authentication method shared-secret
ike phase1 2 authentication shared-secret ascii *****
ike phase1 2 dangling-sas no
ike phase1 2 encryption 3des
ike phase1 2 group 2
ike phase1 2 hash md5
ike phase1 2 id 2
ike phase1 2 identity local ipv4-address 0.0.0.0
ike phase1 2 identity remote ipv4-address 0.0.0.0
ike phase1 2 independent rekeys yes
ike phase1 2 initial-contact yes
ike phase1 2 invalid-spi-recovery no
ike phase1 2 mode main
ike phase1 2 negotiation normal
ike phase1 2 port policy permissive
ike phase1 2 sa lifetime seconds 28800
ike phase1 2 sa lifetime kbytes none
ike phase1 2 sa use-policy new-sas-immediately
ike phase1 2 tag "DHC IKE Profile"
ike phase1 2 vendor-id yes
Since this last config dump, I have tried scheduling the phase 2
duration to be half that of phase 1 (4 hours instead of 8), following
some recommendations I found elsewhere. No help. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in