AnyConnect VPN user connects via LDAP but no access past Inside interface

Anthony Hayes · ‎08-02-2016

Hey all. I've seen this problem come up many times in web searches and in discussions here, but I cannot find the problem that I'm having in my programming. The AnyConnect user can login via LDAP and PING the inside interface, but cannot access anything past it nor PING the DMZ interface. What am I missing here? Thanks!

: Hardware: ASA5512, 4096 MB RAM, CPU Clarkdale 2793 MHz, 1 CPU (2 cores)
:
ASA Version 9.2(1)
!
hostname *****
domain-name *****
enable password ***** encrypted
xlate per-session deny tcp any4 any4
xlate per-session deny tcp any4 any6
xlate per-session deny tcp any6 any4
xlate per-session deny tcp any6 any6
xlate per-session deny udp any4 any4 eq domain
xlate per-session deny udp any4 any6 eq domain
xlate per-session deny udp any6 any4 eq domain
xlate per-session deny udp any6 any6 eq domain
passwd ***** encrypted

dns-guard
ip local pool AnyConnect_Pool 192.168.2.100-192.168.2.200 mask 255.255.255.0
!
interface GigabitEthernet0/0
nameif outside
security-level 0
ip address ASA-OUTSIDE-IP 255.255.255.248
!
interface GigabitEthernet0/1
nameif inside
security-level 100
ip address 192.168.1.250 255.255.255.0
!
interface GigabitEthernet0/2
nameif dmz
security-level 50
ip address 10.10.10.10 255.255.255.0
!
boot system disk0:/asa921-smp-k8.bin
ftp mode passive
clock timezone EST -5
clock summer-time EDT recurring
dns domain-lookup outside
dns domain-lookup inside
dns domain-lookup dmz
dns server-group DefaultDNS
name-server 192.168.1.14
name-server 192.168.1.15
name-server 8.8.8.8
domain-name *****
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
object network INSIDE
subnet 192.168.1.0 255.255.255.0
object network DMZ
subnet 10.10.10.0 255.255.255.0
object network Networks_HS
subnet 172.16.0.0 255.255.0.0
object network Networks_MainSites
subnet 192.168.0.0 255.255.0.0
object network VPN
subnet 192.168.2.0 255.255.255.0
object network obj_any
subnet 0.0.0.0 0.0.0.0
access-list split_tunnel standard permit 192.168.1.0 255.255.255.0
access-list split_tunnel standard permit 10.10.10.0 255.255.255.0
pager lines 24
logging enable
logging timestamp
logging asdm informational
mtu mgmt 1500
mtu outside 1500
mtu inside 1500
mtu dmz 1500
ip verify reverse-path interface mgmt
ip verify reverse-path interface outside
ip verify reverse-path interface inside
ip verify reverse-path interface dmz
icmp unreachable rate-limit 1 burst-size 1
icmp permit any echo-reply outside
icmp deny any outside
asdm image disk0:/asdm-751.bin
asdm history enable
arp timeout 14400
no arp permit-nonconnected
nat (inside,outside) source static any any destination static VPN VPN no-proxy-arp route-lookup
!
object network INSIDE
nat (inside,outside) dynamic interface
object network DMZ
nat (dmz,outside) dynamic interface
route outside 0.0.0.0 0.0.0.0 ASA-OUTSIDE-GATEWAY 1
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
aaa-server LDAP_SRV_GRP protocol ldap
aaa-server LDAP_SRV_GRP (inside) host ****.*******.***
timeout 5
server-port 636
ldap-base-dn *****
ldap-group-base-dn *****
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn *****
ldap-over-ssl enable
server-type microsoft
user-identity default-domain LOCAL
aaa authentication ssh console LOCAL
aaa authentication http console LOCAL
aaa authentication serial console LOCAL
http server enable
http ***** 255.255.255.0 inside
http redirect outside 80
snmp-server host inside ***** community *****
snmp-server location *****
snmp-server contact *****
snmp-server community *****
snmp-server enable traps syslog
crypto ipsec security-association pmtu-aging infinite
crypto ca trustpool policy
telnet timeout 5
ssh stricthostkeycheck
ssh ***** 255.255.255.0 inside
ssh timeout 20
ssh key-exchange group dh-group1-sha1
console timeout 0
management-access inside
threat-detection basic-threat
threat-detection statistics host
threat-detection statistics port
threat-detection statistics protocol
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
ntp server 130.88.212.143 source outside prefer
webvpn
enable outside
anyconnect image disk0:/anyconnect-win-3.1.10010-k9.pkg 1
anyconnect profiles Default_AnyConnect_Profile disk0:/default_anyconnect_profile.xml
anyconnect enable
group-policy DfltGrpPolicy attributes
dns-server value 192.168.1.15 192.168.1.14
vpn-tunnel-protocol ikev2 ssl-client
split-tunnel-policy tunnelspecified
split-tunnel-network-list value split_tunnel
default-domain value *****
webvpn
anyconnect profiles value Default_AnyConnect_Profile type user
anyconnect ask none default anyconnect
username ***** password ***** encrypted privilege 15
username ***** password ***** encrypted privilege 15
tunnel-group DefaultWEBVPNGroup general-attributes
address-pool AnyConnect_Pool
authentication-server-group LDAP_SRV_GRP
password-management
tunnel-group DefaultWEBVPNGroup webvpn-attributes
group-alias Default_AnyConnect_Profile enable
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
!
hpm topN enable
: end

Richard Burts · ‎08-02-2016

I wonder if the problem with access to DMZ has to do with address translation. I see that you have provided a nat exemption for VPN traffic to inside for not an exemption for traffic to dmz. Try adding something like this and let us know what happens

nat (dmz,outside) source static any any destination static VPN VPN no-proxy-arp route-lookup

HTH

Rick

HTH

Rick

mibricen · ‎08-02-2016

Hello Anthony,

What Richard stated is correct, I just wanted to add to his response that in order to ping interfaces located on the ASA from hosts located over a VPN connection, the "management-access <interface>" command is needed. And this command is only applicable to one interface at a time. Currently you have it configured on "inside" interface, so that will be the only one responding to pings for VPN users.

If you need to ping "dmz" for testing purposes you may change the management-access to the dmz interface: "management-access dmz". And place it back to inside interface if needed afterwards.

----------------------------------------------------------------------------------------------------------------

Now based on the split tunnel access list:

access-list split_tunnel standard permit 192.168.1.0 255.255.255.0
access-list split_tunnel standard permit 10.10.10.0 255.255.255.0

The networks behind "inside" and "dmz" interfaces should be accessible over the VPN.

object network INSIDE
subnet 192.168.1.0 255.255.255.0

object network DMZ
subnet 10.10.10.0 255.255.255.0

object network VPN
subnet 192.168.2.0 255.255.255.0

I will personally prefer to use the objects on the nat exemptions to avoid the "any" definitions to absorb traffic not meant to the rule.

nat (dmz,outside) source static DMZ DMZ destination static VPN VPN no-proxy-arp route-lookup

nat (inside,outside) source static INSIDE INSIDE destination static VPN VPN no-proxy-arp route-lookup

----------------------------------------------------------------------------------

You may place captures on the inside and/or dmz interfaces to check if the traffic is leaving correctly to the internal networks.

capture <capture name> interface <interface name> match ip host <remote ip> host <local ip>

For example:

If the remote access user was given the 192.168.2.25 address and he is trying to reach 192.168.1.10 internal host.

1- initiate a constant ping to the internal host from the remote host.

2- place the capture:

capture in interface inside match ip host 192.168.2.25 host 192.168.1.10

3-Display the capture to check if traffic is leaving and returning correctly (or if it is not).

show capture in

If you see echo request and reply on the interface let me know since we will need to check if the traffic is being dropped.

Miguel

Anthony Hayes · ‎08-03-2016

Hello Richard & Miguel and thank you for taking time to respond to my post. An update:

Richard: I added the NAT command you provided that I (embarrassingly) missed and it gave me access to the PC behind the DMZ interface. I can ping and RDP to that PC from the VPN client now, as I could not before. Thank you for catching that.

Miguel: I have put in my notes the info you gave about an interface needing "management-access" given to it in order to ping it and only one interface can have that designation at a time. Very good to know and got more info by Googling the command. I also made the changes in my NAT exemptions from "any" to specific interfaces as you prefer to do. I understand the concept for the change and have made a note of that as well.

I did place a capture on the inside interface and pinged both the responding pc behind the DMZ and a pc that doesn't respond behind the INSIDE interface from the VPN client to see how the capture looks when it works and when it doesn't.

The working ping to the pc in the DMZ showed the ICMP: ECHO REQUEST and ICMP: ECHO REPLY logged as it should be. The ping to the pc on the INSIDE only shows ICMP: ECHO REQUEST with no corresponding ECHO REPLY Hence, its not working. I have verified that Windows Firewall is off on the pc that I am trying to ping behind the INSIDE interface.

As I'm clearly a noob trying to learn this device, does this look like I have a ACL problem on the INSIDE interface that doesn't allow the reply back? I'm thinking maybe the implicit "Deny All" rule or something?? I'm just not sure why it works with a pc behind the DMZ and not the INSIDE interface.

Richard Burts · ‎08-03-2016

I wonder if the problem with access to PC inside might be that whatever is doing routing inside does not have a route for the VPN address pool?

HTH

Rick

HTH

Rick

Anthony Hayes · ‎08-09-2016

Richard, that was correct. I had this 5512-X plugged into the same switch as the current 5510 we have for testing LDAP AnyConnect authentication. It dawned on me that any pc behind the INSIDE interface would have the 5510 as its default gateway and not the 5512-X that I was VPN'd into. The PINGs were coming in via the 5512-X and trying to go out the 5510.

What I didn't understand is why my LDAP calls to the server behind the INSIDE interface worked from the 5512-X but simple PINGs weren't. I will have to research that. Thanks all for your help.

Richard Burts · ‎08-09-2016

If I am understanding your situation correctly the difference is this: the LDAP call is generated by the ASA which will use the IP of the inside interface as the source address. So when the LDAP response comes back it knows that the response goes to the 5512. But the ping is generated from the VPN client and its source address is not recognized as being associated with the 5512 but with the 5510.

HTH

Rick

HTH

Rick