Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

unable to access subnets on the outside interface

Status
Not open for further replies.

mktck

Technical User
Feb 9, 2009
31
SG
Hi,

I have 2 ASAs. IPSec tunnel is established between them. ASA5505 - ASA5520.

At the moment, the Inside interface of ASA5505 can ping the Internal interface of ASA5520. I have a range if servers with IP 63.237.x.x/24 which is on the same subnet of the External interface of ASA5520(63.237.x.40/24). I am unable to ping this at all.

The tunnel peer is pointing fro ASA5505 to 63.237.x.40 but crypto map allows only the ASA5520 Internal IP subnet to tok to the ASA5505 Inside IP subnet. I have tried to put an allow for the 63.237.x.x/24 subnet to the ASA5505 Inside IP subnet and vice versa, but it don't seems to go through.

Should I be setting and additional tunnel for this for should I edit the cryptomap?

Please refer to my Show Runs on this thread.:
 
Your nat exemption ACLs are cattywompus.
Delete these from the 5505
access-list inside_nat0_outbound extended permit ip 67.148.x.x 255.255.255.252 63.237.x.x 255.255.255.0
access-list inside_nat0_outbound extended permit ip interface outside 63.237.x.x 255.255.255.0
access-list inside_nat0_outbound extended permit ip interface inside 63.237.x.x 255.255.255.0

and kill this one for security
access-group outside_access_in in interface outside
access-list outside_access_in extended permit ip any any

Now fro the 5520 - Start the VPN config over. In short this should be a mirror image of the 5505

access-list inside_nat0_outbound extended permit ip 172.17.x.0 255.255.0.0 10.10.x.0 255.255.255.0
access-list outside_1_cryptomap extended permit ip 172.17.x.0 255.255.0.0 10.10.x.0 255.255.255.0

nat (inside) 0 access-list inside_nat0_outbound

crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs
crypto map outside_map 1 set peer 67.148.x.x
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map 1 set security-association lifetime seconds 28800
crypto map outside_map 1 set security-association lifetime kilobytes 4608000
crypto map outside_map interface outside
crypto isakmp enable outside

Now make sure all the vpn tunnel options match on both sides or it will not go - lifetimes (Kb and/or seconds), IKE settings, tunnel group attributes, etc.

There is so much going on with the 5520 I don't even know where to start. Is all of it necessary? Functioning? Best idea is to find out what you need "only" and kill the rest. Maybe even start from scratch and only add what you need one thing at time so you can troubleshoot when it breaks.


Brent
Systems Engineer / Consultant
CCNP, CCSP
 
Hi Brent,

Would you kindly explain the removal of these lines and how it will help in my situation? I cannot test it at the moment but would like a better understanding before execution. Thank you.

access-list inside_nat0_outbound extended permit ip 67.148.x.x 255.255.255.252 63.237.x.x 255.255.255.0
access-list inside_nat0_outbound extended permit ip interface outside 63.237.x.x 255.255.255.0
access-list inside_nat0_outbound extended permit ip interface inside 63.237.x.x 255.255.255.0
 
Sure thing -

access-list inside_nat0_outbound extended permit ip 67.148.x.x 255.255.255.252 63.237.x.x 255.255.255.0
access-list inside_nat0_outbound extended permit ip interface outside 63.237.x.x 255.255.255.0
access-list inside_nat0_outbound extended permit ip interface inside 63.237.x.x 255.255.255.0 /i] -
To decipher them - the beginning is the source and the end is the destination. The networks in these lines never pass through the pix's. They are not natted anyway. Those IPs are endpoints or external to the pix's. They aren't helping and most likely mucking things up.

The bigger problem was the 5520. The ACLs and crypto maps need to be redone.


Brent
Systems Engineer / Consultant
CCNP, CCSP
 
Hi, I have removed the useless lines. No positive result so far. I can ping 63.237.x.40 of the External interface of ASA5520 from a host on the Inside interface of the ASA5505. I can ping 63.237.x.40 from 63.237.x.20 (my exchange server), but can't reach 172.17.x.40 (Internal interface of ASA5520). A tracert from 63.237.x.20 show it still travel via the older path which is still LIVE. What i did on the 172.17.x.x network is inserting a static path into hosts of the 172.17.x.x to travel via 172.17.x.40 towards my ASA5505. I am wondering is it is possible to do the same on the 63.237.x.x network.
 
Like I said, the previous was just cleaning things up. You need to tackle the 5520.

Do you have a diagram of the topology (all internal networks, external, DMZ, etc.?) As I understand, the exchange server is outside the ASA. What is the older path??

Brent
Systems Engineer / Consultant
CCNP, CCSP
 
Hi Brent,

Please don't laugh at me, but I do not have the topo map at all. Futhermore, my counterparts in the remote site handling the 5520 are too busy to assist as well. I am working on the 5505 site.

From my observation by RDP into the 5520 office site, the Exchange server gateway is 63.237.x.1. A tracert from the Exchange server to my current live network shows the icmp travel to 172.17.x.1, to a convitiy box 172.17.x.50, then reaching my current network. I tried pushing a static route to my new network by using Windows route command to 172.17.x.40 but it says tat IP does not reside on the same network. But, the Exchange server can ping the 63.237.x.20, which is the External Interface of the 5520.

I telnet into 63.237.x.1 and confirm that it is a router, and 172.17.x.50 and confirm its a contivity box. This is the old network.

I have been trying and asking around if I am able to get my exchange server to tok to the new network, but no one seems to get it. Maybe you can advise?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top