Connection from one Site-To-Site VPN to another Site-To-Site VPN not working

[Marcel F.]

Hi,

We have a ASA at our HQ which has several Site-To-Site VPN to our customers.

So, now we have also a new small brach office with also a ASA
This ASA has a Site-To-Site VPN to our HQ

Now, the branch office wants to connect to hosts behind one of the customer VPN.
And this does not work.
All Networks inside our HQ are perfectly reachable from the branch office.

I see the requets from the brance office at my HQ ASA but for me, it seems that the nat does not work for this connect, but i don't know why.

Here is the relevant config of the HQ ASA

---snip---
object network VPN_CUSTOMER001_natip
host 172.20.12.49


object-group network VPN_CUSTOMER001_dest_list
network-object host 10.0.104.112
network-object host 10.0.104.113
network-object host 10.0.104.114
network-object 10.244.0.0 255.252.0.0


object-group network VPN_CUSTOMER001_allowed_local_networks_list
network-object 10.8.5.0 255.255.255.0
network-object host 10.2.60.14
network-object 10.56.0.0 255.255.255.0
network-object 10.49.0.0 255.255.252.0


access-list outside_cryptomap_7 remark Customer001
access-list outside_cryptomap_7 extended permit ip 172.20.12.48 255.255.255.252 10.0.104.0 255.255.252.0
access-list outside_cryptomap_7 remark Customer001
access-list outside_cryptomap_7 extended permit ip 172.20.12.128 255.255.255.192 10.0.104.0 255.255.252.0
access-list outside_cryptomap_7 remark Customer001
access-list outside_cryptomap_7 extended permit ip 172.20.12.128 255.255.255.192 10.244.0.0 255.252.0.0
access-list outside_cryptomap_7 remark Customer001
access-list outside_cryptomap_7 extended permit ip 172.20.12.48 255.255.255.252 10.244.0.0 255.252.0.0
access-list outside_cryptomap_7 remark Customer001
access-list outside_cryptomap_7 extended permit ip 172.20.12.48 255.255.255.252 host 10.3.3.170

nat (inside,outside) source dynamic VPN_CUSTOMER001_allowed_local_networks_list VPN_CUSTOMER001_natip destination static VPN_CUSTOMER001_dest_list VPN_CUSTOMER001_dest_list

---snap---

HQ ASA - Request from HQ (working)
6 Apr 06 2017 19:47:40 302013 10.8.5.154 60394 10.244.8.175 3389 Built outbound TCP connection 2701928 for outside:10.244.8.175/3389 (10.244.8.175/3389) to inside:10.8.5.154/60394 (172.20.12.49/60394)

HQ ASA - Request from branch office (not working)
6 Apr 06 2017 19:57:20 302013 10.56.0.10 62510 10.244.8.175 3389 Built inbound TCP connection 2702704 for outside:10.56.0.10/62510 (10.56.0.10/62510) to inside:10.244.8.175/3389 (10.244.8.175/3389)

Any ideas??

Thanks

[Richard Burts]

We do not have enough information yet to be sure of the issue or how to solve it. Please give us a clear understanding of what addresses are used at the new branch office and what addresses are used at the customer site.

You seem to think that the problem has to do with NAT. I suspect that while NAT may be part of the problem it is not all of the problem. Based on your description I would guess that the underlying issue is that for the branch office to communicate with the device at the customer site that both the branch office and the customer site must include each other in their access list which identifies traffic to be encrypted (the access list used in the crypto map) and those addresses also need to be in the matching access lists at HQ.

HTH

Rick

[Marcel F.]

Hi,

OK, sorry.

subnet of branch office: 10.56.0.0/24

hosts on customer site: eg. 10.244.0.0/14 (VPN_CUSTOMER001_dest_list)

All requests to the customer will be masqueraded with 172.20.12.49 (VPN_CUSTOMER001_natip)
So the customer site does not have to add our subnets

Only we will do this. Our allowed subnets are the networks/hosts inside of VPN_CUSTOMER001_allowed_local_networks_list (eg 10.8.5.154 or 10.56.0.10)

So, according to the two logfile examples requests form 10.56.0.0/24 will be not masqueraded .. as far as I read it correct.

Thanks,
Marcel

[Marcel F.]

ah, I think I just saw the real problem....

according to the log example the request from the branch office (10.56.0.10) goes from the outside-interface to the inside-interface.
But it should stay on the outside-interface to reach the customer site (10.244.8.175)....

But same-security-traffic permit inter-interface and same-security-traffic permit intra-interface are activated on the HQ ASA.