06-17-2019 09:11 AM - edited 02-21-2020 09:13 AM
I recently modified our Cisco ASA 5516-X firewall (in routed mode), changing the "inside" interface from one of the GigabitEthernets to a BVI (IP 10.0.0.1). After doing so, I seem to have lost access to our Windows (DC) Domain Controller (IP 10.1.1.50), which maintains our internal DNS and DIT (Directory Information Tree) for authentication. In other words, AnyConnect VPN users can no longer authenticate and, therefore, cannot use internal resources. I have created some new ACLs to go with this setup (temporarily any-any), but am stumped as to why AAA doesn't work.
The ASA is connected to a L3 switch (SVI IPs 10.0.0.2 and 10.1.1.2), to which the servers connect. I can ping the DC from the router and the router from the DC; however, I can't seem to connect to it for AAA or DNS.
router# ping 10.1.1.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.50, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
PS C:\Users\cerealkiller> ping 10.0.0.1 Pinging 10.0.0.1 with 32 bytes of data: Reply from 10.0.0.1: bytes=32 time<1ms TTL=254 Ping statistics for 10.0.0.1: Packets: Sent = 1, Received = 1, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Control-C
When I try to test the AAA server from the ASDM, I receive the following error.
Authentication test to host 10.1.1.50 failed. Following error occurred - ERROR: Authentication Server not responding: AAA Server has been removed
On the router's CLI, I added debugging info for ldap and watched:
router# debug ldap 255 debug ldap enabled at level 255 router# [-2147483622] Session Start [-2147483622] New request Session, context 0x00007fb1814879f8, reqType = Authentication [-2147483622] Fiber started [-2147483622] Creating LDAP context with uri=ldap://10.1.1.50:389 [-2147483622] Connect to LDAP server: ldap://10.1.1.50:389, status = Failed [-2147483622] Unable to read rootDSE. Can't contact LDAP server. [-2147483622] Fiber exit Tx=0 bytes Rx=0 bytes, status=-2 [-2147483622] Session End
Because the AAA server is also our internal DNS, I tested name resolution as well, which failed:
router# ping SERVER_NAME ^ ERROR: % Invalid Hostname
Pinging a public address yields the same result:
router# ping google.com ^ ERROR: % Invalid Hostname
I am not sure if this is something to do with using the BVI or what. Do I need to revert back to using the physical interface? Does anyone know the source address when the ASA sends an AAA request? Any help is greatly appreciated in this. The following ASA config should be all the necessary options, but please let me know if I can get more information. Thank you!
interface GigabitEthernet1/1 description WAN link from ISP nameif outside security-level 0 ip address PUB.LIC.IP.ADDR SUB.NET.MA.SK ! interface GigabitEthernet1/2 bridge-group 1 nameif inside_1 security-level 100 ! interface BVI1 description Bridge Interface nameif inside security-level 100 ip address 10.0.0.1 255.255.255.0 ! dns domain-lookup outside dns domain-lookup inside dns server-group DefaultDNS name-server 10.1.1.50 inside name-server PUBLIC_DNS1 outside name-server PUBLIC_DNS2 outside domain-name domain.tld
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface !
access-list outside_access_in extended permit ip any any
access-list inside_access_in extended permit ip any any
access-list inside_1_access_in extended permit ip any any
access-list global_access extended permit ip any any
! nat (inside_1,outside) source dynamic internal-nets interface ! access-group outside_access_in in interface outside access-group inside_1_access_in in interface inside_1 access-group inside_access_in in interface inside access-group global_access global
!
route outside 0.0.0.0 0.0.0.0 ISP_GATEWAY 1
route inside 10.1.1.0 255.255.255.0 10.0.0.2 1 ! aaa-server ldap-servers protocol ldap realm-id 1 aaa-server ldap-servers (inside) host 10.1.1.50 ldap-base-dn DC=DOMAIN,DC=TLD ldap-scope subtree ldap-naming-attribute sAMAccountName ldap-login-password ***** ldap-login-dn CN=LDAP USER,OU=ORG_UNIT,DC=DOMAIN,DC=TLD server-type microsoft ! group-policy AnyConnectPolicy internal group-policy AnyConnectPolicy attributes vpn-tunnel-protocol ikev2 ssl-client split-tunnel-policy tunnelspecified split-tunnel-network-list value anyconnect-vpn address-pools value anyConnectPool ! tunnel-group DefaultRAGroup general-attributes address-pool anyConnectPool authentication-server-group ldap-servers LOCAL default-group-policy AnyConnectPolicy tunnel-group DefaultWEBVPNGroup general-attributes address-pool anyConnectPool authentication-server-group ldap-servers LOCAL default-group-policy AnyConnectPolicy
UPDATE: The above has been edited to show the correct route.
--
Matt
Solved! Go to Solution.
06-18-2019 08:08 AM
06-18-2019 04:31 AM
I would test by amending the following -
no route inside 10.1.1.0 255.255.255.0 10.1.1.2 1
route inside 10.1.1.0 255.255.255.0 10.0.0.2
06-18-2019 06:47 AM
Good catch. I must admit I did a bit of doctoring with the IP addresses; I suppose I should've just left them alone and not introduce the possibility of more errors. I actually _do_ have the line you suggested in the config. I will edit that post to clarify as well.
06-18-2019 08:08 AM
06-18-2019 09:59 AM
I think that very well may be the case: I am running version 9.8(2).
Thank you very much. I will revert back to using a L3 interface and let you know if my issue resolves.
06-19-2019 07:45 AM
I went back to using GigabitEthernet1/2 instead of the BVI for my inside interface, and I was able to successfully authenticate with my AD server again. I have to assume at this point that the bug affecting version 9.8(1) also affects 9.8(2), which is what I'm running. Thanks, GRANT3779, for the assistance!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide