cisco ipsec == pita
Written by jlgaddis on January 1, 2005 – 5:52 pm -For anyone who has never has the pleasure of delving into IPSec on Cisco’s IOS software, let me offer a piece of advice: don’t.
Nah, just kidding. It’s not that bad, but trying to get a working configuration is complicated by the fact that I don’t exactly have a “standard” setup.
Background info: I have a 768/128kbps DSL link to the Internet through Blueriver Networking. My DSL modem is a Westell 516, which is just an ethernet bridge for DMT-modulated ADSL lines. That runs into a Cisco Systems 4500M Router equipped with two ethernet and four serial interfaces. ethernet0 runs to the DSL modem and ethernet1 runs to a Cisco Systems Catalyst 1912EN switch. Hosts on my LAN are assigned IP addresses in the 192.168/16 netblock, in accordance with RFC 1918, Address Allocation for Private Internets.
Enter IPSec.
A large group of “online acquaintances” has formed a rather large IPSec-based Virtual Private Network (VPN), compromised of numerous nodes in multiple countries on multiple continents. I previously had a link to the VPN when I was using a Debian GNU/Linux box running the FreeS/WAN implementation of IPSec. The Linux kernel’s NAT and routing features allowed me to access services on the VPN without much of a problem (when the link stayed up, that is).
As previously mentioned, however, I’m now using a Cisco 4500M router on the “edge” of my Internet connection. I’m running a version of the IOS software the IPSec 3DES support so that’s not a problem. The problem comes from the fact that I need to do some pretty funky stuff to get access to services on the VPN. Remember me mentioning that I use IP addresses in the 192.168/16 netblock? The hosts I want to be able to access the VPN are on the 192.168.0/24 subnet, which is fine and dandy. For the purposes of the VPN, however, I have been assigned the 10.65.2/24 netblock out of the 10.64/14 and 10.164/14 netblocks we’re using (also in accordance with RFC1918. The problem lies in that any outbound traffic destined for the Internet is NAT’d to my public IP address. I need outbound traffic destined for the VPN (10.64/14 or 10.164/14) to be NAT’d to 10.65.2.x. I have actually made great progress from where I was at a week or so ago with this and now have IPSec running, along with a GRE tunnel. SA’s are being properly established. I cannot, however, properly communicate through the tunnel. I’m pretty confident at this point (thanks to sniffing outbound traffic from the router) that outbound VPN traffic is, indeed, making it to the remote endpoint of the tunnel, but I believe it’s being discarded there due to having invalid source addresses for the interface it’s coming in on. Once I can communicate with one of the administrators of $remote_box and have them run a tcpdump on that interface (after the traffic is decrypted), I’m pretty sure we should be able to get it working (I just *KNOW* it’s a problem with my NAT stuff). Grrr, why can’t I just get a /24 of my own at home!?
Tags: networking, security | No Comments »



