Anyconnect users need to use FQDN after connecting

toxicman · ‎09-27-2012

We are experincing a problem with only some of our home based users. they VPN in just fine and can reach any servers by using the FQDN such as internalhost.company.com, however they cannot resolve "internalhost". The issue seems to be somewhere between AD and Anyconnect potentially. Our Group Policy is giving them DNS servers & the "company.com" domain but it doesn't seem to be properly injecting.

A wireshark capture shows this when the user tries to ping internalhost:

Client -> ASA specified DNS server -> Query internalhost.ad.domain.com

ASA specified DNS server -> Client -> No Such Name

Client -> Home subnet DNS server -> Query internalhost.ad.domain.com

Home subnet DNS server -> Client -> Response w/ Home ISP homepage IP

I'm not sure why 2 things are happening here:

1) While the client is a member of the AD, they should be using company.com first, I thought AnyConnect put the Group Policy domain at the top of the list

2) Why is the client reaching out to the Home subnet DNS server second? We are providing 2 DNS servers via AnyConnect, and that subnet isn't even part of the Split Tunnel group. AnyConnect seems to be bypassing the Split Tunnel rules we have specified.

Any ideas or suggestions? We are on the latest windows version 2.5.3055 and running windows 7.

Thanks!

~Jason

Javier Portuguez · ‎09-27-2012

Hi Jason,

Please do the following:

group-policy specific_group_policy attributes

split-dns value ad.domain.com

split-dns

Let me know how it goes.

Thanks.

Portu.

Please rate any helpful posts.

toxicman · ‎09-27-2012

Thanks Portu,

I checked our config & I see this in our DfltGrpPolicy, but not under the one our users connect in via. Those only have the

"default-domain value company.com"

I suspect for our case we'd add "

"split-dns value company.com"

as that's where about 95% of our DNS entries exist. Typically the computers will eventually try that value, but I suspect it's not proceeding through the suffix list as the Home ISP DNS service is providing an IP.

I'll post back after we try this out.

~Jason

Javier Portuguez · ‎09-27-2012

Thanks for the quick response.

I would suggest this instead:

group-policy specific_group_policy attributes

split-dns value company.com ad.domain.com

!

You can add more if needed.

Keep me posted.

toxicman · ‎09-27-2012

I was looking around & noticed that myself too. We have 5 or 6 internal AD domain names so I'll add them all during our test. We are set to inherit from the Default policy, but that policy only has the root DNS name in the list. If this works, I'll update the default instead of all the individual policies.

Hoping to test with the user tomorrow.

Javier Portuguez · ‎09-27-2012

Great!

Hope to hear good news from you tomorrow

toxicman · ‎09-27-2012

Found a different user and tried this out with no luck. I added in all the domains to the split-dns list and it's still failing. This user doesn't have wireshark running, but we were seeing the same IP come back from a ping test.

One of the domains in the users suffix list is our standard domain, but it's the 6th one out of 7 listed.

This used to work for us on the old VPN Client software, but the ASA seems to have so many other features, I'm not finding the right one for this.

toxicman · ‎09-27-2012

Here's a snip of our config. I tried adding the split-dns list to the Default too, with no luck, and also removing the domain name from the user Policy & let it inherit too, with no luck:

group-policy DfltGrpPolicy attributes

wins-server value 192.168.197.36 192.168.197.30

dns-server value 192.168.197.30 192.168.197.36

vpn-session-timeout 2880

vpn-tunnel-protocol ssl-client ssl-clientless

group-lock value DefaultWEBVPNGroup

ipsec-udp enable

ipsec-udp-port 22847

split-tunnel-policy tunnelspecified

split-tunnel-network-list value HomeSubnets

default-domain value company.com

split-dns value americas.ad.company.com emea-aspac.ad.company.com dmz.ad.company.com asp.ad.company.com ad.company.com company.com oldcompanyname.com

smartcard-removal-disconnect disable

webvpn

anyconnect mtu 1200

anyconnect profiles value CompanyVPNProfile type user

anyconnect ask none default anyconnect

anyconnect ssl df-bit-ignore enable

!

!Here's the user profile

!

group-policy CompanyVPN internal

group-policy CompanyVPN attributes

wins-server value 192.168.197.36 192.168.197.30

dns-server value 192.168.197.30 192.168.197.36

vpn-tunnel-protocol ssl-client ssl-clientless

ip-comp disable

group-lock value CompanyVPN

split-tunnel-policy excludespecified

split-tunnel-network-list value HomeSubnets

split-dns value americas.ad.company.com emea-aspac.ad.company.com dmz.ad.company.com asp.ad.company.com ad.company.com company.com oldcompanyname.com

address-pools value UserVPNPool

webvpn

anyconnect ssl compression none

always-on-vpn profile-setting

!

!HomeSubnets ACL, the user who tested today has a home subnet of 192.168.1.x, the user w/ wireshark is 192.168.11.x

!

access-list HomeSubnets standard permit 192.168.0.0 255.255.255.0

access-list HomeSubnets standard permit 192.168.1.0 255.255.255.0

access-list HomeSubnets standard permit 10.0.0.0 255.255.255.0

access-list HomeSubnets standard permit 192.168.8.0 255.255.255.0

access-list HomeSubnets remark another home subnet

access-list HomeSubnets standard permit 192.168.2.0 255.255.255.0

Javier Portuguez · ‎09-27-2012

Hi Jason,

Checking your configuration I found:

dns-server value 192.168.197.30 192.168.197.36

!

access-list HomeSubnets standard permit 192.168.0.0 255.255.255.0

access-list HomeSubnets standard permit 192.168.1.0 255.255.255.0

access-list HomeSubnets standard permit 10.0.0.0 255.255.255.0

access-list HomeSubnets standard permit 192.168.8.0 255.255.255.0

access-list HomeSubnets remark another home subnet

access-list HomeSubnets standard permit 192.168.2.0 255.255.255.0

!

Please make the following changes:

access-list HomeSubnets standard permit host 192.168.197.30

access-list HomeSubnets standard permit host 192.168.197.36

!

You will also need to add these two hosts to the NAT exempt rule.

In summary:

The DNS servers are not included in the SPLIT ACL. Please add them and adjust the NAT rules.

Thanks.

Portu.

Please rate any helpful posts.

toxicman · ‎09-28-2012

Well that HomeSubnets is used for those who wish to enable local LAN access when they VPN in, if not we are going to tunnel all of their traffic. hosts 192.168.197.30 & 192.168.197.36 exist on the ASA / corporate side of the VPN so we don't want them to be excluded from tunneling. I was able to get a wireshark capture yesterday but the forum site here was down when I went to post.

Here we can see the user is trying to do a lookup when they just ping "othersites" which has an internal DNS entry provided by 192.168.197.30 or .36 with the IP 192.168.10.247.

This wireshark shows the computer stepping through 2 Domain Suffixes against the VPN provided DNS servers, then trying 3 suffixes against their home subnet DNS server, then it goes back, does 3 more against the VPN provided, 1 more on the home subnet, then finally makes it down the list to the one which properly resolves from the VPN provided DNS server.

My temporary fix was to have the user change their Cable Modem / Router to use non-ISP provided DNS servers. it seems their home ISP basically returns any query so the user could be redirected to their search page. (Cox is the provider in question).

We would like to get this resolved though to help with the numerous other users including those who may not have control of their upstream DNS servers such as someone at a hotel.

I can provide more config if that helps too, but looking at this wireshark capture, it seems the computer is misbehaving by trying the home ISP DNS server before exhausting the options provided by the ASA / Anyconnect.

Thoughts?

Javier Portuguez · ‎09-28-2012

Jason,

Have you tried an "ipconfig /flushdns" while connected?

Thanks.

toxicman · ‎09-28-2012

yep, we were trying that too, before every ping attempt, and we were disconnecting / reconnecting AnyConnect when making changes. I'll probably open a TAC case on this as it's been affecting a number of users and it's starting to become an issue for some with legacy applications that have the shortnames configured within them instead of the FQDN.

Javier Portuguez · ‎10-01-2012

Hi Jason,

Have you tried with tunneall?

Indeed a TAC case is a good option, open one and ask for my assistance, I will be glad to help you further.

Thanks.

Portu