There are many cool things about working at a large church like LifeChurch.tv. It's exciting to hear about all the changed lives each weekend, and it's humbling to think about how God is allowing us to take His message all over the world.
Along with the cool stuff, of course, comes a few difficult things for the handy dandy neighborhood IT Team.
We currently have 13 campuses in 6 states (which includes our Internet Campus). Our 14th Campus opens in early 2009. A challenge we have faced for many years now is campus connectivity. There is a balance between "perfect connectivity" and "financial stewardship." Our larger metro OKC campuses are connected with high-bandwidth point-to-point circuits. The rest of the campuses are all connected via standard DSL/Cable connections and IPSec VPN. Until recently, we have been able to connect all the campuses with Cisco equipment – either Routers or PIX/ASA Firewalls.
**insert ominous music**
In Early 2008, we launched our 2nd Tulsa Campus – Internally called "STO" – or "South Tulsa" Campus. It's awesome, God is doing GREAT things in Tulsa. Unfortunately, the location of the STO Offices is in an area with ONLY BTC (Bixby Telecom) service and ONLY DYNAMIC DSL and there is something weird with their DSLAM equipment that when combined with Cisco equipment + IPSec causes serious network issues. So, what do we do?
The good news is that we had a plan. For several years we have been using IPCop for content filtering. It is a great free GPL product with lots of fun add-ons. We left IPCop for Websense – I blogged a little about that here – but IPCop has a VPN Capability built in. Why not try it? So we did. And it worked.
Here are some of the details just in case you'd like to try this yourself.
Cisco ASA 5520 – Running ASA OS v8.03 – Central Connection – Configuration Details
First, you'll want to identify an object-group…this identifies the PRIVATE IP Network details for the remote network behind the IPCop.
object-group network Remote_Network
description Remote Campus Network
network-object 10.10.20.0 255.255.255.0
Next, you'll want to create an access-list that "permits" traffic going to the object group that you created.
access-list VPN_Remote_Network extended permit ip any object-group Remote_Network
Next you'll want to create a crypto map entry for this particular VPN connection. I'll assume here that you have already created a crypto map for OTHER VPN connections and now you're just wanting to create this one for IPCop-to-Cisco VPN.
crypto map VPN_map 2 match address VPN_Remote_Network
crypto map VPN_map 2 set pfs
crypto map VPN_map 2 set peer PUBLIC.IP.OF.IPCOP
crypto map VPN_map 2 set transform-set ESP-3DES-SHA ESP-3DES-MD5
crypto map VPN_map 2 set nat-t-disable
crypto map VPN_map 2 set reverse-route
Next, you'll want to create a group-policy that identifies you want to use IPSec for your VPN tunnels
group-policy IPCopVPN internal
group-policy IPCopVPN attributes
vpn-tunnel-protocol IPSec
Finally, you'll want to create the actual VPN tunnel group
tunnel-group PUBLIC.IP.OF.IPCOP type ipsec-l2l
tunnel-group PUBLIC.IP.OF.IPCOP general-attributes
default-group-policy IPCopVPN
tunnel-group PUBLIC.IP.OF.IPCOP ipsec-attributes
pre-shared-key strongpassword
Obviously, you need to change "strongpassword" to be a strong shared password that you will authenticate your remote IPCop box to this Cisco ASA to create the tunnel.
Great, now the Cisco ASA 5520 configuration is complete. Off to IPCop.
IPCop – Running version 1.4.16 – STO Campus Connection – Configuration Details
Launch the IPCop Interface, http://IPCOP.IP:81, and click on VPNs -> VPNs menu like below
When the VPNs menu launches, you'll need to verify a few things… Make sure you settings look like below… have your PUBLIC IP in the appropriate box, click the Enabled checkbox, and click Save.
Great, now you need to create a tunnel. Click the Add button. Now, choose "net to net" and click Add.
Make your settings like below… Pay particular attention to the order of the subnets. In this example, the Host IP Address is the PUBLIC.IP of the IPCop box – the RED Interface. The rest of it should make sense – working backwards from the Cisco ASA Config. The Local subnet is the subnet behind the IPCop box (ala: the Remote_Network on the Cisco ASA) and the Remote HOST is the PUBLIC.IP of the Cisco ASA and the Remote Subnet is any subnet(s) that are at the Central location behind the Cisco ASA. Make sense?
Anyway, click Save. You're network will now show up like below.
Check that out… it's RED and Closed. That's normal. Click the little arrow next to the RED Closed status. Your screen will refresh, and, assuming you configured everything properly, your VPN tunnel will connect.
Hooray! Your VPN tunnel is now GREEN and Open.
I'm blogging this because it's been on my mind lately. Why you say? Because we still use this connection at our STO Campus. And, randomly, we will lose connection. We have a dynamic IP – because BTC won't give us static IPs. So, from time to time, we need to rebuild this connection because the PUBLIC.IP on the IPCop box will change. It's very annoying. It's happened several times recently – including yesterday – so it's fresh on my mind and I wanted to capture the info somewhere in hopes that it helps someone else. G'nite!
Hi,
very nice work.
I’m trying to get data packets over my “asa 5505 (8.4(1)) to ipcop 1.4.21 ipsec”-connection.
The tunnel is green, but pings and other data is not going thru the tunnel. The ipcop has BOT on it, and I set it to “permit any to any” so that there are no packets to be dropped/rejected (also on the asa).
Do you have an idea? How did you set routing/exempt rules or nat on the asa?
best regards
Erik
Erik–
When I’ve seen this in the past, it’s been many years, but when I’ve seen it – it’s related to ACL “reflection”
Whatever you identify as interesting/ACL traffic on one side, needs to be reflected/mirrored on the other.