[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

[Openvpn-users] DNS Caveat


  • Subject: [Openvpn-users] DNS Caveat
  • From: "Simon Ironside" <sironside@xxxxxxxxxxxxx>
  • Date: Wed, 22 Sep 2004 12:04:29 +0100

Hello,
 
I've mentioned this before but I haven't had a reply so I thought I'd log this issue as completely as I can! I've searched the list archives and found this problem mentioned before but cannot find a solution.
 
"Client" End:
OpenVPN 1.6.0 on Windows XP SP1
Connecting via Internet through any one of 3G, GPRS, WLAN/Cable Router, LAN/Cable Router, Dial-up.
The 3G/GPRS connection is treated as a Dial-up connection by Windows.
 
"Server" End:
OpenVPN 1.6.0 on FreeBSD 4.10 - I think this end is irrelevant, I believe the problem lies at the client end.
 
Problem:
 
The tunnel comes up okay, I can ping the DNS servers using their IP addresses but I cannot resolve DNS names using the DNS servers on the other side of the tunnel.
 
I believe I am experiencing the caveat mentioned in the openvpn examples and in:
http://support.microsoft.com/default.aspx?scid=kb;en-us;311218&Product=winxp
 
I've followed the instructions on the Microsoft site but this doesn't fix the problem. I've also tried moving the id of the TAP-32 adapter to the top of the "pile" and this doesn't help either.
 
I have managed a ropey work around, a batch file called by route-up that essentially executes the command line:
 
netsh interface ip set dns "Forth Ports VPN" static 10.2.0.31 primary
 
The disadvantage is that this kills the tunnel (cannot ping the other end when I could just before route-up was executed) until it does a ping-restart (hence my very short ping and ping-restart times in the configuration files.)
 
Is there a better workaround for this?
 
If this is something that is made better or fixed in the current beta of 2.0, to appease my natural aversion to beta software in a production environment, are the "1.6.0" features just as stable as they are in 1.6.0? I.e. if I chose not to implement the "server" mode could I expect the current beta of 2.0 to be just as reliable as 1.6.0?
 
I've pasted the configurations and the fixdns.bat file at the bottom of this message.
 
<snip>
 
# OpenVPN client config
remote somehost.somewhere.com
port 5003  
dev tun
dev-node "VPN"
ifconfig 10.255.0.10 10.255.0.9
up-delay
dhcp-option DOMAIN somewhere.net
dhcp-option DNS 10.2.0.31
dhcp-option DNS 10.2.0.32
route-up fixdns.bat

tls-client
ca fpgmvpn01-ca.crt
cert devlir-laptop.crt
key devlir-laptop.key
reneg-sec 900
comp-lzo
 
tun-mtu 1500
fragment 1450
mssfix

ping 3                 
ping-restart 5        
ping-timer-rem         
persist-tun            
persist-key           
 
verb 3
route 10.0.0.0 255.255.0.0 10.255.0.9 
route 10.1.0.0 255.255.0.0 10.255.0.9 
route 10.2.0.0 255.255.0.0 10.255.0.9  
route 10.3.0.0 255.255.0.0 10.255.0.9  
route 10.4.0.0 255.255.0.0 10.255.0.9  
route 10.5.0.0 255.255.0.0 10.255.0.9  
route 10.6.0.0 255.255.0.0 10.255.0.9  
route 10.7.0.0 255.255.0.0 10.255.0.9  
route 10.8.0.0 255.255.0.0 10.255.0.9  
route 10.10.0.0 255.255.0.0 10.255.0.9  
route 155.155.0.0 255.255.0.0 10.255.0.9 
 
route 192.168.10.0 255.255.255.0 10.255.0.9 
route 192.168.11.0 255.255.255.0 10.255.0.9 
route 192.168.12.0 255.255.255.0 10.255.0.9 
route 192.168.13.0 255.255.255.0 10.255.0.9 
<snip>
 
# OpenVPN server config
float
port 5003
dev tun  
ifconfig 10.255.0.9 10.255.0.10 

user nobody
group nobody

tls-server   
ca /usr/local/openvpn/fpgmvpn01-ca.crt 
dh /usr/local/openvpn/dh2048.pem 
cert /usr/local/openvpn/fpgmvpn01.crt 
key /usr/local/openvpn/fpgmvpn01.key 
reneg-sec 900
   
comp-lzo 
  
tun-mtu 1500    
fragment 1450    
mssfix     
 
ping 3   
ping-restart 5  
ping-timer-rem  
persist-tun  
persist-key  

verb 3     
log /usr/local/openvpn/devlir-laptop.log 
writepid /usr/local/openvpn/devlir-laptop.pid
 
<snip>

@echo off
rem fixdns.bat
rem OpenVPN FixDNS script - executed after routes are up

rem Fix DNS issue
netsh interface ip set dns "VPN" static 10.2.0.31 primary