Cisco Secure Access Help
Describes Configure Virtual Appliances in Cisco Secure Access. Configure your Cisco Secure Access Virtual Appliances (VAs) deployed in VMWare, Hyper-V, KVM, Azure, AWS, Google Cloud Platform, Nutanix, or Alibaba Cloud.
Configure your Cisco Secure Access Virtual Appliances (VAs) deployed in VMWare, Hyper-V, KVM, Azure, AWS, Google Cloud Platform, Nutanix, or Alibaba Cloud.
When you open the VA in your preferred hypervisor's console, and you'll see a configuration menu. As seen in the lower right corner, the system time is set to UTC by default. This will not affect your DNS, network, or hypervisor.
To access the VA console efficiently, use a native application (such as VMware vSphere Client, VMware Remote Console, or RDP).
If you have deployed the VA in a network that supports DHCP, the VA is automatically assigned a DHCP IP address and registers to Secure Access using this IP. This IP address appears on the configuration and in Secure Access.
A VA can be deployed in Azure with either a static IP address or a DHCP IP address. If you do not specify a static IP address at the time of deployment, the VA is automatically assigned a DHCP IP address and registers to Secure Access using this IP address. Secure Access lists this IP address as the name of the VA. For more information, see Manage DNS Forwarders.
In the case of AWS and Google Cloud Platform, the VA is automatically assigned a DHCP IP address and registers to Secure Access using this IPO address. Secure Access lists this IP address as the name of the VA on the dashboard.
Configuration mode does not support concurrent access by more than two users.
Configuring the VA involves configuring the name, IP details, and local DNS servers. It is mandatory to configure the name and IP, netmask, and gateway (unless already configured). Failing to do this results in the VA not being able to register to Secure Access.
In addition to an IPv4 address, you can also configure the VA with an IPv6 address. Endpoints with an IPv6 address can use the VA for DNS resolution, and Secure Access logs the internal IPv6 address of the endpoint in the reports.
Active Directory integration is currently not supported for IPv6 endpoints.
| Field | Description |
|---|---|
| Name* |
The name associated with the VA in Secure Access. This is a descriptive name, similar to a hostname for a computer or server. If you have multiple hypervisor hosts, appending or prepending numbers or letters to indicate the local hypervisor host is advised.
|
| IP, Netmask, and Gateway* |
Give the VA a local, static IP address on the same network as your endpoints which will utilize the VAs for DNS resolution.
|
| Local DNS 1-6 | Configure your local DNS servers that will receive DNS queries for internal domains. These are usually your Windows Servers with the DNS server role installed. You can enter IPv4 and/or IPv6 addresses here. For more information and commands to configure local DNS servers, see Local DNS Forwarding. |
*Mandatory parameters for the VA.
If you have entered the Configuration Mode over SSH, to validate status, enter:
config va statusIf tests complete without error, the next step is to verify that the VA syncs with Secure Access.
Repeat the previous steps to configure a second VA. A second VA is required for continuous operation, high availability, and automatic upgrades.
Azure AD Domain Services is currently not supported. For identity integration with the VA, the AD Connector and Domain Controllers should be deployed as VMs in Azure. Alternately, these components can be deployed on-premise provided there is an ExpressRoute or MPLS connection over which the AD Connector can communicate with the VA in Azure.
Configure other settings on your Cisco Secure Access Virtual Appliances (VAs).
You can set rate limits of DNS queries on a VA for a single IP address. Use rate limits to prevent any single endpoint from attempting to flood the VA with DNS queries and causing a Denial-of-Service on the VA.
Enable rate limits on the Virtual Appliance. Rate-limiting is off by default.
config va per-ip-rate-limit enable <pps> <burst>Disable rate limits on the Virtual Appliance.
config va per-ip-rate-limit disableCheck status and packet drops on the Virtual Appliance.
config va showBy default, VAs use Ubuntu NTP servers (ntp.ubuntu.com) as their time servers. You can configure your VAs to use other NTP servers.
config ntp add <serverIP1> <serverIP2>config ntp remove <serverIP1> <serverIP2>config ntp showBy default, the VA is configured to use the Cisco Secure Access DNS resolvers. For more information, see Secure Access DNS Resolvers .
You can change the Secure Access resolvers used by the VA.
config va resolvers globalUse this option if your ISP blocks traffic to the Secure Access DNS resolvers.
config va resolvers alternateconfig va resolvers global-v6config va resolvers USconfig va resolvers US-v6config va resolvers 7071config va resolvers 7071-v6If you configure the IPv6 Secure Access DNS resolvers, then the VA only sends DNS queries over IPv6. HTTPS traffic to other endpoints is sent over IPv4.
Secure Access supports DNSSEC by performing validation on queries sent from Secure Access DNS resolvers to upstream authorities.
If your endpoints are making DNS queries with the DNSSEC OK (DO) bit to the VA, the default behavior of the VA is to turn off this bit before forwarding the query to Secure Access or the local DNS server.
Configure the VA to preserve the DO bit when forwarding the DNS query to Secure Access or the local DNS server.
The VA preserves any DNSSEC Security Resource Records in the DNS response to the endpoint.
config va dnssec enableconfig va dnssec disable| Command | Description | Notes |
|---|---|---|
| config va dnssec enable | Configure the VA to preserve the DO bit when forwarding the DNS query to Secure Access and/or the local DNS server. | Preserves any DNSSEC Security Resource Records in the DNS response to the endpoint. |
| config va dnssec disable | Disable the above configuration. |
Virtual Appliances can forward logs to a remote syslog server. If configured, Secure Access forwards logs related to internal DNS queries, logs on upgrades and reboots of the VA, and admin audit.
config logexport destination <server-ip-address:port> <protocol>Supported Values for <protocol>:
TCP, UDP, or TLS.
If no value is specified, TCP is the default.
If the protocol value is TCP or UDP and a port is not specified, 514 is assigned as the default port.
If the protocol value is TLS and a port is not specified, 6514 is taken as the default port.
IPv6 addresses are not supported as destination IPs for this command.
For example: config logexport destination <10.26.02.82:514> udp
To forward the logs over a TLS-encrypted session, first create the certificates for the client (VA) and server (remote syslog server). The certificates can be self-signed or signed by a Root certificate authority (CA).
Add the key and certificate to the VA using the following commands:
config logexport key <copy the contents from keyForClientCert.pem file>
config logexport cert <copy the contents from ClientCert.pem file>
config logexport ca \<copy the contents from selfsignedCA.pem|chainCertCA.pem file>The CA configured in the last command should be the CA used to sign the server certificate.
All internal DNS queries sent to the internal DNS server are logged at the syslog server. Logs include the date and time, the internal domain being queried and the private IP, hostname and username of the source endpoint that made the query.
If AD integration is not configured for the VA, the hostname and username of the source endpoint are not available.
config logexport enable internaldnsFormat for internal DNS queries:
Date
Time
Hostname (forwarder)
VA Label:
InternalDNS
Internal IP of source
User AD identity of source (if a user identity is mapped to this IP else "NULL")
Host AD identity of source (if a host identity is mapped to this IP else "NULL")
Internal Domain being queried
Reboots and upgrades of the VA are logged at the syslog server.
config logexport enable healthFormat for VA boot:
Format for VA upgrade:
Admin audit log (logins by admin users and config commands run on the VA) are logged at the syslog server.
config logexport enable adminFormat for User Login to VA:
Format for Configuration change:
AuditLog-Config command executedEnables logging of internal DNS, health, and admin logs at the syslog server.
config logexport enable allRun this command to check the status of the log forwarding:
config logexport statusRun this command to turn off logging:
config logexport disable <feature>You can set the featureoption tointernaldns,health,auditorall.
Example:
config logexport disable allNIC Terminology Throughout this section, the terms NIC, network interface, and network adapter are used interchangeably.
Virtual Appliances support a dual-NIC configuration. This dual-NIC configuration is intended to enable the DMZ deployment of a VA for traffic segregation with one network interface. The network interface is used for outbound communication and the other network interface is used for internal communication.
Dual-NIC support has only been qualified on VAs running on Hyper-V and VMware. There is no change to existing behavior if the VA is deployed with a single NIC. Configuring more than two NICs on the VA is not supported.
When using the dual-NIC configuration, Secure Access does not support the configure of IPv6 addresses for network adapters.
You can deploy a new VA with dual-NIC support. The configuration steps are similar to configuring an upgraded VA. You can add the secondary adapter to the VM using the hypervisor console, before powering on the VM. Both adapters should be of the same driver type.
Secure Access Virtual Appliances enable the use of Anycast DNS addressing within an enterprise.
The advantage of using Anycast is that all your endpoints can use the same DNS IP address irrespective of the Site where they belong. Configuring an Anycast IP address on the VA adds resiliency for DNS resolution.
The VA currently supports enabling Anycast using the BGP protocol. This requires support for BGP on the VA's neighboring router, or any router that is reachable from the VA within 255 hops.
You can configure up to 4 routers running BGP as BGP peers for the VA.
Two VAs in different branches can also be configured with the same Anycast IP address, ensuring resiliency across branches. However, if AD integration is required, these VAs must be in the same Secure Access Site, since the AD Connector propagates IP-AD user mappings only to VAs in its Secure Access site.
Secure Access supports the configuration of IPv4 addresses as an Anycast address on the VA.
Secure Access Virtual Appliances use Anycast for load balancing. Secure Access has verified the use of Anycast for load balancing on the VA in on-premises deployments: VMware and Hyper-V. However, for VAs that are deployed in the cloud, the use of Anycast depends on the egress networking support provided by the cloud environment's virtual switches (vSwitches).
Anycast for VAs is not supported on Google Cloud Platform (GCP) due to limited support on the GCP infrastructure.
Example:
In the following configuration, the VA needs to be configured with Anycast IP 192.168.1.22, the BGP router's ASN is 7105, and IP address is 10.1.0.1.
You can configure your Virtual Appliances behind a load balancer that meets the following requirements:
This feature has specifically been qualified with the F5 BIGIP-LTM 16.1.1 version, where the F5 can inject the endpoint source IP in DNS requests that it forwards to VAs in the load balancing pool. Refer to F5 documentation on ECS injection in DNS requests when forwarding these requests to a DNS server pool.
By default, the VA does not accept DNS requests with the ECS option from any endpoint. To allow the VA to accept DNS requests with the ECS option from load balancers, the load balancer IP has to be added to the VA configuration using the following commands:
config loadbalancer add <server-ip/prefix>config loadbalancer remove <server-ip/prefix>You can add a maximum of 8 load balancers to a VA. Also, add or remove a single load balancer at a time.
Use the config admap command to configure association timeouts for a given IP address. You can also view or clear the AD mapping. You can only clear the mappings of an individual IP address.
Example commands:
config admap view <ip address>config admap clear <ip address>config admap set-user-timeout 28800
# This command sets the host timeout for 8 hoursconfig admap set-host-timeout 28800
# This command sets the host timeout for 8 hoursconfig admap show-timeoutOnce you delete the Secure Access API key credentials that you created for authentication of your Virtual Appliances, the VAs have 90 days to use the existing API client key and secret. After 90 days, your VAs can not sync with Secure Access.
Unless you have unusual circumstances, we do not recommend that you delete your Secure Access API key credentials.