ASA 5505 Series, Unable to access new subnet

Unanswered Question
Dec 8th, 2011
User Badges:

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Marvin Rhoads Thu, 12/08/2011 - 11:01
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

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?

RogueParticle Mon, 12/12/2011 - 08:26
User Badges:

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.

Marvin Rhoads Mon, 12/12/2011 - 08:47
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

The ASA Packet Tracer utility will tell you which access-list blocks the traffic.

RogueParticle Mon, 12/12/2011 - 08:50
User Badges:

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.

Marvin Rhoads Mon, 12/12/2011 - 08:57
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

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

RogueParticle Mon, 12/12/2011 - 09:23
User Badges:

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.

Marvin Rhoads Mon, 12/12/2011 - 09:39
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 Firewalling, Network Management, VPN

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.

Actions

This Discussion