Unable to pass traffic between ASA Site to Site VPN Tunnel

[Adam Handley]

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

[nkarthikeyan]

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

[nehmaan123]

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

[nehmaan123]

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

[Adam Handley]

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

[Jouni Forss]

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

[Adam Handley]

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

[Jouni Forss]

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

[Adam Handley]

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

[Jouni Forss]

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

[Adam Handley]

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

[Jouni Forss]

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

[nehmaan123]

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

Thanks,

Nehmaan
 

[Adam Handley]

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

[Jouni Forss · Accepted solution]

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

[Adam Handley]

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