Becase a more beefy dedicated circuit was apparently too expensive, I have been tasked with utilizing the internet as our primary data connectivity between two sites. To do this, site-to-site VPN seems to be the only sensible solution. The subnetting is currently ATROCIOUS... I am trying to streamline it... and the future of this environment is a fully meshed MPLS solution for inter-office connectivity, while in this one scenario I have to use the internet to connect two relatively close offices in the same city - currently it is handled by point to point wireless.
I intend to designate the LAN environment of this particular city to be the 10.20.0.0/16 environment, with the future cities being 10.40.0.0/16 and 10.60.0.0/16 etc -so that via MPLS we can all exchange a single /16 instead of the discontiguous nightmare that is the current environment. For political reasons, I am forced to try and solve the routing problem I'm having via eigrp. Here's the topology inquestion:
ASA1------INTERNET------ASA2
| |
R1-----------VOIP T1-----------R2
| |
LAN LAN
All services (DHCP, DNS, DOMAIN, etc) are hosted by R1. My initial addressing plan involved using 10.20.250.X/30's on all the point to point links with several /22's and /24's used for other purposes. The "VOIP T1" is to be used only for voip traffic for our Cisco Phones - I currently have a route map managing that, with all other intra-office communication going over a P2P wirelss link that we're trying to use the INTERNET to replace.
I mocked this up with GNS3 and I'm stuck trying to figure out how to initiate EIGRP communication over the tunnel - I used this guide to set up the L2L/Site-to-Site tunnel:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00805a87f7.shtml#CLI
BUT - as mentioned in this forum thread (which also gives a generic GRE tunnel setup template, but where the tunnel destinations are publicly routable addresses - 14.x.x.x):
https://supportforums.cisco.com/thread/256270 The mcast EIGRP protocol traffic wouldn't go over the tunnel - it would have to be encapsulated in GRE - I have no idea how to properly set the tunnel destination/target since it's an RFC 1918 address... can I trust the natting of the FW to convert that into the internet routable address it would have to be - the only public address space will be owned by the ASA? Currently I have this set up to do PAT, but if I'm going to do this in production, I would clearly want that to be static - if it even works this way.
My 2nd dilemma is realizing that I put a "route inside 10.20.0.0 255.255.0.0 10.20.250.X" statement on my FWs to get reply traffic from the "internet" back to my hosts. I would've thought the PAT config would've made that work, but it didn't until I added that route statement. I'm worried such a statement would wreak havoc with any dynamic routing as the fw would believe that a packet sourced from 10.20.30.0/24 (on R1) and destined for 10.20.48.10/22 (on R2) should actually be routed right back out the interface it came from. I suppose I could redraw the subnetting so my "route inside" statement was only for networks owned by R1 (which admittedly would be cleaner). I'm also sure this is why no interesting traffic ever triggers the tunnel to come up - anytime I issue the 'show crypto isakmp sa' command, no sa's are ever formed.
Usually when I reach this point in my grand plans, I find out I've made all sorts of calamitous errors that necessitate redoing everything from scratch. Hope that isn't the case. I'm attaching the ASA configs I built to do this and I'm hoping I don't have to reinvent the wheel here.
