cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2139
Views
5
Helpful
5
Replies

AAA stopped after implementing BVI

misterDub
Level 1
Level 1

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

 

1 Accepted Solution

Accepted Solutions

What version of code are you running? Is it possible you are hitting the following bug ?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf26463/?reffering_site=dumpcr


View solution in original post

5 Replies 5

GRANT3779
Spotlight
Spotlight

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

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.

What version of code are you running? Is it possible you are hitting the following bug ?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf26463/?reffering_site=dumpcr


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.

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!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card