We're trying to set up a site-to-site VPN between a 3825 (IOS 12.4, also our border router) at our main site and an ASA5505 (8.2) at a branch office. It appears the encrypted tunnel portion is operating properly but we're not getting packets from either side to the other. At the least, packets from the main site that are sent from the main router to the 3825 intended to cross the VPN are being sent back to the main router.
I'm hoping someone can point out what we're doing wrong or not doing. Until we get this right, the ASA5505 is not yet at the branch office and we're trying it out from one of our homes (static, routable IP, not NATed).
I'm not clear on how the 3825 is supposed to deal with packets intended to cross the VPN. Since these packets have a destination of a /24 that is a subnet of the /16 for the main office network, the ip routing table would happily send them back to the main internal router. I would have thought that the crypto map's match access-list would override that, but maybe not.
The apparently unusual situation is that our border router does not do any NAT. Perhaps for more common l2l VPNs, the NAT rules cause the packets that should cross the VPN to be sent there.
Throughout, I've anonymized our IP info. 999.999.0.0/16 is a routable IP range.
From the point of view of the branch office, the VPN is a split tunnel. The IPs at the branch office are 999.999.99.0/24 and these are used to communicate (ie, not NATed) to the main office, but they are NATed (actually PATed, I guess) before going out to the Internet (eg, to cisco.com). Connections to the Internet from behind the 5505 work as expected.
From the point of view of the main office, NAT is not done at all. And of course the VPN is effectively a split tunnel as only the packets to the branch office are directed over the VPN.
Below is a diagram of the topology. Attached are the VPN & routing relevant portions of the configuration of the two VPN endpoints.
An observed problem is that a traceroute shows packets sent from 999.999.1.2 to 999.999.99.32 go to 999.999.1.1 (as expected) but then are delivered to 999.999.1.2 and the looping begins. I tried a few different IP routings for those packets but none makes sense. I would think the IP routes shouldn't apply. It would make more sense if the 999.999.1.1 interface had an additional address of 999.999.99.2 (but I didn't try that).
Here is a log snippet showing the SA gets built, and a ping from the branch office to the main office is sent. (As I look through last night's logs, I don't see that we tried a non-ICMP connection from branch office to main office. It is possible that we didn't confirm whether non-ICMP packets got to a main office machine and that some firewall rule blocked the ICMP. Obviously any ACK doesn't get back, but we were looking with tcpdump.)
Apr 10 2015 20:58:58: %ASA-6-602303: IPSEC: An inbound LAN-to-LAN SA (SPI= 0xC55054E2) between 900.9.9.2 and 800.8.8.2 (user= 800.8.8.2) has been created. Apr 10 2015 20:58:58: %ASA-5-713120: Group = 800.8.8.2, IP = 800.8.8.2, PHASE 2 COMPLETED (msgid=511a19d7) Apr 10 2015 20:58:59: %ASA-6-302020: Built outbound ICMP connection for faddr 999.999.3.5/0 gaddr 999.999.99.32/17947 laddr 999.999.99.32/17947 Apr 10 2015 20:59:15: %ASA-6-302021: Teardown ICMP connection for faddr 999.999.3.5/0 gaddr 999.999.99.32/17947 laddr 999.999.99.32/17947
