Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Unable to pass traffic between ASA Site to Site VPN Tunnel

Hi,

I am having issues passing traffic between two ASA firewalls. The VPN tunnel is up with one dynamic IP and one Static IP. I have attached a diagram of the VPN connection. I am unsure where the issue lies and what to check next. I think i have all the routes and access-lists in that are required.

I have also attached the config of the ASA5505 and the ASA5510.

This is the first time I have set up a VPN connection so any guidance would be greatly appreciated.

Thanks

Adam

1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

Hi,

Hi,

 

With regards to your Remote Site ASA configuration notice that you have not added the Central Site internal networks to the L2L VPN configurations at all therefore the traffic does not go through the VPN.

 

access-list outside_1_cryptomap extended permit ip 10.1.1.0 255.255.255.128 10.182.226.0 255.255.*.* 


access-list exempt extended permit ip 10.1.1.0 255.255.255.128 10.182.226.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 10.182.0.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 192.168.170.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 192.168.172.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 140.15.0.0 255.255.*.* 

 

Take a look at the above ACL configurations. The "exempt" ACL is used in the NAT0 configurations and tells the ASA which traffic to exempt from NAT. The "outside_1_cryptomap" ACL is used to tell between which subnets the traffic should be using the L2L VPN connection.

 

So in short on the Remote Site ASA these ACLs should be indentical. Make the additions to the L2L VPN ACL and try again.

 

I would also stress that make sure that the Central Site ASAs L2L VPN ACL contains the same networks. Naturally the ACL on the Central Site will have its internal subnets as the source and the Remote Sites LAN as the destination.

 

Thw output of "show crypto ipsec sa" shows you that only the SA between the Central Site link network and the Remote Site LAN has been established. Others have not formed as the configuration is lacking ATLEAST on the Remote Site ASA. Might also be the Central Site.

 

- Jouni

 

31 REPLIES

Hi Adam, How you want to

Hi Adam,

 

How you want to access the site to site network? because i see some of the encryption domain in public network and some of them are in private network... also i see both the ends you are using dynamic peer.... that should not be the problem.... just get me the information, what would be the encryption domain on both the ends.....

 

Regards

Karthik

New Member

I would like to have the

I would like to have the affected site pass straight through the tunnel into the main internal network picking up an IP subnet which is routable on the internal network. This will be a 4G Backup Solution for when we have a network outage at a site. On the ASA 5510 there is also a Remote VPN set up which is working for PDA's which isn't included in this scope. There is a Dynamic IP for the ASA 5505 because it is connecting via the 4G. The ASA5510 has a static external IP which is 105.255.242.1. I have set the ASA5505 to Originate Only to get the VPN up. I think i am getting confused with the IP's and the natting section. 

On the ASA5505 I have an internal IP of 10.1.1.0/24 and a destination address of 192.123.123.128/25. On the ASA5510 I have the opposite set up.  

Hope this helps.

Adam

New Member

Hi,Was just in the

Hi,

Was just in the neighbourhood. :-)

 

Looks like you are missing NAT exemption on the ASA 5505.

 

Can you send the output of "show crypto isakmp sa" and "show crypto ipsec sa".

 

Thanks,

Nehmaan

New Member

Both show outputs are

Both show outputs are attached. 

Thanks

New Member

You need to add the NAT

You need to add the NAT exemption on the ASA 5505. You have already done this on the ASA 5510.

 

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/nat_bypassing.html

 

A good tool for troubleshooting is the "packet-tracer" command.

 

Thanks,

Nehmaan

 

New Member

Based on the link you have

Based on the link you have sent i have added the following commands. 

#access-list exempt permit ip 10.1.1.0 255.255.255.128 192.123.123.128 255.255.255.128

#nat (inside) 0 access-list exempt

Is it the internal subnet (10.1.1.0 255.255.255.128) or the patted IP of the outside interface of the ASA 5505 which is 192.168.0.50 that should be within the NAT exemption?

ciscoasa# show running-config nat
nat (inside) 0 access-list exempt
nat (inside) 1 0.0.0.0 0.0.0.0

Thanks

Adam

New Member

Hi, No it should be the

Hi,

 

No it should be the internal networks only.

 

You can run a ping from an internal PC from one site to the other to test.

 

Thanks,

Nehmaan

New Member

Okay that has been done but i

Okay that has been done but i am still struggling to gain a connection through the tunnel to the internal network.

Packet Tracer says that from my internal network IP on the ASA 5505 i am able to send traffic to an internal IP on the ASA5510 but i am still unable to get any traffic down the tunnel. 

Is there anything else to try?

Thank you for the help so far guys. 

Adam

 

New Member

Hi Adam, Can you please let

Hi Adam,

 

Can you please let me know which source IP you are pinging from and to which destination IP address.

 

I'm a little confused here. Are you trying to ping the VPN clients at the headend ASA or remote subnets that sit behind the headend ASA ?

 

Your VPN is up and I don't see any issues there. I believe your issues lies with your subnets and possiblly NAT configuration.

 

I would also add inspect icmp under the default policy-map.

 

On the ASA 5505 you have the following:

interface Vlan1
 nameif inside
 security-level 100
 ip address 10.1.1.1 255.255.255.0 

 

The ACL you sent me:

access-list exempt permit ip 10.1.1.0 255.255.255.128 192.123.123.128 255.255.255.128

 

The VPN will not work for the whole /24 if you use a /25.

 

Thanks,

Nehmaan

New Member

If it makes it easier I have

If it makes it easier I have attached a configuration for the headend ASA and a remote ASA for you.

 

Headend would have a static IP, Remote ASA would have a dynamic IP.

 

Regards,

Nehmaan
 

New Member

I am pinging from a laptop

I am pinging from a laptop plugged into the ASA5505 which has picked up a DHCP Address within the 10.1.1.0/25 network (10.1.1.10) to the core router within the internal network. Obviously I cannot ping anything on the 192.123.123.128/25 subnet because nothing is connected. 

I have added 'inspect icmp' into the default policy-map.

Sorry that is my fault causing the confusion. I have changed the 10.1.1.0 to a /25 subnet instead of /24. This has been changed throughout the firewall so it is all consistent.

Thanks

Adam 

is it started to work for you

is it started to work for you now?

 

Regards

Karthik

New Member

Unfortunately not. I have

Unfortunately not. I have double checked to make sure there isn't a silly mistake with the subnets etc but there isn't. I will have a look at the txt files Nehmaan has sent and see if anything is missing or different. 

Thanks

Adam

New Member

I have attached a packet

I have attached a packet trace from an Internal IP on the remote ASA (10.1.1.10) to the VPN subnet on the headend ASA (192.123.123.135). Hopefully something may show up for you guys. 

Thanks

Adam

Hi Adam, 1st thing.... one

Hi Adam,

 

1st thing.... one end you have the 10.1.1.0 network, which is a private range.... other end you have 192.123.123.128, which is a public Network..... so you need to do NATing and you should create your NAT for 10.1.1.0 to go with the public ip when it goes out.... and more over your crypto map acl should be between the public ip segments.....

 

Regards

Karthik

New Member

Hi Adam,

Hi Adam,

 

I agree with Karthik and Jouni. For the NAT exemption source and destination should be your internal subnets. There isn't anything you need to do with the outside IP address here apart from set the "peer" on the crypto statements.

 

I don't believe you need any route commands to get this working.

 

Your packet-tracer looks fine.

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

 

If the 192.123 is your internal subnet have a PC setup or something to see if you can ping etc...

 

I also assume that you have the end devices on the inside correctly configured as in the default-gateway.

 

Regards,

Nehmaan

New Member

Hi Adam, You mentioned the

Hi Adam,

 

You mentioned the following:

 

Obviously I cannot ping anything on the 192.123.123.128/25 subnet because nothing is connected. 

 

I assume you mean nothing on the far end ASA has any devices on the 192.123.123.128/25 subnet. If this is the case then yes it won't work anyway.

 

You could use "packet-tracer" here and do a "show nat" to see if you get any hits on the counter.

 

Thanks,

Nehmaan

New Member

yes correct. My understanding

yes correct. My understanding is when a device from the 10.1.1.0/25 subnet connects via the tunnel it will pick up at 192.123.123.128/25 address to route on the internal network. 

I have done a show nat on the remote ASA but it is only showing hits on the outside interface PAT. 

Thanks

Adam

Super Bronze

Hi, I will stick my hands

Hi,

 

I will stick my hands/head into this problem also :)

 

I still have a bit confusion on what you are trying to achieve here. You are talking about subnets 10.1.1.0/25 and 192.123.123.128/25

 

You mention in one post that the 192.123.123.128/25 subnet is the destination subnet to which the subnet 10.1.1.0/25 connects to? If so where is this subnet 192.123.123.128/25 located at? I don't see any "route" configuration on the Central Site ASA that would match this subnet. Again, where is this subnet supposed to be located at?

 

I checked one of your "packet-tracer" output from the Remote Site ASA and that tells us that the correct NAT Exempt is matched and that the L2L VPN connection is up. So I don't see any problems there.

 

At this point I presume that the problem is at the Central Site. Please let us know where the subnet 192.123.123.128/25 is located and I am pretty sure we can solve this problem. The problem might just be missing the "route" command on the Central Site or maybe there is some bigger missunderstanding here.

 

- Jouni

New Member

Hi Jouni,Thanks for getting

Hi Jouni,

Thanks for getting involved :-).

My aim is to VPN an affected site into our internal LAN using site-to-site VPN. From what I have read, you require an IP subnet on both sides. So i have 10.1.1.0/25 on the remote ASA and I have created a subnet 192.123.123.128/25 on the main ASA. This network only exists within the VPN and ACLs on the ASA. I have a route on the main router which directs traffic for 192.123.123.128/25 to the ASA firewall. As this is a learning curve for me I may be doing something wrong with the IP subnet on the main ASA. 

Hope this makes it a bit clearer what I am trying to accomplish and what i have done so far. 

Thanks

Adam

 

Super Bronze

Hi,

Hi,

 

So from what I understand your dont actually have the subnet 192.123.123.128/25 anywhere in your Central Sites internal network?

 

The configuration you have tells the ASAs involved that the Remote Site has the subnet 10.1.1.0/25 and the Central Site has the subnet 192.123.123.128/25 and traffic between these subnet should be forwarded through the L2L VPN connection.

 

With that in mind for any connectivity to be possible between the subnets the ASA has to have (one of the below must be true)

  • An interface where the subnet 192.123.123.128/25 is directly connected/configured
  • A route for the subnet 192.123.123.128/25 towards some other routing device (like some internal router)
  • The subnet 192.123.123.128/25 has been configured as a NAT subnet for some real local subnet

 

So judging by your last reply this network is not actually located anywhere. Its only configured as the local subnet for the Central Site on the L2L VPN. Therefore when the traffic from the Remote Site arrives through the L2L VPN connection the ASA probably matches the traffic to the "nat" configuration below

 

nat (InternalInterface,OriginBroadband) source static 4G_VPN_POOL 4G_VPN_POOL destination static 4G_ASA_Network 4G_ASA_Network no-proxy-arp route-lookup

 

And since ASAs "nat" configurations are able to override the routing table on the ASA this means that the traffic will be forwarded towards "InternalInterface" or it might be droppe because of some configuration related issue.

 

So the real question now is what are the actual hosts/subnets on the Central Site which need connectivity to the Remote Sites subnet 10.1.1.0/25? No connections are possible in the current state as there are no actual hosts in the subnet 192.123.123.128/25 and its not really configured anywhere in the network where the Central Site ASA could pass traffic to.

 

- Jouni

 

 

New Member

Hi Jouni, What I have done

Hi Jouni, 

What I have done now is change the network 192.123.123.128/25 to the internal network of the ASA firewall. I am now able to ping the internal IP of the firewall, the default gateway and anything else on the subnet.

What I am unable to do now is ping anything off of that subnet that is internal.

I am also unable to ping from the internal network to 10.1.1.0/25 network. 

I have set up a route on the internal router for 10.1.1.0/25 next hop is the internal IP of the ASA. I am unsure on exactly what routes i need on the two firewalls to make sure that the traffic goes down the tunnel. 

Thanks

Adam

Super Bronze

Hi,

Hi,

 

You have to make sure that both Sites ASAs have all the subnets included in the ACLs used in the L2L VPN configurations (crypto map). This tells the ASAs between which subnets traffic should use the L2L VPN connection.

 

Remember also that the Remote Site ASA needs NAT0 configurations for each destination subnet on the Central Site WHICH YOU ADD to the ACLs used in the L2L VPN configurations.

 

You previously mentioned adding this NAT0 configuration on the Remote Site

 

access-list exempt permit ip 10.1.1.0 255.255.255.128 192.123.123.128 255.255.255.128


nat (inside) 0 access-list exempt

 

So you will need a new ACL line (using the same ACL name ofcourse) for each destination subnet that you want to connect to through the L2L VPN from the Remote Site.

 

Lets say you wanted to add a destination network 172.16.1.0/24 to the L2L VPN configuration on the Remote Site and this network is located at the Central Site then you would add the following line to the NAT0 ACL

 

access-list exempt permit ip 10.1.1.0 255.255.255.128 172.16.1.0 255.255.255.0

 

I find it a bit strange also that your Central Site ASA does not have any Dynamic PAT configurations for Internet traffic? Or this purely a VPN device and normal Internet traffic uses some other device?

 

If the Central Site is just a VPN device and you dont want to NAT any networks then you really dont need to add any NAT0 configurations on that side. NAT0 configurations are usually added to bypass the normal Dynamic PAT configurations (just like its done on the Remote Site ASA) but if your Central Site ASA does not need any Dynamic PAT configurations (as there is none at the moment) then you wont need to add any NAT0 configurations.

 

Also with regards to the ICMP testing.  You say it does not work from Central Site to Remote Site? Notice that you have the following at the end of your ACL (even though there would still be implicit deny without it)

 

access-list InternalInterface_access_in extended deny ip any any 

 

Just make sure that before this rule there is a rule that allows traffic from the Central Site internal network you want to the destination network at the Remote Site.

 

With regards to the routing you mention, just make sure that the Central Site ASA has routes for all the internal networks at that site that need to use the L2L VPN.

 

Hope I made any sense. Might have missed something.

 

- Jouni

New Member

I have added in the internal

I have added in the internal networks that the remote network will need access to. Unfortunately this hasn't allowed me to get further than the default gateway.

The ASA Outside interface has one external IP which I believe does PAT but it is not out main Internet connection. It is really only used for VPN and for Fire/Intruder alarms. 

I have checked my ACL's. I have got any any ip on the remote ASA.

On the central ASA I have got the ACLs to allow access in and out for the two networks between eachother. 

Thanks

Adam

 

Super Bronze

Hi, I think at this point it

Hi,

 

I think at this point it would probably best if you shared the current configurations of the devices as you might have made multiple changes compared to the original shared configurations.

 

In addition I would like to know what you mean by the second sentence. From what source IP address are you testing connecivity and to which destination IP address are you trying? What are you using to test connecitivity? I would sometimes advice against using ICMP/Traceroute as they have a bad habit of getting blocked on the way especially with firewalls. Which side default gateway are you talking about and what IP address is it? On what device is that IP address?

 

Since your Central Site network probably contains another device towards which the default route is pointing inside the network I would suggest checking the routing towards 10.1.1.0/25 all the way from the host to the VPN ASA. Check that the traffic destined to 10.1.1.0/25 is not actually being routed wrong somewhere along the way.

 

After you have tested some connections can you also share with us the output of "show crypto ipsec sa" from the Remote Site ASA and also mention the source/destination IP address of the test.

 

- Jouni

New Member

In addition to Jouni's

In addition to Jouni's comments, Can you please send a "show nat detail" for us please.

 

Thanks,

Nehmaan
 

New Member

I am using Ping to check

I am using Ping to check connection. I am pinging from a laptop connected to the remote ASA (10.1.1.11) to the internal gateway of the Central ASA (10.182.226.1). I have no problem getting to that internal subnet but cannot get further. 

I have attached what was requested for the Remote ASA. Central ASA to follow. 

Thanks

Adam

Super Bronze

Hi,

Hi,

 

With regards to your Remote Site ASA configuration notice that you have not added the Central Site internal networks to the L2L VPN configurations at all therefore the traffic does not go through the VPN.

 

access-list outside_1_cryptomap extended permit ip 10.1.1.0 255.255.255.128 10.182.226.0 255.255.*.* 


access-list exempt extended permit ip 10.1.1.0 255.255.255.128 10.182.226.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 10.182.0.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 192.168.170.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 192.168.172.0 255.255.*.* 
access-list exempt extended permit ip 10.1.1.0 255.255.255.128 140.15.0.0 255.255.*.* 

 

Take a look at the above ACL configurations. The "exempt" ACL is used in the NAT0 configurations and tells the ASA which traffic to exempt from NAT. The "outside_1_cryptomap" ACL is used to tell between which subnets the traffic should be using the L2L VPN connection.

 

So in short on the Remote Site ASA these ACLs should be indentical. Make the additions to the L2L VPN ACL and try again.

 

I would also stress that make sure that the Central Site ASAs L2L VPN ACL contains the same networks. Naturally the ACL on the Central Site will have its internal subnets as the source and the Remote Sites LAN as the destination.

 

Thw output of "show crypto ipsec sa" shows you that only the SA between the Central Site link network and the Remote Site LAN has been established. Others have not formed as the configuration is lacking ATLEAST on the Remote Site ASA. Might also be the Central Site.

 

- Jouni

 

New Member

Hi Jouni,Thanks for that, I

Hi Jouni,

Thanks for that, I am now able to get to the other internal networks.

I have another question now though. Everything is working with IP's but how can i allow DNS through the VPN?

Really appreciate the help from you all. 

Thanks

Adam

14215
Views
35
Helpful
31
Replies