Creating a Cisco ASA - Palo Alto VPN tunnel for ALL traffic

[nthen]

I have a Cisco ASA at a remote site and PAN 3020 at my HQ site.  The current site-to-site tunnel is working well and remote users can access resources in my network.  Now comes the tricky part.  In a perfect world, I could put another smaller PAN unit there for AV, App Control, etc. but until then I need some way to control it since those users are not conforming my security policy.  Does anyone know of a way on an ASA to tunnel all traffic to a PAN firewall?  This way, rules on my 3020 would work for the remote VPN and I can prevent those users from using certain apps across the Internet.

[ericgearhart · Accepted solution]

On the Cisco ASA, for the "interesting traffic" ACL that defines what to tunnel to the remote site, you'd simply open up that "interesting traffic" ACL to include all traffic sourced by your internal LAN(s) destined for anywhere. This would cause all the traffic leaving the ASA's "inside" network to be tunneled over to your 3020. Also make sure you build a NoNAT exception on your ASA, so the ASA doesn't NAT any LAN traffic.

You can then do NAT out to the Internet on your PA 3020.

If you'd like help with the config on the ASA, you can PM me or post some config here if you're comfortable doing that. At a previous job I managed literally hundreds of IPsec tunnels with ASAs in three different parts of the country.

[nthen]

So in theory I would do something like this (I left out other non important parts of the config)...

object-group network HQ-Encrypt

    network-object 0.0.0.0 0.0.0.0

object-group network RemoteSite-Encrypt

    network-object 192.168.1.0 255.255.255.0

crypto map HQ 50 match address remote_vpn

crypto map HQ 50 set peer 1.2.3.4

crypto map HQ 50 set transform-set HQ

crypto map HQ 50 set security-association lifetime seconds 3600

crypto map HQ interface outside

access-list nonat extended permit ip object-group RemoteSite-Encrypt object-group HQ-Encrypt

access-list remote_vpn extended permit ip object-group RemoteSite-Encrypt object-group HQ-Encrypt

I am not 100% sure on this NAT portion though...

global (outside) 1 interface

nat (inside) 0 access-list nonat

nat (inside) 1 192.168.1.0 255.255.255.0

[ericgearhart]

That 'nat (inside) 0 access-list nonat' is the NoNAT I was thinking of... basically your internal LAN source won't be NAT'd at all.

This part of your config:

nat (inside) 0 access-list nonat

nat (inside) 1 192.168.1.0 255.255.255.0

...basically says "don't NAT traffic if it matches this specific access list (named nonat in your example). NAT everything from 192.168.1.0/24, and use the interface named 'outisde'  to NAT behind." The "nat (inside) 0" line is a special config line - "nat 0" statements are really what you DON'T want to NAT (hence the access list name, nonat)

You could just flat out turn off NAT on the ASA honestly... you could "no out" your global NAT and your "nat (inside)" statements instead of trying to NoNAT everything

[ericgearhart]

In that example you've got I think in your two ACLs you've got the directions backward. In the ACLs you're basically pointing out what traffic will flow over the IPsec tunnel.

If for example your headquarters subnet is 192.168.0.0/24 (your remote site is 192.168.1.0/24 in your example above), you want to say "everything flowing from 192.168.0.0/24 to anywhere will flow over the IPsec tunnel"

So you'd need this, in your example from above:

object-group network HQ-Encrypt

    network-object 192.168.0.0 255.255.255.0

object-group network RemoteSite-Encrypt

    network-object 0.0.0.0 0.0.0.0

And your ACLs would look like this:

access-list nonat extended permit ip object-group HQ-Encrypt object-group RemoteSite-Encrypt

access-list remote_vpn extended permit ip object-group HQ-Encrypt object-group RemoteSite-Encrypt

[nthen]

The way I have the ACLs now are working, but I'll PM you the config which may be easier if I am showing something wrong.  Right now my remote site has a server so that would still need to be NAT'd but everything else would not need to be.  This is recent acquisition for my company so it is still in transition.

[ericgearhart]

Hey if what you have configured is working then that's all good... it's hard to "eyeball" a config and point things out without having an ASA around.

Glad I could help!

[nthen]

I appreciate the advice on the tunnel all mode.  I think I have my ACL right to only NAT their server to our private addresses and send everything else.  From the PAN then I should be able to NAT and have all my policies apply.  Does this ACL make sense?

access-list nonat permit ip 192.168.1.10 255.255.255.255 172.16.1.0 255.255.255.0

access-list nonat permit ip 192.168.1.10 255.255.255.255 10.50.1.0 255.255.255.0

access-list nonat deny ip 192.168.1.10

access-list nonat permit ip 192.168.1.0 255.255.255.0 0.0.0.0 0.0.0.0

[ericgearhart]

That does look correct to me... the logical flow of the ACL looks like it would do what you want.

It looks like this is what you're trying to achieve:

• nonat traffic from your specific server to your two remote sites
• don't nonat anything else from that specific server on the 192.168.1 subnet
• nonat all traffic from 192.168.1.0/24 to anwhere

Looks good to me!