Intelligent DNS (iDNS)

My SH IDNS RR command displays a "gmac not found" message on a RRA

This error has two possible causes. Firstly, check that the entered IP address assigned to the RRA entry belongs to the GMAC defined in the configuration. Secondly, remove a GMAC and the RRA entry will remain unused. If you create a new GMAC, you need to update the Intelligent DNS (IDNS) table with the remap idns rr command.

I have bypassed my single Link LB unit with a patch cord between my firewall and primary link router, all outgoing traffic is fine but I do not have DNS resolution for incoming services that were load balanced.

The Link Load Balancer IDNS module provides DNS interception for load balanced incoming requests. If you removed the Link LB unit, you must ensure that incoming DNS requests are handled by another DNS server with static records to the primary link.

I do not have any internal DNS server. When my primary link is down, the IDNS module returns the IP of the second link to my internal systems instead of the primary link IP.

You can disable IDNS interception on the inside by disabling the idns_in feature.

My Cisco VPN setup is configured to use IDNS for redundancy but the VPNs do not failover correctly. My IDNS setup works perfectly but the firewalls keep trying to connect over the failed link. What can I do?

Some Cisco firewalls will resolve the FQDN once, at the initiation of a VPN tunnel, and retain the result IP address until the next reboot. This prevents the VPN from failover since the IDNS module cannot tell the Cisco firewall that the target IP changed.

The best way to solve this problem is to use the SitePathMTPX feature of the Link LB. We understand that this is not necessarily feasible in every situation, below is a recipe to help with the DNS resolution problem that afflicts some well-known firewalls.

You can alleviate this issue by adding a second peer IP that will now point to the IP of the alternate link on the remote firewall/router configuration. This will accept VPN connection natted to an alternate link in case of primary link failure. The VPN session will be terminated and re-initiated on the alternate link.

You can define multiple peers by using crypto maps to provide redundancy. This configuration is useful for site-to-site VPNs.

If one peer fails, the adaptive security appliance establishes a tunnel to the next peer associated with the crypto map. It sends data to the peer that it has successfully negotiated with, and that peer becomes the “active” peer. The “active” peer is the peer that the adaptive security appliance keeps trying first for follow-on negotiations until a negotiation fails. At that point the adaptive security appliance goes on to the next peer. The adaptive security appliance cycles back to the first peer when all peers associated with the crypto map have failed.

  Configuration:
 
 crypto map Public 10 match address ACL_FOR_THE_PEER_TO_MATCH
crypto map Public 10 set peer x.x.x.x    (Peer one) if fail will go to peer two
crypto map Public 10 set peer y.y.y.y     (Peer two) if Peer one fail
crypto map Public 10 set ikev1 transform-set Strong-Des
crypto map Public 10 set security-association lifetime seconds 28800
crypto map Public 10 set security-association lifetime kilobytes 1000000

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
pre-shared-key Thisisthepeerkey

tunnel-group y.y.y.y type ipsec-l2l
tunnel-group y.y.y.y ipsec-attributes
pre-shared-key Thisisthepeerkey

One of the main drawbacks of using this method is the lack of failback, in other words, once the VPN has failed-over it will remain on the secondary link until the seconadry link fails or the VPN is forcefully restarted. Using the SitePathMTPX feature will resolve this problem since the Link LBs at both sites can effectively switch the VPN from one link to the next transparently at all times without interrupting the packet flow.