FMC AnyConnect VPN Internal Routing

[christopher_ringley]

I have Firepower Management Center running a HA setup of two Firepower 1010s. These devices are managing 5 public IPs with no problems. We have a couple internal resources with public DNS A records which required creating static NAT rules for changing the destination from the public A record to the local IP address, everything works perfectly.

We are now working on setting up AnyConnect on the FTDs and are having an issue with that same problem. The current NAT rules do not work on anything coming over the VPN trying to access a resources with a public A record. A good example of this would be trying to access an internal email server.

Not sure if I am explaining correctly. I attached an example static NAT rule we use for directing an internal device to the email network when using the public DNS record. Let me know if any additional information would be helpful.

[flamingbk]

Hello Christopher,

Do you configured a policy rule for this traffic? ( VPN -> Email )?

Do you use any type of split tunneling?

Public IP is pointed at OUTSIDE(DMZ) or EMAIL zone?

If you can share a simples network diagram and packet tracert with this taffic flow will be helpul

Regards,

Fernando.

[christopher_ringley]

Hello Fernando,

I have all the policy rules in place for VPN traffic to necessary destinations.

With split tunneling enabled, this works as expected. However, our goal was to force all traffic through the FTD in order to filter URLs, files, etc.

The FTD interface handles a range of public IPs. For example 10.10.50.84/29. We then NAT specific incoming packets to proxy servers to send to internal servers. So if a request came in on our public IP for email, say 10.10.50.83, we would forward that to a proxy to handle sending to the email server. While on the network we have NAT rules to reroute the traffic with a destination the same as an interface IP to the internal server instead. This is what is not working on the FTD I believe due to the security group for VPN being Outside, the same as all incoming traffic.

While on the network the tracert is as follows (changed to preserve security)

10.90.100.5 to 10.90.100.1

10.90.100.1 to 10.91.200.2 (email server internal IP)

While on the VPN with the same rules in place

10.90.100.5 to 10.90.100.1

10.90.100.1 to 10.10.50.83 (public IP)

This last step it just hangs because it can't reroute inside of the network.

I attached a simple diagram that should give context while preserving security.

Thanks,

Chris

[Peter Koltl]

Commonly VPN clients do not use the public addresses of the services. They access even the published services with real private server addresses. It requires an internal DNS server so that the name resolving returns the private address when the tunnel is up. When the tunnel is not connected, the external DNS returns the public address. This is called split DNS.