mrsmileyns
asked on
Cisco backup VPN
Here is the basic idea – 3 sites – NY, Fl, NJ - NY is the hub and NJ and Fl are spokes. Normal operation is as follows – NJ and FL are connected to NY via point to point T1’s with Cisco 2600’s at the sites to a Cisco 3600 at the NY site – the 3600 is then connected to a Cisco Gbic Aggregator which does of the vlans for the NY site – the Aggregator then goes to a Watchguard Firebox firewall/VPN server and out to the internet over a 4.5 mbps pipe. So remote sites are connected to the hub with point to point T1’s and use the hub’s internet connectivity. This all works fine and is running well. If none of the point to point T1’s ever go down, the next paragraph will not be an issue.
This is the issue – goal is to have redundancy at both remote locations for both internet access and site to site connectivity to the NY office. So, both remote sites have additional internet T1’s and an identical Watchguard Firbox/VPN server. Both of the 2600’s at the remote sites have a primary gateway of last resort as the 3600 back in the NY office. This works fine. They also have another gateway of last resort set with a metric of 100 – so it will be “secondary.” This is the trusted interface on the Watchguard so it will be used as a backup in the event that the point to points go down. In theory, if I shutdown the serial interface on the point to point connectivity on the 2600 at either of the remote sites the 2600 should then route all packets to the route with a metric of 100 as the main route has become unavailable. Is this correct? I am finding the rollover test process to be very rough to say the least. It is proving to be very sloppy when the point to point T1 drops and it “rolls” to the backup internet connectivity / VPN to the NY office. I am finding reboots of Windows machines, reassignment of gateways are necessary among other anomalies.
Without getting too detailed and going on too long – is the basic engineering premise behind this backup solution sound? Does it seem like it should work? If you were the engineer how would you accomplish this goal of internet and remote site to NY site redundancy ?
This is the issue – goal is to have redundancy at both remote locations for both internet access and site to site connectivity to the NY office. So, both remote sites have additional internet T1’s and an identical Watchguard Firbox/VPN server. Both of the 2600’s at the remote sites have a primary gateway of last resort as the 3600 back in the NY office. This works fine. They also have another gateway of last resort set with a metric of 100 – so it will be “secondary.” This is the trusted interface on the Watchguard so it will be used as a backup in the event that the point to points go down. In theory, if I shutdown the serial interface on the point to point connectivity on the 2600 at either of the remote sites the 2600 should then route all packets to the route with a metric of 100 as the main route has become unavailable. Is this correct? I am finding the rollover test process to be very rough to say the least. It is proving to be very sloppy when the point to point T1 drops and it “rolls” to the backup internet connectivity / VPN to the NY office. I am finding reboots of Windows machines, reassignment of gateways are necessary among other anomalies.
Without getting too detailed and going on too long – is the basic engineering premise behind this backup solution sound? Does it seem like it should work? If you were the engineer how would you accomplish this goal of internet and remote site to NY site redundancy ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
mikebernhardt
In fact, if you make the firewall changes your static routes would likely work a lot better for your design. But as I said, static routes are static. If you want routes that are (almost) guaranteed to be good you should use something dynamic.
ASKER
Actually - good point - I will clarify - all of the internet traffic must go out through the NY office unless there is a catastrophe and the backup internet connections at the remote sites are to be used. We do have browsing policies, strict logging and the like enforced via the NY office due to the nature of our business this is a requirement. I do have EIGRP set up on all of our Ciscos - the 2600's at the remote offices, and the 3600 and the Aggregator at the home office - I am fairly new to using that routing protocol - it was that way when I started here 2 months ago as was this design half done - I am not sure if it is helping. I will leave this open for a while longer and see if anyone has any other ideas. Thanks.
Even if you had to reboot PCs, etc. the fact that the problem cleared after that indicates to me that routing isn't the issue. A routing problem would be persistent and has nothing to do with your LANs. It sounds like the firewall state issue is causing your problems.
One way to test whether your routing design is working is to do your failover test without the remote-site firewalls in the mix. Then simply set up pings to some addresses both in NY and the Internet. If those go as hoped when you fail over, you know that the firewalls are the problem.
What I'm not clear about is whether the goal is to have internet traffic on the backup T1 travel the VPN and go through NY also? If so, then just remove the remote firewalls. If not, perhaps you can set up the remote-site firewalls so that any VPN traffic to NY is not checked for state. Go with my original suggestion but decentralize the usage policies so that all of the sites are self-sufficient (probably expensive though!) but log back to NY.
One way to test whether your routing design is working is to do your failover test without the remote-site firewalls in the mix. Then simply set up pings to some addresses both in NY and the Internet. If those go as hoped when you fail over, you know that the firewalls are the problem.
What I'm not clear about is whether the goal is to have internet traffic on the backup T1 travel the VPN and go through NY also? If so, then just remove the remote firewalls. If not, perhaps you can set up the remote-site firewalls so that any VPN traffic to NY is not checked for state. Go with my original suggestion but decentralize the usage policies so that all of the sites are self-sufficient (probably expensive though!) but log back to NY.
ASKER
No - goal is to have the backup T1's go out direct to the internet - in the event that we needed to use the backup T1's, they will go out to the internet over those pipes - we will sacrfice the monitoring and logging for that time as...well, hopefully they never get used - the VPN is only for connection to file and application servers back in NYC.
I think there are better ways to do this - unfortunately, equipment was purchased and this was halfway done when I arrived on the scene - so I am trying to get the best solution under the circumstances - in addition it is tough because there is no IT staff at one of the remote sites for testing - whine whine from me :)
I think there are better ways to do this - unfortunately, equipment was purchased and this was halfway done when I arrived on the scene - so I am trying to get the best solution under the circumstances - in addition it is tough because there is no IT staff at one of the remote sites for testing - whine whine from me :)
Do the failover test I suggested and then at least you'll know where to focus your efforts. I see 2 solutions:
1. Try to set up firewalls so that VPN traffic to NY passes through without state checking. Maybe you can set up the VPN between 2 routers that are already inside the firewalls instead of between the firewalls themselves, which would keep the remote firewalls out of the loop. You may still have problems with some internet traffic though.
2. Perhaps the NY firewall can share state info with the remote ones. But usually this is done out-of-band.
1. Try to set up firewalls so that VPN traffic to NY passes through without state checking. Maybe you can set up the VPN between 2 routers that are already inside the firewalls instead of between the firewalls themselves, which would keep the remote firewalls out of the loop. You may still have problems with some internet traffic though.
2. Perhaps the NY firewall can share state info with the remote ones. But usually this is done out-of-band.
ASKER
I will work on it and post back to this question in the future - but you have given me a lot to chew on - thanks for the help and time
In early 2000 a friend and I tested 2 2620s with encryption modules running IPSec across a T1 with no problems. It depended on how many packets/sec, not on the actual bandwidth. We were jamming up to 1800 pkts/sec with the encryption module, 1300 without, before CPU utilization got too high.