ASA: Sending Traffic Destined for External IP Through Tunnel

[rschember1]

Hello --

Here's the situation I'm trying to figure out.

I have an ASA5506 at SiteA 10.10.1.0/24 and an ASA at SiteB 10.10.20.0/24 with a site-to-site VPN between the two sites. This works perfectly.

Also at SiteA, we have a managed service we pay for to allow us VPN connections with some customers at ManagedSiteC. This managed equipment listens on 10.10.1.9 and I don't have control of it. When we need to communicate with ManagedSiteC at IP 1.2.3.4, for the Windows server physically at SiteA, I just use a route statement on the server to use 10.10.1.9 as the gateway for traffic to 1.2.3.4. This works perfectly.

We have a DR server at SiteB that we would like to be able to communicate with ManagedSiteC 1.2.3.4 when needed. I worked with the network team that handles the ManagedSiteC equipment and got them to set up routes so I can ping 10.10.1.9 (the ManagedSiteC inside interface) from the SiteB 10.10.20.0 subnet.

My question is, how do I now configure the ASAs at SiteA and SiteB to allow me to communicate with 1.2.3.4 from SiteB? Essentially, I need to pass traffic from SiteB destined for 1.2.3.4 through the tunnel from 10.10.20.1 to 10.10.1.1 and have it then get routed to the managed router at 10.10.1.9, and vice-versa.

Thanks in advance,

--Rob

[Milos_Jovanovic]

Hi @rschember1,

First of all, you'll need to exand your crypto domain so that 1.2.3.4 and 10.10.20.0/24 can communicate over the tunnel between SiteA and SiteB (since 1.2.3.4 is on SiteAm from the standpoint of SiteB). You'll then need to tell SiteA ASA that it should route traffic for 1.2.3.4/32 to 10.10.1.9. For SiteB ASA, you need to tell it it is with SIteA (meaning that this traffic needs to entern the tunnel, so you'll probably route it to 'outside', asuuming this is where crypto is applied). On this managed router 10.10.1.9, you'll need to tell it that 10.10.20.0/24 is on ASA at SiteA.

BR,

Milos

[rschember1]

Hi Milos --

I'm still striking out here unfortunately. Here's what I did so far.

SiteA:

crypto map outside_map 20 match address ACL_20

access-list ACL_20 extended permit ip 10.10.1.0 255.255.255.0 10.10.20.0 255.255.255.0
access-list ACL_20 extended permit ip object obj-1.2.3.4 10.10.20.0 255.255.255.0

nat (inside,outside) source static obj-10.10.20.0 obj-10.10.20.0 destination static obj-10.10.1.0 obj-10.10.1.0 no-proxy-arp route-lookup

route outside 0.0.0.0 0.0.0.0 x.x.x.x 5
route inside 1.2.3.4 255.255.255.255 10.10.1.9 3

----------------

SiteB:

crypto map outside_map 1 match address ACL_01

access-list ACL_01 extended permit ip 10.10.20.0 255.255.255.0 10.10.1.0 255.255.255.0
access-list ACL_01 extended permit ip 10.10.20.0 255.255.255.0 object obj-1.2.3.4

nat (inside,WOW) source static obj-10.10.20.0 obj-10.10.20.0 destination static obj-10.10.1.0 obj-10.10.1.0 no-proxy-arp route-lookup

route WOW 0.0.0.0 0.0.0.0 x.x.x.x 5

----------------

What am I missing? When you say to expand the crypto domain to include 1.2.3.4, did I do that correctly? Do I need to add 1.2.3.4 to the nat exemption list? I added a route for 1.2.3.4 at SiteA on the inside interface -- is this the correct interface? I tried others and it made no difference. At SiteB, the default route already points all traffic to the outside interface, so I shouldn't need an additional route there, correct?

Thanks for your help!

--Rob

[Milos_Jovanovic · Accepted solution]

Hi Rob,

Yes, this is what I meant for expanding crypto domain. And yes, you'll need to add 1.2.3.4 to NAT-exempt. Yes, your routing looks ok for SiteA. And no, no additional route is required on SiteB, as default route will catch this traffic, taking it to crypto map.

Try with adding no-NAT for 1.2.3.4, and if it still doesn't work, try with packet tracer and/or packet capture. It could happen that everything is fine on your end, but your SiteC doesn't route properly.

BR,

Milos

[rschember1]

Milos --

You were correct about both things.

I added a NAT exemption for (inside,outside) at both SiteA and SiteB for 1.2.3.4 and using a packet capture, I could see the traffic getting to SiteA, but I wasn't getting anything in return.

I contacted the company with the managed router for SiteC to see if they could see traffic getting to their inside interface from SiteB -- they could. Turns out they also missed a NAT for the SiteB subnet. Once they corrected that, traffic started working in both directions.

Thanks for your assistance.

--Rob