12-08-2011 10:41 AM
Hello,
I am working on a site that has recently added a new subnet and I am unable to ping any of the stations on this new network. I have configured an Exempt NAT rule just the same as the rules allowing access to other networks. I have a feeling the problem is in the Site-to-Site VPN configuration since the new subnet is at the primary location over the VPN.
In the site-to-site configuration I added the new subnet to the list of "Remote Networks" and I still can't communicate with any of the devices on the network. If I go to the main site I have no problems so it appears to be related to the VPN or a configuration in the ASA on that site.
A port scan shows that all the traffic is "filtered" so somewhere either the site ASA or the main ASA is blocking the traffic.
Any tips on how I can narrow down the problem would be appreciated. Thanks!
12-08-2011 11:01 AM
A site to site VPN will need to have the new subnet allowed in the crypto map at each end. That's in the form an access-list which is defined and then applied to the tunnel. Without the cryptomap being properly defined, you would be seeing an error due to IKE Phase 2 SAs being unable to establish. That's assuming routing and everything else is set up correctly.
Are you sure the packets destined for the new subnet are getting to the ASA? If they are, have you tried using the packet tracer (cli tool or option in ASDM - "Tools, Packet Tracer") tool to look at the path the packets would / should take through the ASA?
12-12-2011 08:26 AM
Ok I did see some entries that were needed in the cryptomap, I mirrored the working site configuration. However the packet trace is showing that the traffic is being denied at the Access List of the remote site's ASA (the site the traffic is leaving from). So their ASA is not even letting the traffic out to the VPN tunnel.
So I configured an Allow from Inside Network to the Remote network rule on the inside interface and it is still dropping the traffic.
12-12-2011 08:47 AM
The ASA Packet Tracer utility will tell you which access-list blocks the traffic.
12-12-2011 08:50 AM
It takes me to the inside interface. So I have created a rule to allow any traffice to the network I am trying to ping 192.168.5.0/24 and this rule is at the top, however it is still showing me that is the rule blocking the traffic.
12-12-2011 08:57 AM
Can you provide the relevant script lines? Your syntax should look something like:
access-list acl_in extended permit icmp any 192.168.5.0 255.255.255.0
access-group acl_in in interface inside
12-12-2011 09:23 AM
Unfortunatly I am only using ASDM to configure the ASA.
Here are the rules I have though
Source/Dest/Service/Action
Inside/Wireless/ip/Permit
any/Inside/ip/Deny
any/any/ip/Permit
any/any/ip/Deny
It does say that an Implicit rule is the cause in the packet trace. The only Implicit rule is the very last one which is un-editable.
12-12-2011 09:39 AM
If you're hitting the implicit deny that most likely means one of two things:
1. the allow statement that you thought should take effect is incorrectly formed, or
2. the source for your traffic is not what you expect it to be (and is thus not being allowed by your allow statement).
You can check #2 by doing a packet capture while generating the traffic in question. Once you confirm the traffic to/from IPs are as expected, doublecheck against the allow statement, thus validating #1.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide