Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've got the following set up:

LAN ->  DHCP / DNS / VPN server (OSX 10.6) -> Cisco ASA 5505 -> WAN

Connecting to the LAN via VPN works fine. I get all the details properly and I can ping any host on the internal network using their IP. However, I can't do any host lookups whatsoever. I've looked through the logs on and found this nugget in the firewall log:

3 Sep 08 2010 10:46:40 305006 10.0.0.197 65371 portmap translation creation failed for udp src inside:myhostname.local/53 dst inside:10.0.0.197/65371

Port 53 is dns services, no? Because of that log entry, I'm thinking that the issue is with the firewall, not the server. Any ideas? Please keep in mind that I have very little knowledge and experience with this kind of firewall and the little experience I do have is with the ASDM GUI console, not the CLI console.

share|improve this question
    
As a first step, verify that the VPN client is set to use your internal DNS servers for name resolution. On a Windows client you can check this by running ipconfig/all from a command line. –  joeqwerty Sep 8 '10 at 12:15
    
I've verified that all the settings are ok. Additionally, I've tried nslookup and specifying the server to be the internal DNS. Pinging any client on the internal network works, including the DNS server so it is indeed reachable. However, all attempts att name resolution ends with a time out. However, trying name resolution with an external server, such as googles, works just fine. –  macke Sep 8 '10 at 14:38
    
portmap translation errors indicate a problem with ip address translations. if you are using nat make sure you have an entry for both src/dst ip addresses; if you are using 'nat 0'the same is true. –  ChrisV Jul 31 '11 at 0:29
    
This question seems similar in nature. –  alx9r Nov 11 '12 at 16:33
    
Sorry to say but if you don't know how the firewall works, please leave your fingers out of it. In the end you will have gigantic security hole. That said, there is an option in ASDM that shows you what commands are being pushed to the ASA when clicking "Apply", so that might be a possibility to learn what it's doing, since ASDM is doing nothing more than create CLI commands which it sends to the ASA. –  Marki Aug 11 '13 at 10:46

4 Answers 4

1) Are your clients establishing the tunnel directly with the ASA or with the "VPN server" in your diagram? 2) Are your VPN clients being given the same IP range as your internal network or a separate range?

Based on the log entry, it sounds like your clients are establishing the tunnel to the ASA and given a different subnet than the internal network. If this is the case, I think you need a NAT exemption rule on your ASA to tell it not to try and NAT traffic between your internal IP range and your VPN IP range. This preserves your source (VPN subnet) and destination networks (internal subnet) so the ASA doesn't think it needs a public/private NAT rule for access to the internal network based on the 2 interfaces it is seeing the traffic come through on. In the GUI this is under: Configuration tab>>Firewall>>NAT Rules although I've had mixed experiences making rules like this in the GUI - might have to go to the CLI.

share|improve this answer
    
1) Not with the ASA. 2) Same IP range. I think you may very well be right. However, I can't really make sense of the GUI either. –  macke Sep 8 '10 at 18:33
    
I'm not sure I'm getting this correctly, should I make an exempt rule going from inside-network/24 to inside-network/24? I tried, but it didn't work. Log still shows the same errors. –  macke Sep 8 '10 at 19:56

In my experience this should work with the out of the box config of the ASA. Check for any DHCP settings on the ASA that might be overriding your settings from your LAN DHCP server.

Lines to look for are dhcpd domain, dhcpd dns and dhcpd auto_config.

The setup I use is pretty robust, but has the ASA doing DHCP for the local clients - this means that if the VPN goes down, users still have access to local systems.

share|improve this answer

I have no experience with the specific hardware you are working with. However, with openvpn, you need to have bridge the network for dns queries to work. From the sounds of things, you already have a bridged VPN set up (i.e. your client ip address is on the same range as that of the destination network).

When you set up a bridged network like so, your dns server might still be binding to the original ethernet interface instead of the new bridged interface.

If that is the case, the packets will not get router correctly. Get the DNS Server to bind to the bridge interface or even better to the ip address of the bridge interface so that it will work regardless of whether the VPN is active or not.

share|improve this answer

I has the same issue with Cisco VPN Client working with USB GSM modem. The problem was solved using the next sentence in ASA Cisco ASA.

group-policy TestVPN attributes
  split-dns value dominioprivado1.com dominioprivado1.org dominioprivado1.net 

Where "dominioprivado1.com dominioprivado1.org dominioprivado1.net" are the DNS zones that contain the servers's names privates.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.