I am trying to use the Cisco SDM to configure a site-to-site vpn for an 1841 on a T1 directly to a 871 on Cable. As SOON as I save the quick configuration on one of the routers, the pinging ability immediately goes down between the two. But, I can still access web and ping everything else on the web when this happens. As soon as I delete the VPN site-to-site configs, pinging and managment access works fine. The Cable connection has a xx.xxx.xxx.33 with a subnet mask of 255.255.255.224 or a /27 The T1 has a xx.xxx.xxx.238 with a subnet mask of 255.255.255.252 or a /30. Is this the problem? How do I get these to talk or make the VPN work? After looking over the ACLs the wizard creates, it does:
access list 100 permit ip xx.xxx.xx.236 0.0.0.3 xx.xxx.xxx.32 0.0.0.31
but a few lines below the ipsec remarks, it does a:
access list 102 deny ip xx.xxx.xx.236 0.0.0.3 xx.xxx.xxx.32 0.0.0.31
Is this correct?
Any help would be greatly appreciated! I am trying to get this VPN working by the close of day! I can post full configs of both if needed.
I am not sure yet what the issue is, but I am confident that the subnet masks are not the problem. Since the two devices are not directly connected and are not members of the same subnet, then their subnet masks are entirely unrelated.
I am not sure what your question is about the access lists. It looks like there are two access lists (100 and 102) with the same set of addresses but 100 permits the addresses while 102 denies the addresses. Depending on what the access lists are used for (perhaps identifying interesting traffic for IPSec or denying traffic for address translation, or something else) it is quite likely that what is configured is correct.
It might allow us to give you more help if you provide more information. In particular it would be helpful to see configs from the routers.
Whew! Finally got it working. I am not sure exactly what it was, but I removed all of the old acl references, ipsec and crypto maps and started on both router ends from scratch. Thanks for the quick response though guys.
NOW, I have a few other issues. The VPN connection shows ok on both sides, I can ping the interfaces from both sides instead of it going down now. Problem is, I have vlan1 set as range 10.1.5.0 on the small 871 (only want those addresses assigned in the small branch). The machines are getting a dhcp address off of the small router and can ping the other 10.1.5s in the office and get web ALL the while the site-to-site being up. But, I cannot get the 10.1.5 machines to ping anything in corporate on 10.1.4, 10.1.2, etc. Is this a routing issue? How do I make a vlan that doesnt exist on one side talk to another? I will post both configs for review. Thanks again all!
Definitely sounds like a routing issue. The question is where you have the routing issue. Check the following
1. Can you reach the lan IP address of the remote router (i.e. 10.1.5.1, 10.1.4.1, 10.1.3.1, 10.1.2.1), pinging from the local router. If you can not, your provider may not be routing those lan address properly.
2. I did not notice any LAN ip address on 871 router. Is this an ommission while copying or an error?
3. Confirm that all systems have the right gateway configured on them.
1) No. from the corp router, I cannot ping 10.1.5.1 (the branch routers lan IP or vlan IP I have set)
2) Actually - the lan IP address of the 871 I thought was 10.1.5.1 (which you'll see is vlan 1)
3) I only have 1 gateway (the default routes) set in each router - which I am assuming is correct because they can resolve ips and names correctly for internet access, etc. They both use the format 0.0.0.0 0.0.0.0 x.x.x.33 and on the other router 0.0.0.0 0.0.0.0 x.x.x.237.
Other Notes: In the DHCP pool, I have the default-router that's being assigned as 10.1.5.1... is this correct? Should this be the wan IP?
I noticed that the current crypto maps allow ip permits... does "ip" mean any traffic? Because I was thinking it may be that I need to add "udp" or "tcp" or "icmp" to the lists. IE: pinging.
Thanks so much, I will get this thing hammered down by tonight!!
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...