Routing issue with dst nat - ASA

[a.maldonado]

Hello! and I hope someone can help me.

As part of delivering a service to our customers I had the need to nat their destination (as well as our source). However, two different customers wanted me to nat their end and later noticed they use a similar IP subnet. The only difference being in the length of the mask. Then, when I troubleshooted one of them I discovered the two entries in the routing table of the firewall (see below). Note: The root cause of the problem turned out to be something else and not these duplicated routes.

This is not a problem at present because the subnets are different and the hosts within those subnets are different. However, I wonder what would have happened if both had wanted me to send packets to the same real IP. Let’s say 192.168.100.2, which is within both IP prefixes.

Cisco_ASA# sh route | i 192.168.100.

V        192.168.100.0 255.255.255.0

V        192.168.100.0 255.255.255.248

 Could someone tell me how I solve this issue, if there is a solution? Please see Phase 2 configuration of their  VPNs attached.

Other info:

Cisco Adaptive Security Appliance Software Version 9.16(2)

SSP Operating System Version 2.10(1.162)

Device Manager Version 7.16(1)150

Hardware:   ASA5516, 8192 MB RAM, CPU Atom C2000 series 2416 MHz, 1 CPU (8 cores)

Internal ATA Compact Flash, 8000MB

BIOS Flash M25P64 @ 0xfed01000, 16384KB

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-firewalls/211275-Configuration-Example-of-ASA-VPN-with-Ov.html

This can help you

MHM

[Rob Ingram]

@a.maldonado those "V" static routes are in the routing table because reverse route injection (RRI) configured under the crypto map sequences. You can remove them using the following:

no crypto map OUTSIDE_map 163 set reverse-route
no crypto map OUTSIDE_map 158 set reverse-route

You would also need to use Twice NAT to workaround the overlap.

[a.maldonado]

Hi @Rob Ingram  and thank you for your post.

If I remove the reverse route command, how does the FW know that the packet destined to the nated address 192.168.100.2 is destined for the customer using crypto map 163? If both customers were using the same /24 range and the same real server address 192.168.100.2. Do you know?

Regarding twice nat, I am already doing that and just by luck the source of the services is different for each customer so I that is why there are no conflicts but one of those services use the same source address for all customers and there could be a problem if I ever have two customers using the same real IP range and both happen to use the same address for the server.

[MHM Cisco World]

I run lab year ago and it work.

Can I see twice NAT you use ?

MHM

[MHM Cisco World]

If you do twice NAT correctly then last steps is 

Remove RRI from VPN 

Config static route for MAPPED IP not real IP toward the internet your use for vpn and NAT.

Note- one more point you need to use mapped IP in acl of VPN not real IP

That it' 

I am sure it will work

MHM

[a.maldonado]

Hi, thank you for your comments. The problem is the customers can't or do not want to nat their end. Hence, they use their real IP subnet for their crypto ACL and I have to do the same on my crypto ACL.

I can and will remove the RRI from the crypto maps

I already configure the static routes for the mapped addresses pointing to the ISP:

route OUTSIDE 10.241.242.8 255.255.255.248 ISP1 1

route OUTSIDE 10.240.209.24 255.255.255.248 ISP1 1

[MHM Cisco World]

The conflict is between two sites noy between you and other sites

Now 

NAT(inside'outside) static source  local-lan local-lan destiantion remote-real remote-mapped 

Acl will be 

Ip access-extende 100 permit local-lan remote-mapped 

Note:- this step need mandatory adjust the acl in peer

Route outside remote-mapped <next hop>

This must be done for only one site other no need

Thanks 

MHM

[a.maldonado]

Please see the nat statements that I am using for each customer:

This is for customer 1 crypto map 163

nat (any,OUTSIDE) source dynamic COMPANY_NET-GROUP-A NAT_COMPANY_HOST-X.X.X.201 destination static CUSTOMER_1_HOST-10.241.242.9 CUSTOMER_1_REAL_HOST-192.168.100.2

This is for customer 2 crypto map 158

nat (any,OUTSIDE) source static HOST1_172.16.252.10 NAT_HOST1-CUSTOMER_2_HOST-10.239.93.137 destination static CUSTOMER_2_HOST-10.240.209.25 CUSTOMER_2_REAL_HOST-192.168.100.30
nat (any,OUTSIDE) source static HOST2_172.16.252.20 NAT_HOST2-CUSTOMER_2_HOST-10.239.93.138 destination static CUSTOMER_2_HOST-10.240.209.25 CUSTOMER_2_REAL_HOST-192.168.100.30
nat (any,OUTSIDE) source static SERVER-NET_GROUP NAT_POLLING-CUSTOMER_2_HOST-10.239.93.139 destination static CUSTOMER_2_HOST-10.240.209.25 CUSTOMER_2_REAL_HOST-192.168.100.30
nat (any,OUTSIDE) source dynamic MANAGEMENT-NET_GROUP NAT_GNUKA_MGSrv-CUSTOMER_2_HOST-10.239.93.140 destination static CUSTOMER_2_HOST-10.240.209.25 CUSTOMER_2_REAL_HOST-192.168.100.30

[Rob Ingram]

@a.maldonado those V routes are used to redistribute via a routing protocol so connected devices learn the route is via the VPN, it is optional not a requirement (it depends on your environment). As long as the traffic is routed to the ASA, the ASA will check the crypto ACL and determine whether the traffic should be encrypted and route it via the correct tunnel.

[tvotna]

@a.maldonado, @Rob Ingram is absolutely right. It's ok that real addresses of two remote subnets overlap so long as your traffic is routed to the correct egress interface where crypto map lives. The only requirement in this case is to NAT your local subnets in a unique way for each of those tunnels, because crypto ACLs must not overlap. This is just to clarify a bit.

[a.maldonado]

Excellent Rob, thank you. I understood the explanation regarding the V in the routing table.

But what I am concerned is that I could potentially have 2 customers with the same crypto ACL as per below. In this case how does the firewall knows what is the correct tunnel?

access-list OUTSIDE_cryptomap_163 extended permit ip object-group CRYPTO_COMPANY_NET-GROUP-A object-group CRYPTO_CUSTOMER_1_NET-GROUP-A

access-list OUTSIDE_cryptomap_158 extended permit ip object-group CRYPTO_COMPANY_NET-GROUP-A object-group CRYPTO_CUSTOMER_2_NET-GROUP-A

where CRYPTO_CUSTOMER_1_NET-GROUP-A and CRYPTO_CUSTOMER_2_NET-GROUP-A will have the same 192.168.100.0 as part of the group because this is their interesting traffic (real subnet the customers are using because they don't want or they can't nat it). In this case, how does the firewall knows what crypto map the signal is for? if the source (CRYPTO_COMPANY_NET-GROUP-A) is exactly the same for both customers.

My nat statements for the two different customers abobe will look like this:

This is for customer 1 crypto map 163
nat (any,OUTSIDE) source dynamic COMPANY_NET-GROUP-A NAT_COMPANY_HOST-X.X.X.201 destination static CUSTOMER_1_HOST-10.241.242.9 CUSTOMER_1_REAL_HOST-192.168.100.2

This is for customer 2 crypto map 158
nat (any,OUTSIDE) source dynamic COMPANY_NET-GROUP-A NAT_COMPANY_HOST-X.X.X.201 destination static CUSTOMER_2_HOST-10.240.209.25 CUSTOMER_2_REAL_HOST-192.168.100.2

The only thing that ties the nat statement to the crypto map would be the nated destination (because 192.168.100.0 it is in the crypto ACL of both customers) so how does the ASA know what cryptomap to use?
I hope I am explaining myslef and also I wonder if I am doing this right? I thought I was until I saw the

[Rob Ingram · Accepted solution]

@a.maldonado perform NAT on your side, refer to the example to avoid the overlap.

nat (inside,outside) source static LOCAL LOCAL-XLATE-SPOKE1 destination static REMOTE-XLATE-SPOKE1 SPOKES-NETWORK
nat (inside,outside) source static LOCAL LOCAL-XLATE-SPOKE2 destination static REMOTE-XLATE-SPOKE2 SPOKES-NETWORK

Configure the crypto ACL with the translated subnets

access-list VPN-to-SPOKE1 extended permit ip object LOCAL-XLATE-SPOKE1 object SPOKES-NETWORKS
access-list VPN-to-SPOKE2 extended permit ip object LOCAL-XLATE-SPOKE2 object SPOKES-NETWORKS

[a.maldonado]

Thank you all, especially @Rob Ingram, for your time and sharing your knowledge. I finally got it. I also have to nat the source to make the difference as to which egress interface and crypto map to use.