Dns not working



  • I've been using OpenVPN for remote clients for quite a while now… several windows and mac os x clients. However, DNS has never worked. Even though I set the DNS server option in the openvpn config, hosts cannot resolve any of the local domains from the DNS server. I've tried both the builtin DNS Forwarder as well as a separate DNS server. Any ideas what is going on, and how to debug this?

    Justin



  • What version of pfSense?  What version of the OpenVPN server are you running and what are your OpenVPN server and client configurations?

    It works fine for me, and many others, so there must be something odd going on with either your client or server configurations.



  • pfSense 1.2.3. I'm mostly using the windows 2.1.1 client, but also tunnelblick on mac os x, which also uses 2.1.1.

    Attached is the config, with the keys omitted.

    Also, in the client config, I have:

    push "route 192.168.2.0 255.255.255.0"; push "route 192.168.3.0 255.255.255.0"
    

    Below is a connection log from mac os x.

    2010-06-11 17:40:59 *Tunnelblick: OS X 10.6.2; Tunnelblick 3.0b26 (build 1395); OpenVPN 2.1.1
    2010-06-11 17:41:01 *Tunnelblick: Attempting connection with XXX.ovpn; Set nameserver = 1; monitoring connection
    2010-06-11 17:41:01 *Tunnelblick: /Applications/Tunnelblick.app/Contents/Resources/openvpnstart start XXX.ovpn 1338 1 0 0 0
    2010-06-11 17:41:02 SUCCESS: pid=4160
    2010-06-11 17:41:02 SUCCESS: real-time state notification set to ON
    2010-06-11 17:41:02 SUCCESS: real-time log notification set to ON
    2010-06-11 17:41:01 OpenVPN 2.1.1 i386-apple-darwin10.2.0 [SSL] [LZO2] [PKCS11] built on Feb  9 2010
    2010-06-11 17:41:01 MANAGEMENT: TCP Socket listening on 127.0.0.1:1338
    2010-06-11 17:41:01  waiting...
    2010-06-11 17:41:02 MANAGEMENT: Client connected from 127.0.0.1:1338
    2010-06-11 17:41:02 MANAGEMENT: CMD 'pid'
    2010-06-11 17:41:02 MANAGEMENT: CMD 'state on'
    2010-06-11 17:41:02 MANAGEMENT: CMD 'log on all'
    2010-06-11 17:41:02 END
    2010-06-11 17:41:02 MANAGEMENT: CMD 'hold release'
    2010-06-11 17:41:02 SUCCESS: hold release succeeded
    2010-06-11 17:41:02 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    2010-06-11 17:41:02 WARNING: file 'XXX.key' is group or others accessible
    2010-06-11 17:41:02 LZO compression initialized
    2010-06-11 17:41:02 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    2010-06-11 17:41:02 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    2010-06-11 17:41:02 Local Options hash (VER=V4): '41690919'
    2010-06-11 17:41:02 Expected Remote Options hash (VER=V4): '530fdded'
    2010-06-11 17:41:02 Socket Buffers: R=[42080->65536] S=[9216->65536]
    2010-06-11 17:41:02 UDPv4 link local: [undef]
    2010-06-11 17:41:02 UDPv4 link remote: XXX:1194
    2010-06-11 17:41:02 
    2010-06-11 17:41:02 
    2010-06-11 17:41:02  sid=2fcdf9ea ec4786dd
    2010-06-11 17:41:03  /C=US/ST=NC/L=XXX/O=XXX/CN=vpn-CA/emailAddress=XXX
    2010-06-11 17:41:03 VERIFY OK: nsCertType=SERVER
    2010-06-11 17:41:03  /C=US/ST=NC/O=XXX/CN=server/emailAddress=XXX
    2010-06-11 17:41:06 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    2010-06-11 17:41:06 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    2010-06-11 17:41:06 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    2010-06-11 17:41:06 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    2010-06-11 17:41:06  1024 bit RSA
    2010-06-11 17:41:06 [server] Peer Connection Initiated with XXX:1194
    2010-06-11 17:41:07 
    2010-06-11 17:41:08 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
    2010-06-11 17:41:08 ifconfig 192.168.4.9 192.168.4.10'
    2010-06-11 17:41:08 OPTIONS IMPORT: timers and/or timeouts modified
    2010-06-11 17:41:08 OPTIONS IMPORT: --ifconfig/up options modified
    2010-06-11 17:41:08 OPTIONS IMPORT: route options modified
    2010-06-11 17:41:08 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
    2010-06-11 17:41:08 ROUTE default_gateway=XXX
    2010-06-11 17:41:08 TUN/TAP device /dev/tun0 opened
    2010-06-11 17:41:08 
    2010-06-11 17:41:08 /sbin/ifconfig tun0 delete
    2010-06-11 17:41:08 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
    2010-06-11 17:41:08 /sbin/ifconfig tun0 192.168.4.9 192.168.4.10 mtu 1500 netmask 255.255.255.255 up
    2010-06-11 17:41:08 /Applications/Tunnelblick.app/Contents/Resources/client.up.osx.sh tun0 1500 1542 192.168.4.9 192.168.4.10 init
    2010-06-11 17:41:09 
    2010-06-11 17:41:09 /sbin/route add -net 192.168.1.0 192.168.4.10 255.255.255.0
    2010-06-11 17:41:09 /sbin/route add -net 192.168.4.1 192.168.4.10 255.255.255.255
    2010-06-11 17:41:09 /sbin/route add -net 192.168.2.0 192.168.4.10 255.255.255.0
    2010-06-11 17:41:09 /sbin/route add -net 192.168.3.0 192.168.4.10 255.255.255.0
    2010-06-11 17:41:09 Initialization Sequence Completed
    2010-06-11 17:41:09 XXX
    
    

    ![Screen shot 2010-06-11 at 5.42.20 PM.png](/public/imported_attachments/1/Screen shot 2010-06-11 at 5.42.20 PM.png)
    ![Screen shot 2010-06-11 at 5.42.20 PM.png_thumb](/public/imported_attachments/1/Screen shot 2010-06-11 at 5.42.20 PM.png_thumb)
    ![Screen shot 2010-06-11 at 5.42.29 PM.png](/public/imported_attachments/1/Screen shot 2010-06-11 at 5.42.29 PM.png)
    ![Screen shot 2010-06-11 at 5.42.29 PM.png_thumb](/public/imported_attachments/1/Screen shot 2010-06-11 at 5.42.29 PM.png_thumb)



  • I don't see in the client log any sign that the DNS server has been pushed to it, which is probably part of your problem.  You may want to follow that issue up with the TunnelBlick folks.  Can you repeat that test with the Windows client and produce it's client log?

    Also, if your clients use any of those 192.168.x.y networks you're using, they will have problems with the VPN.  It would be far better if you were to move away from 192.168.0.x and 192.168.1.x - the most common home network IP ranges.



  • Yeah, I would have done a lot of things differently from the person who originally set this network up. FYI on my test network I use a different subnet (192.168.5.x).

    Here's the log from a windows client:

    Fri Jun 11 19:24:14 2010 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009
    Fri Jun 11 19:24:14 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Fri Jun 11 19:24:15 2010 LZO compression initialized
    Fri Jun 11 19:24:15 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Fri Jun 11 19:24:15 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    Fri Jun 11 19:24:15 2010 Local Options hash (VER=V4): '41690919'
    Fri Jun 11 19:24:15 2010 Expected Remote Options hash (VER=V4): '530fdded'
    Fri Jun 11 19:24:15 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
    Fri Jun 11 19:24:15 2010 UDPv4 link local: [undef]
    Fri Jun 11 19:24:15 2010 UDPv4 link remote: XXX:1194
    Fri Jun 11 19:24:16 2010 TLS: Initial packet from XXX:1194, sid=6958fec4 8f389965
    Fri Jun 11 19:24:17 2010 VERIFY OK: depth=1, /C=US/ST=NC/L=XXX/O=XXX/CN=vpn-CA/emailAddress=XXX@XXX.com
    Fri Jun 11 19:24:17 2010 VERIFY OK: nsCertType=SERVER
    Fri Jun 11 19:24:17 2010 VERIFY OK: depth=0, /C=US/ST=NC/O=XXX/CN=server/emailAddress=cert@XXX.com
    Fri Jun 11 19:24:22 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Fri Jun 11 19:24:22 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Fri Jun 11 19:24:22 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Fri Jun 11 19:24:22 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Fri Jun 11 19:24:22 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    Fri Jun 11 19:24:22 2010 [server] Peer Connection Initiated with XXX
    Fri Jun 11 19:24:24 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
    Fri Jun 11 19:24:24 2010 PUSH: Received control message: 'PUSH_REPLY,route 192.168.2.0 255.255.255.0,ifconfig 192.168.4.201 192.168.4.202'
    Fri Jun 11 19:24:24 2010 OPTIONS IMPORT: --ifconfig/up options modified
    Fri Jun 11 19:24:24 2010 OPTIONS IMPORT: route options modified
    Fri Jun 11 19:24:24 2010 ROUTE default_gateway=10.0.2.2
    Fri Jun 11 19:24:24 2010 TAP-WIN32 device [Local Area Connection 3] opened: \\.\Global\{73865E09-FBCC-4FB2-B1C7-489DFB77854F}.tap
    Fri Jun 11 19:24:24 2010 TAP-Win32 Driver Version 9.6 
    Fri Jun 11 19:24:24 2010 TAP-Win32 MTU=1500
    Fri Jun 11 19:24:24 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.4.201/255.255.255.252 on interface {73865E09-FBCC-4FB2-B1C7-489DFB77854F} [DHCP-serv: 192.168.4.202, lease-time: 31536000]
    Fri Jun 11 19:24:24 2010 NOTE: FlushIpNetTable failed on interface [3] {73865E09-FBCC-4FB2-B1C7-489DFB77854F} (status=6) : The handle is invalid.  
    Fri Jun 11 19:24:30 2010 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
    Fri Jun 11 19:24:30 2010 C:\WINDOWS\system32\route.exe ADD 192.168.2.0 MASK 255.255.255.0 192.168.4.202
    Fri Jun 11 19:24:30 2010 ROUTE: route addition failed using CreateIpForwardEntry: Network access is denied.   [status=65 if_index=3]
    Fri Jun 11 19:24:30 2010 Route addition via IPAPI failed [adaptive]
    Fri Jun 11 19:24:30 2010 Route addition fallback to route.exe
    Fri Jun 11 19:24:30 2010 Initialization Sequence Completed
    

    Here's the typical client config:

    client
    dev tun
    proto udp
    remote XXX 1194
    ping 10
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca ca.crt
    cert XXX.crt
    key XXX.key
    ns-cert-type server
    comp-lzo
    pull
    verb 3
    
    


  • It's resolved. There were two different problems. One was with Tunnelblick. I switched to a different VPN client on the Mac (Viscosity) which worked right away. The problem with the Windows PC was that I was using a different VPN config, who's alias was mistakingly being blocked from DNS via a firewall rule.


Locked