Please help troubleshoot specific ASA nat statement need, details...

[jmaxwellUSAF]

Hello.
I am new to ASA OS configuration. I am troubleshooting the failing code below...

#object network VENDOR1
   #host 1.1.1.1
#object-group network VPN-Vendor-IP
   #network-object object VENDOR1
#access-list Split-Tunnel extended permit ip host 1.1.1.1 object VPN-Pool

... My goal with this code is for the erected split tunnel to include 1.1.1.1 within the tunnel, so that Anyconnect clients can communicate with the server at 1.1.1.1 . I expect I need a NAT statement.
 
1. What is the code of NAT statement I need?
2. Why do I need this NAT statement / What is the logic within this NAT statement?

Thank you!

[Rob Ingram]

@jmaxwellUSAF obviously 1.1.1.1 is not the real IP address. Is the real IP address a host inside the network or is it on the internet, so the RAVPN user is tunnelled back to the ASA and hairpin? You'd probably need a NAT exemption rule.

[jmaxwellUSAF]

1.1.1.1 is a public IP address of the vendor.

Thank you.

[Rob Ingram]

@jmaxwellUSAF so it's routed back out the outside interface?

Therefore you need the NAT rule as per your post yesterday...

object network VPN-Pool
 nat (Outside,Outside) dynamic interface

And to allow the traffic to hairpin (ingress/egress out the same interface) use the following command (if not already configured) - same-security-traffic permit intra-interface

[jmaxwellUSAF]

"same-security-traffic permit intra-interface"

Where do I place this command?

Thank you Rob!

[Rob Ingram]

@jmaxwellUSAF its a global CLI command, just copy and paste.

[jmaxwellUSAF]

Thank you Rob! 

I must execute this after hours. I will reply with an update.

[jmaxwellUSAF]

Do I need the below NAT statement as well?

#nat (Inside,Outside) source static VPN-Vendor-IP VPN-Vendor-IP destination static VPN-Pool VPN-Pool

Thank you.

[Rob Ingram]

@jmaxwellUSAF possibly not, it depends where is this vendor connected to, the inside or outside interface? When you said public IP address, I assumed it would reside on the outside interface. Hence the I suggested the first NAT rule.

[jmaxwellUSAF]

This is an outside public IP address. After hours, I will try with and without, whichever yields success. 

Thank you.

[Rob Ingram]

@jmaxwellUSAF if the destination is definately outside then - "nat (Inside,Outside) source static VPN-Vendor-IP VPN-Vendor-IP destination static VPN-Pool VPN-Pool" is not going to apply (in this scenario), because the source interface in this rule is "inside" but traffic from anyconnect users will always be sourced on the outside.

It depends on the other networks in the group "VPN-Vendor-IP" whether the NAT rule it is required or not. From the CLI run "show nat detail" and check to see if traffic has been translated/untranslated on this NAT rule, which would indicate whether it's in use or not.

[jmaxwellUSAF]

This new config with VENDOR1 and 1.1.1.1 is not in the current config. The other details are already in the config.

"show nat detail" reveals 29 Manual NAT, and 32 Auto NAT

What concerns me is that, without a new NAT statement, the existing config was already tried and it didn't work.

[Rob Ingram]

@jmaxwellUSAF well like I said the existing rule would not work when accessing 1.1.1.1 from an anyconnect user.

[jmaxwellUSAF]

I found a strong hint:

Within the config, there exists a maximally similar instance of code with a different IP address ( I don't know the details of that IP address, but it is a public address. It shows evidence of being translated with "nat (Inside,Outside) source static VPN-Vendor-IP VPN-Vendor-IP destination static VPN-Pool VPN-Pool"

But that code is already in the config. Is there anything else I should try here?

[Rob Ingram]

@jmaxwellUSAF but where does this other IP address reside, on the inside interface or the outside? If it's on the inside, then yes it makes sense. If the source is not from the "inside" interface it won't match that NAT rule.