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

Reply to
Vince
Loading thread data ...

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.

Reply to
Mike Drechsler - SPAM PROTECTE

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.

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

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

V> Hello,

Reply to
TP

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?

Reply to
Vince

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.

Reply to
Vince

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

Reply to
Vince

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:

formatting link
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.

Reply to
Mike Drechsler - SPAM PROTECTE

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.

Reply to
Mike Drechsler - SPAM PROTECTE

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

Reply to
Vince

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

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

Reply to
Mike Drechsler - SPAM PROTECTE

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.

Reply to
Vince

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.
Reply to
Mike Drechsler - SPAM PROTECTE

tftp backups are not human readable.

Reply to
Mike Drechsler - SPAM PROTECTE

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.

Reply to
Vince

SNIP

SNIP

SNIP

SNIP

SNIP

SNIP

SNIP

SNIP

SNIP

SNIP

SNIP

SNIP

Ok, I think I know what you have going on. You are using the same IKE phase 1 session for 2 different endpoints. You should setup a separate phase 1 IKE connection for each router pair with it's own password. I personally like randomly generated passwords for these. I don't even bother to remember the password, I just generate a new one if I ever need to change it.

So on each site, you should have 2 connection profiles and 2 IKE profiles. One for each remote router that will be connecting to that router. They should not share an ike configuration even though the router lets you do this.

Reply to
Mike Drechsler - SPAM PROTECTE

Hi Mike,

OK, I tried setting up the IKE profiles as you suggested. I have one IKE profile for each tunnel on each router - the ends of each tunnel have identical IKE profile settings. Both tunnels coming from Site C are fine, communication is good, no excessive phase 2 renegotiations. The problem now is that the tunnels between site A and B were still re-negotiating phase 2 every few seconds, and periodically lose communication between the subnets until I re-set the tunnel. I just now tried changing the advanced IKE settings to use old SA's until expired instead of using new SA's immediately, that seems to have quieted things down for now - but for how long, who knows. Any suggestions?

Reply to
Vince

Not sure I understand what you mean by different - each router has 2 tunnels, and each tunnel has the same IKE profile on each end, but each pair has a unique profile/password/key, shared between the 2 routers at each end. Shouldn't the parameters at each end be the same? Or does each and every password need to be unique?

Here's what I have now:

Site A Site B Router A config for "Tunnel A-B":(IKE Profile: "A-B", password: "a2b") Router B config for "Tunnel A-B":(IKE Profile: "A-B", password: "a2b")

Site A Site C Router A config for "Tunnel A-C":(IKE Profile: "A-C", password: "a2c") Router C config for "Tunnel A-C":(IKE Profile: "A-C", password: "a2c")

Site B Site C Router B config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c") Router C config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")

Reply to
Vince

Make sure that each IKE profile has a different password/key and they aren't all identical.

Reply to
Mike Drechsler - SPAM PROTECTE

Sorry, the last tunnel should be: Site B Site C Router B config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c") Router C config for "Tunnel B-C":(IKE Profile: "B-C", password: "b2c")

Could there be an issue with the way I am "nailing" the tunnels? Should only on side have a "dead peer detection" and/or 24-hour scheduled connection and/or 0-value timeout for the tunnel?

Reply to
Vince

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.