0

We have an ASA5505 and it is the backbone of our network that controls the DHCP/NAT rules/Firewall etc.

We are having issues with VPN users being able to access local systems.

We are able to ping IP addresses and the FQDN (server.domain.local) but they are unable to ping or access the system through the server name. (\server for example)

I have done every configuration I can think of through the server but unable to resolve the DNS resolution issue.

I am thinking the ASA 5505 may be blocking it under the policy rules (asdm).

Does anyone have any ideas?

Thanks in advance!

gravyface
  • 13,957
  • 19
  • 68
  • 100
Lbaker101
  • 309
  • 2
  • 8
  • 18
  • What do the log files on the ASA say? You should be seeing drops recorded there if the ASA is indeed blocking things. – rmalayter Dec 27 '11 at 21:43
  • I have it set to report anything from "warning" on up. So i guess its not so much the asa but some configuration. do you know of any settings within it to have it allow the system names to go through? – Lbaker101 Dec 27 '11 at 22:06

2 Answers2

1

Are those names being resolved through NetBIOS name resolution, or DNS?

If it's NetBIOS, then set up DNS; the broadcast traffic that it's using isn't going to traverse the VPN tunnel.

If it's DNS, then you should just need to set up a search suffix in the client VPN policy that gets sent to connected clients.

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
1

Likely not an issue with the ASA blocking per se -- but a DNS 101 issue. In general, a network interface in Windows should have a connection-specific DNS suffix. It is not required, but if it exists will be added to the DNS suffix search list.

The network interface connection-specific DNS suffix is either learned or statically assigned by the administrator. In the case of DHCP -- the DHCP server returns (Option 15 and/or Option 119) values that the DHCP client uses. In the case of static assignments -- the suffix can be statically assigned.

In the case of remote access VPN users the administrator generally has to configure the domain name and/or suffix search order on the VPN server/endpoint. On an ASA this is configured in the ASA's group-policy for the specific group-policy that is matched (from AnyConnect or IPSec).

The below snippet assumes the Default Group Policy (DfltGrpPolicy) and sets the domain-name to acme.local. Note that the Default Group Policy should not be used in production environments (it is rather trivial to create one).

group-policy DfltGrpPolicy internal
group-policy DfltGrpPolicy attributes
 dns-server value 10.0.0.10 10.0.0.11
 default-domain value acme.local

@SpacemanSpiff

In short, yes. Beginning with ASA 7.0.1 the sysopt connection permit-vpn global configuration command has been enabled by default. This command allows traffic egressing a VPN tunnel (L2L or RA), having been decrypted, to bypass interface ACL's. Traffic ingressing the VPN tunnel (to be encrypted) still hits the interface ACL first.

With sysopt connection permit-vpn in place and left alone (recommended) -- one can control VPN traffic with both group-policy and user ACL's configured with the vpn-filter command in the correct mode. However, without vpn-filter (but with sysopt connection permit-vpn) in place the ASA will forward L2L and RA VPN traffic that it decrypts without regard for interface ACL's.

If one enters no sysopt connection permit-vpn then one must explicitly permit IKE, ESP (and others) in addition to decrypted traffic for it to be permitted. However, I (like many) find it simpler (and just as secure) to leave sysopt connection permit-vpn in place and use vpn-filter when needed.

Weaver
  • 1,952
  • 12
  • 13