Introduction
Companies often run their own DNS server that they use to resolve DNS names to private IP addresses, to make accessing systems easier for users. It is for example easier to tell a user to start their Remote Desktop client program and to connect to server1 instead of having to tell them to connect to 192.168.70.243. To learn what DNS is, see this article. OpenVPN Access Server supports pushing an instruction to a connecting OpenVPN client to use a specific DNS server. Actually it supports pushing 2 DNS servers, in case the first one fails to respond. This can be configured in the Admin UI under VPN Settings. The Access Server also supports sending additional instructions for DNS Resolution Zones, which functions like a type of split-DNS where only queries for a specific DNS zone are sent to the VPN server, and DNS Default Suffix, which provides a hint to Windows to ‘autocomplete’ a partial hostname to a Fully Qualified Domain Name, or FQDN.
Unfortunately, not every operating system behaves the same in regards to DNS. Some systems will try all DNS servers at once, and accept the response from the first to respond. Others will be able to do split-DNS, and others will not. This can lead to certain problems. The guide below provides a way of checking to see if the DNS query you are doing from your OpenVPN client device, is actually making it through the VPN tunnel to the OpenVPN Access Server. And from there, of course, to the target DNS server. This information is valuable in determining whether or not the problem is at the client end, or at the server end.
Testing DNS resolution from a client system
We are going to assume that you have a DNS server configured in the Admin UI of the Access Server, under VPN Settings. We are assuming you are not using the DNS Resolution Zones or the DNS Default Suffix fields. With this setting, all DNS request should be going from the OpenVPN client, through the OpenVPN Access Server, and then to the specified DNS server. In our example we are pushing the Google Public DNS server 8.8.8.8, and our test results will reflect this in the sample outputs as well.
Install your OpenVPN client program on your chosen client system. In our example we will be using a Windows 10 Professional client system with the OpenVPN Connect Client installed, and connected to the OpenVPN Access Server. Next open a console session or an SSH session to the OpenVPN Access Server, and obtain root privileges. We will be using the tool tcpdump to monitor activity on port 53 TCP and UDP, the default port where DNS queries are handled. We will be flushing the local DNS resolver cache on the client side, and then resolve a number of domains simply by pinging them by name. In our test situation, there are only a handful of clients connected, and the activity of DNS queries is very low, so we can monitor it easily. If you are testing on a production system and the tcpdump command gives too much output, you can append a grep filter by IP address, to filter queries coming only from your specific VPN client’s IP address, to make reading and locating the DNS query results easier.
On the Access Server run these commands:
apt-get update apt-get install tcpdump
With TCPdump installed, now run it with these parameters:
tcpdump -eni any port 53
Or, if you want to filter it by the IP address of your VPN client (adjust as needed):
tcpdump -eni any port 53 | grep "172.27.10.22"
With this running in the background, go to your VPN client’s operating system, and open a command prompt. On Windows for example you can run the cmd program to open an old style DOS prompt. With that open, use the following commands to wipe the local DNS resolver cache, so it won’t pull results from its own local memory, and then do an actual query.
Wipe local DNS resolver cache on Windows:
ipconfig /flushdns
Resolve some domain names:
ping www.google.com ping www.openvpn.net ping www.facebook.com
Each of these should yield results that look somewhat like this:
Pinging www.google.com [216.58.212.228] with 32 bytes of data: Reply from 216.58.212.228: bytes=32 time=4ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Reply from 216.58.212.228: bytes=32 time=3ms TTL=56 Ping statistics for 216.58.212.228: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 4ms, Average = 3ms
On the OpenVPN Access Server you should be seeing results that look somewhat like this:
18:03:07.976553 In ethertype IPv4 (0x0800), length 76: 172.27.232.2.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.976579 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.49531 > 8.8.8.8.53: 53268+ A? www.google.com. (32) 18:03:07.981162 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 192.168.47.133.49531: 53268 1/0/0 A 216.58.211.100 (48) 18:03:07.981181 Out ethertype IPv4 (0x0800), length 92: 8.8.8.8.53 > 172.27.232.2.49531: 53268 1/0/0 A 216.58.211.100 (48)
The above result from tcpdump shows that a DNS request was received from the VPN client at 172.27.232.2, and that it was directed at the DNS server at 8.8.8.8, and the request was to find the A record (IP address) for the DNS name www.google.com. The first line shows that this request is coming in at the OpenVPN Access Server, from the VPN client. The second line shows the request leaving the Access Server through the network interface with MAC address 00:0c:29:c7:60:e9. In our test setup, this is the network interface of the Access Server that goes to the Internet, which makes sense, because the 8.8.8.8 DNS server is on the Internet. The third line shows that a DNS result has been received, and the fourth line shows that this result has been relayed back to the VPN client. In this case, DNS resolution is working.
Split-DNS when using DNS Resolution Zones
Split-DNS is the principle of resolving only certain zones (domains) through a DNS server pushed by the VPN server, and the rest through your already present local DNS servers. In Access Server there is a field in the Admin UI, under VPN Settings, called DNS Resolution Zones. If you enter a single domain or a list of (comma-separated) domains here, then the clients will receive an instruction to only resolve those domains through the DNS server pushed by the VPN server, and resolve the rest through the client’s local DNS server.
Please note that not all OpenVPN clients out there support this and there are some differences in behavior between versions of OpenVPN as well. The best results can be achieved by using OpenVPN Connect v3 client software.
When you use split-DNS, you will not see the DNS server that is being pushed in your ipconfig or ifconfig output. The DNS server will not get implemented at the network interface configuration level. Instead, it will be implemented in the DNS system in a DNS resolution policy table. On mac OS for example this can be queried using the scutil command line utility and on Windows this can be queried using netsh to query the resolution policy table in the OS. Such a table is simply a list of domains, and which DNS servers they should be resolved through. Below we will show example output of how split-DNS and normal DNS resolution looks like through a VPN tunnel. Some superfluous data has been removed from these example outputs.
Commands to see network configuration and DNS resolution policy on Windows:
ipconfig /all netsh namespace show effectivepolicy
Commands to see network configuration and DNS resolution policy on mac OS:
ifconfig scutil -dns
Example output on Windows when split-DNS is currently in use:
(OpenVPN) adapter Local Area Connection:
Description . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
Ethernet adapter Ethernet:
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
DNS Servers . . . . . . . . . . . : 192.168.47.254
DNS Effective Name Resolution Policy Table Settings
Settings for .openvpn.net
----------------------------------------------------------------------------
Generic (DNS Servers) : 1.2.3.4
In the above output, you can see that split-DNS is now being used because the DNS server assigned to the normal network interface called Ethernet that connects to our local network has DNS server 192.168.47.254, which is our local DNS server, and the Name Resolution Policy Table has a zone for .openvpn.net that resolves through 1.2.3.4, which is the DNS server pushed by the VPN server. This means that *.openvpn.net will get resolved through the VPN DNS server, and the rest will resolve through the local DNS server 192.168.47.254. Note also that the VPN interface gets 3 IPv6 self-assigned DNS server addresses, which are not assigned by OpenVPN, but by the OS itself. This should not affect DNS resolution.
Example output on Windows when split-DNS is not used:
(OpenVPN) adapter Local Area Connection: Description . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect DNS Servers . . . . . . . . . . . : 1.2.3.4 DNS Effective Name Resolution Policy Table Settings Settings for . ---------------------------------------------------------------------------- Generic (DNS Servers) : 1.2.3.4
In the above output, you can see that split-DNS is not being used because the DNS server is assigned to the network interface adapter itself, and there is only one top level zone for DNS resolution (the dot means all zones). This means that this configuration is not using split-DNS and therefore all DNS queries get redirected to the server at 1.2.3.4.
Troubleshooting
Below are a number of common problems you can see that we try to explain here and where to look for a solution.
Ping request could not find domain (…). Please check the name and try again This can happen when the DNS servers your client system is using is badly configured, cannot be reached, or if the DNS server it is using does not know the domain you are trying to resolve. For example with local DNS servers in your own network it is entirely possible that they only know local computer systems, and have no knowledge of online names like openvpn.net or such. Usually in such a case you can configure the DNS server to forward DNS queries to a public DNS server that does know the answer to those queries, so that it is able to respond to both queries for local names and also public names. A useful step in this situation may be to again run tcpdump as described in the testing DNS resolution from a client system section above, and checking to see what the output of tcpdump is.
If you see a result like this:
18:07:10.082330 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082356 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.54519 > 8.8.8.8.53: 50281+ A? thisdomainreallydoesnotexist.com. (50) 18:07:10.082507 In ethertype IPv4 (0x0800), length 94: 172.27.232.2.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.082521 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 94: 192.168.47.133.57858 > 8.8.8.8.53: 65054+ AAAA? thisdomainreallydoesnotexist.com. (50) 18:07:10.103610 In 34:31:c4:8e:b5:67 ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 192.168.47.133.54519: 50281 NXDomain 0/1/0 (123) 18:07:10.103641 Out ethertype IPv4 (0x0800), length 167: 8.8.8.8.53 > 172.27.232.2.54519: 50281 NXDomain 0/1/0 (123)
Specifically the item NXDomain here is important. It means that this DNS server does not know the name we are trying to resolve. Another DNS might still know the name. but this one doesn’t. In the example above however we have purposefully selected a name that does not exist (or at least it didn’t when we ran the test — it is possible of course someone may register the name in the future) to be sure we see the error. If you are encountering this problem you may want to try to use the nslookup program on a computer with direct access to the DNS server, and use it to query the specific DNS server directly, to confirm that it does know the domain.
If you see a result like this, repeated a few times:
18:19:29.935439 Out 00:0c:29:c7:60:e9 ethertype IPv4 (0x0800), length 76: 192.168.47.133.60180 > 1.2.3.4.53: 16427+ AAAA? www.google.com. (32) 18:19:29.935479 In ethertype IPv4 (0x0800), length 76: 172.27.232.3.51334 > 1.2.3.4.53: 37513+ A? www.google.com. (32)
Then what you may notice here is that you do see a query arriving from the VPN client, pass through the Access Server, and go out to the Internet, but there is no reply. Usually this means that this DNS server is unreachable, or is not a DNS server at all. In the example I have chosen IP address 1.2.3.4 which I know for a fact is not a DNS server. Obviously the query will be repeated a few times but will ultimately fail. The obvious solution here is to choose a DNS server that works, or, to make sure that there is no firewall standing in the way, blocking the queries from the VPN clients to the DNS server. In some cases, when routing is used to give VPN clients access to servers on the private network behind the Access Server, it is a matter of a missing route. In such a case that packets from VPN clients make it to the target DNS server just fine, but it is not able to respond because it is receiving packets from a subnet it does not know how to respond to. That can be solved by implementing static routes for direct VPN client communication, or switching to giving access using NAT instead. In other cases we’ve seen, especially on Windows Server platforms, the built-in Windows Firewall could be blocking queries coming from a subnet outside of the local network. In such a case an adjustment to the firewall is necessary to allow the DNS server to receive the query and respond to it.
When I connect to a VPN network through Gnome Network-manager I lose DNS resolution and in practice, I cannot access resources inside the VPN network or outside.
When I was using Ubuntu 16.04 and I was using the VPN, the «/etc/resolv.conf/» file would contain the DNS servers of the (VPN) network I had connected. Now it always contains the following entries:
nameserver 127.0.0.53
search myprovider.com
From what I have understood 127.0.0.53 is the address of the DNS stub used by the system-resolved.
I suspect that this is a bug because the VPN was working fine the Ubuntu 16.04. Is there any way that I can set the DNS servers of my network when I am using a VPN service?
Update:
I tried connecting to the OpenVPN network with the configuration file attached at the end of the post, but I get the following error:
Authenticate/Decrypt packet error: cipher final failed
I have verified that the server uses lzo compression and I have enabled it as well. The connection stays active but I cannot navigate to any page inside or outside the VPN.
In the configuration file listed below, I have included the solutions posted in the replies
client
dev tun
proto udp
remote openvpn.bibsys.no 1194
remote my-server-2 1194
resolv-retry infinite
nobind
user myuser
group myuser
persist-key
persist-tun
ca ca-cert.pem
cert openvpn.crt
key openvpn.key
cipher AES-256-CBC
comp-lzo yes
script-security 2
up /etc/openvpn/scripts/update-systemd-resolved
down /etc/openvpn/scripts/update-systemd-resolved
down-pre
asked May 5, 2018 at 17:06
1
Problem
The file /etc/resolv.conf does not get updated by the /etc/openvpn/update-resolv-conf script because resolvconf is not installed by default on ubuntu 18.04.
In fact, one of the first lines of that script checks for the /sbin/resolvconf executable:
[ -x /sbin/resolvconf ] || exit 0
Installing resolvconf via apt-get is not a solution as the /etc/openvpn/update-resolv-conf script updates the /etc/resolv.conf file with the pushed DNS entry but the tun device seems to ignore it.
Solution
-
Ubuntu 18.04 uses
systemd-resolved, so all you have to do is install the openvpn helper script forsystemd-resolvedviasudo apt install openvpn-systemd-resolvedor with these GitHub instructions
-
Update your
config.ovpnfile adding these lines:script-security 2 up /etc/openvpn/update-systemd-resolved down /etc/openvpn/update-systemd-resolved down-preThat instead of adding up and down of
/etc/openvpn/update-resolv-confto the conf. -
To prevent DNS Leakage, you should add this line to the end of the
config.ovpnfile (according to this systemd issue comment):dhcp-option DOMAIN-ROUTE .
answered May 14, 2018 at 18:09
QlimaxQlimax
1,3492 gold badges5 silver badges5 bronze badges
16
I found a solution on this blog post. While there are two solutions mentioned, I prefer using the second one because it means my DNS is set by the OpenVPN server (the first solution means I use the same DNS servers whether or not I’m connected to the OpenVPN server).
In short:
sudo mkdir -p /etc/openvpn/scriptssudo wget https://raw.githubusercontent.com/jonathanio/update-systemd-resolved/master/update-systemd-resolved -P /etc/openvpn/scripts/sudo chmod +x /etc/openvpn/scripts/update-systemd-resolved
Then edit your OpenVPN client file (e.g. client.ovpn) by changing the up/down scripts to:
script-security 2
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
up /etc/openvpn/scripts/update-systemd-resolved
down /etc/openvpn/scripts/update-systemd-resolved
(I have commented out the original up/down settings).
answered May 15, 2018 at 22:23
Andy TurferAndy Turfer
1,65813 silver badges14 bronze badges
11
Actually, there is a much easier solution to this problem. The issue is with DNS traffic and how Ubuntu 18 manages that. By default IP forwarding is disabled which is what OpenVPN needs in order to provide proper networking. All you have to do is run the following command:
sudo nano /etc/sysctl.conf
Once you have this file opened, look for the line that contains net.ipv4.ip_forward. If this line is commented, remove the # sign at the front of the line (if it is not commented then you have another issue). Save the file and then restart your OpenVPN server instance.
This fix does not require any modifications to the client or OpenVPN code following upgrade to Ubuntu 18. Tested and confirmed working.
However, this obviously requires you can administer the server. And unfortunately, the bug exists for many who just connect with 18.04 to an OpenVPN server that is administered by somebody else…
answered Sep 15, 2018 at 19:32
MaxMax
951 silver badge1 bronze badge
4
Tested on Ubuntu 18.04 at 13 Sep 2018
There is another useful command to setup what you need via command line. You can control your VPN connection both with command line and GUI.
sudo nmcli connection add type vpn vpn-type openvpn con-name la.vpn.contoso.com ifname --
ifname -- is the required by default, but does not affect anything
sudo nmcli connection modify la.vpn.contoso.com ipv4.dns 172.16.27.1
sudo nmcli connection modify la.vpn.contoso.com ipv4.dns-search int.contoso.com
sudo nmcli connection modify la.vpn.contoso.com ipv4.never-default yes
never-default should not use remote gateway as default route
And much more interested final touch:
nmcli connection modify la.vpn.contoso.com vpn.data 'ca = /tmp/la.vpn.contoso.com/you/ca.crt, key = /tmp/you.key, dev = tun, cert = /tmp/you.crt, cert-pass-flags = 1, comp-lzo = adaptive, remote = la.vpn.contoso.com:1194, connection-type = tls'
Afterwards you can control vpn with GUI or use following commands:
sudo nmcli --ask connection up la.vpn.contoso.com
sudo nmcli connection down la.vpn.contoso.com
Matthieu
4662 silver badges16 bronze badges
answered Sep 13, 2018 at 14:38
vskubrievvskubriev
8877 silver badges14 bronze badges
If your system is using NetworkManager, then you may only need to change the connection’s DNS priority, as per this answer:
nmcli -p connection modify VPN_CONNECTION_NAME ipv4.dns-priority -1
In my case, the DNS was being updated, but ignored as the existing DNS servers had precedence. You may need root/sudo. If that doesn’t work, try ipv6.dns-priority.
answered Aug 6, 2020 at 1:54
WalfWalf
3771 gold badge3 silver badges14 bronze badges
I’m impacted too. In my case, I’m using OpenVPN with an internal name server (which is inside the VPN). That worked until Ubuntu 17.10 (with hosts: files dns in /etc/nsswitch.conf).
/etc/resolv.conf was updated correctly by the openvpn scripts (through calls to /etc/openvpn/update-resolv-conf in the openvpn client configuration file).
However, name resolution for hosts inside the VPN was not working any more (or at least sporadically… I guess the local DNS cache was picking the names, but after a rather long time).
What seems to help, or even resolve the issue (though that’s too early to say) is to install the below package:
sudo apt install openvpn-systemd-resolved
Matthieu
4662 silver badges16 bronze badges
answered May 10, 2018 at 14:48
2
None of the proposed CLI-oriented (non-NetworkManager) solutions worked for me (I don’t even have up and down lines in myconfig.ovpn).
However, I’ve found that NetworkManager VPN seems to work again (it did not work a year or two ago, which is why I switched to openvpn CLI then). I did not tweak it in any way: just tried to activate it with the appropriate credentials.
answered Oct 17, 2021 at 10:34
Here is my (x)ubuntu version:
root@ubuntu:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty
network-manager has been purged; I made an apt-clean after desinstallation. you need network-manager-openvpn package when running openvpn with network-manager
Before I mount the vpn, here is what we have:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
wlan0 Link encap:Ethernet HWaddr 00:24:01:ee:91:3d
inet addr:192.168.2.79 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::224:1ff:feee:913d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:539 errors:0 dropped:0 overruns:0 frame:0
TX packets:442 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:628026 (628.0 KB) TX bytes:56869 (56.8 KB)
Ping is filtered by the ISP:
root@ubuntu:~# ping www.google.com
PING www.google.com (64.233.167.103) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=1 Destination Net Prohibited
From 192.168.2.1 icmp_seq=2 Destination Net Prohibited
From 192.168.2.1 icmp_seq=3 Destination Net Prohibited
I can ping the stack:
root@ubuntu:~# ping 192.168.02.79
PING 192.168.02.79 (192.168.2.79) 56(84) bytes of data.
64 bytes from 192.168.2.79: icmp_seq=1 ttl=64 time=0.023 ms
64 bytes from 192.168.2.79: icmp_seq=2 ttl=64 time=0.049 ms
I installed client configuration from a free VPN provider here is the client configuration:
client
dev tun1
proto tcp
remote 93.115.83.250 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
comp-lzo
verb 3
cipher AES-128-CBC
fast-io
pull
route-delay 2
redirect-gateway
###---I just added the following: ----
verb 6
I connect to the vpn server:
Thu Dec 4 15:16:36 2014 us=990883 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Dec 4 15:16:36 2014 us=990952 NOTE: --fast-io is disabled since we are not using UDP
Thu Dec 4 15:16:36 2014 us=992665 LZO compression initialized
Thu Dec 4 15:16:36 2014 us=992867 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu Dec 4 15:16:36 2014 us=992969 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu Dec 4 15:16:36 2014 us=993035 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
Thu Dec 4 15:16:36 2014 us=993091 Local Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Thu Dec 4 15:16:36 2014 us=993113 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Thu Dec 4 15:16:36 2014 us=993170 Local Options hash (VER=V4): 'bc07730e'
Thu Dec 4 15:16:36 2014 us=993211 Expected Remote Options hash (VER=V4): 'b695cb4a'
Thu Dec 4 15:16:36 2014 us=993259 Attempting to establish TCP connection with [AF_INET]93.115.83.250:443 [nonblock]
Thu Dec 4 15:16:37 2014 us=993523 TCP connection established with [AF_INET]93.115.83.250:443
Thu Dec 4 15:16:37 2014 us=993596 TCPv4_CLIENT link local: [undef]
Thu Dec 4 15:16:37 2014 us=993625 TCPv4_CLIENT link remote: [AF_INET]93.115.83.250:443
Thu Dec 4 15:16:37 2014 us=993748 TCPv4_CLIENT WRITE [14] to [AF_INET]93.115.83.250:443: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Thu Dec 4 15:16:38 2014 us=90125 TCPv4_CLIENT READ [26] from [AF_INET]93.115.83.250:443: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Thu Dec 4 15:16:38 2014 us=90205 TLS: Initial packet from [AF_INET]93.115.83.250:443, sid=c7148944 7465b88f
Thu Dec 4 15:16:38 2014 us=90260 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 0 ]
Thu Dec 4 15:16:38 2014 us=90329 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Dec 4 15:16:38 2014 us=90360 TCPv4_CLIENT WRITE [114] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100
Thu Dec 4 15:16:38 2014 us=90385 TCPv4_CLIENT WRITE [114] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Thu Dec 4 15:16:38 2014 us=90409 TCPv4_CLIENT WRITE [39] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=25
Thu Dec 4 15:16:38 2014 us=320860 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 1 ]
Thu Dec 4 15:16:38 2014 us=454622 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 2 ]
Thu Dec 4 15:16:38 2014 us=454685 TCPv4_CLIENT READ [126] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ 3 ] pid=1 DATA len=100
Thu Dec 4 15:16:38 2014 us=454770 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=100
Thu Dec 4 15:16:38 2014 us=454791 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=100
Thu Dec 4 15:16:38 2014 us=454812 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=4 DATA len=100
Thu Dec 4 15:16:38 2014 us=454833 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 1 ]
Thu Dec 4 15:16:38 2014 us=454882 TCPv4_CLIENT WRITE [30] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 2 3 4 ]
Thu Dec 4 15:16:38 2014 us=550166 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Thu Dec 4 15:16:38 2014 us=550236 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 5 ]
Thu Dec 4 15:16:38 2014 us=647096 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=100
Thu Dec 4 15:16:38 2014 us=647160 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 6 ]
Thu Dec 4 15:16:38 2014 us=742280 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=100
Thu Dec 4 15:16:38 2014 us=742347 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=8 DATA len=100
Thu Dec 4 15:16:38 2014 us=742399 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 7 ]
Thu Dec 4 15:16:38 2014 us=742419 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 8 ]
Thu Dec 4 15:16:38 2014 us=836052 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=100
Thu Dec 4 15:16:38 2014 us=836258 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 9 ]
Thu Dec 4 15:16:38 2014 us=929756 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=10 DATA len=100
Thu Dec 4 15:16:38 2014 us=929826 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 10 ]
Thu Dec 4 15:16:39 2014 us=23949 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=11 DATA len=100
Thu Dec 4 15:16:39 2014 us=24066 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=12 DATA len=100
Thu Dec 4 15:16:39 2014 us=24098 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 11 ]
Thu Dec 4 15:16:39 2014 us=24124 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 12 ]
Thu Dec 4 15:16:39 2014 us=117875 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=13 DATA len=100
Thu Dec 4 15:16:39 2014 us=117994 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 13 ]
Thu Dec 4 15:16:39 2014 us=212512 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=14 DATA len=100
Thu Dec 4 15:16:39 2014 us=212671 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 14 ]
Thu Dec 4 15:16:39 2014 us=307308 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=15 DATA len=100
Thu Dec 4 15:16:39 2014 us=307424 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=16 DATA len=100
Thu Dec 4 15:16:39 2014 us=307456 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 15 ]
Thu Dec 4 15:16:39 2014 us=307483 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 16 ]
Thu Dec 4 15:16:39 2014 us=401580 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=17 DATA len=100
Thu Dec 4 15:16:39 2014 us=401755 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 17 ]
Thu Dec 4 15:16:39 2014 us=496062 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=18 DATA len=100
Thu Dec 4 15:16:39 2014 us=496182 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 18 ]
Thu Dec 4 15:16:39 2014 us=591394 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=19 DATA len=100
Thu Dec 4 15:16:39 2014 us=591551 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=20 DATA len=100
Thu Dec 4 15:16:39 2014 us=591628 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 19 ]
Thu Dec 4 15:16:39 2014 us=591691 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 20 ]
Thu Dec 4 15:16:39 2014 us=687983 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=21 DATA len=100
Thu Dec 4 15:16:39 2014 us=688097 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 21 ]
Thu Dec 4 15:16:39 2014 us=782779 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=22 DATA len=100
Thu Dec 4 15:16:39 2014 us=782866 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 22 ]
Thu Dec 4 15:16:39 2014 us=877451 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=23 DATA len=100
Thu Dec 4 15:16:39 2014 us=877607 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=24 DATA len=100
Thu Dec 4 15:16:39 2014 us=877683 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 23 ]
Thu Dec 4 15:16:39 2014 us=877812 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 24 ]
Thu Dec 4 15:16:39 2014 us=971340 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=25 DATA len=100
Thu Dec 4 15:16:39 2014 us=971458 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 25 ]
Thu Dec 4 15:16:40 2014 us=65227 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=26 DATA len=100
Thu Dec 4 15:16:40 2014 us=65346 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 26 ]
Thu Dec 4 15:16:40 2014 us=160165 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=27 DATA len=100
Thu Dec 4 15:16:40 2014 us=161894 VERIFY OK: depth=1, C=MT, ST=MLT, L=Valletta, O=FreeVPN.me, OU=FreeVPN.me, CN=FreeVPN.me CA, name=FreeVPN.me, emailAddress=contact@freevpn.me
Thu Dec 4 15:16:40 2014 us=163344 VERIFY OK: depth=0, C=MT, ST=MLT, L=Valletta, O=FreeVPN.me, OU=FreeVPN.me, CN=FreeVPN.me, name=FreeVPN.me, emailAddress=contact@freevpn.me
Thu Dec 4 15:16:40 2014 us=163472 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=28 DATA len=100
Thu Dec 4 15:16:40 2014 us=163551 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 27 ]
Thu Dec 4 15:16:40 2014 us=163616 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 28 ]
Thu Dec 4 15:16:40 2014 us=253396 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=29 DATA len=100
Thu Dec 4 15:16:40 2014 us=253509 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 29 ]
Thu Dec 4 15:16:40 2014 us=347870 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=30 DATA len=100
Thu Dec 4 15:16:40 2014 us=347990 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 30 ]
Thu Dec 4 15:16:40 2014 us=441661 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=31 DATA len=100
Thu Dec 4 15:16:40 2014 us=441820 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=32 DATA len=100
Thu Dec 4 15:16:40 2014 us=441897 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 31 ]
Thu Dec 4 15:16:40 2014 us=441961 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 32 ]
Thu Dec 4 15:16:40 2014 us=537084 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=33 DATA len=100
Thu Dec 4 15:16:40 2014 us=537156 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 33 ]
Thu Dec 4 15:16:40 2014 us=631310 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=34 DATA len=100
Thu Dec 4 15:16:40 2014 us=631481 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 34 ]
Thu Dec 4 15:16:40 2014 us=724912 TCPv4_CLIENT READ [103] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=35 DATA len=89
Thu Dec 4 15:16:40 2014 us=779076 TCPv4_CLIENT WRITE [126] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ 35 ] pid=4 DATA len=100
Thu Dec 4 15:16:40 2014 us=779109 TCPv4_CLIENT WRITE [114] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=5 DATA len=100
Thu Dec 4 15:16:40 2014 us=779129 TCPv4_CLIENT WRITE [114] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=100
Thu Dec 4 15:16:40 2014 us=779149 TCPv4_CLIENT WRITE [40] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=7 DATA len=26
Thu Dec 4 15:16:40 2014 us=956873 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 4 ]
Thu Dec 4 15:16:41 2014 us=89394 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 5 ]
Thu Dec 4 15:16:41 2014 us=89581 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 6 ]
Thu Dec 4 15:16:41 2014 us=89642 TCPv4_CLIENT READ [126] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ 7 ] pid=36 DATA len=100
Thu Dec 4 15:16:41 2014 us=89717 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=37 DATA len=100
Thu Dec 4 15:16:41 2014 us=89954 TCPv4_CLIENT READ [48] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=38 DATA len=34
Thu Dec 4 15:16:41 2014 us=90276 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 36 ]
Thu Dec 4 15:16:41 2014 us=90385 TCPv4_CLIENT WRITE [130] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ 37 38 ] pid=8 DATA len=100
Thu Dec 4 15:16:41 2014 us=90433 TCPv4_CLIENT WRITE [114] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=9 DATA len=100
Thu Dec 4 15:16:41 2014 us=90505 TCPv4_CLIENT WRITE [114] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=10 DATA len=100
Thu Dec 4 15:16:41 2014 us=90548 TCPv4_CLIENT WRITE [92] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=11 DATA len=78
Thu Dec 4 15:16:41 2014 us=322864 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 8 ]
Thu Dec 4 15:16:41 2014 us=454411 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 9 ]
Thu Dec 4 15:16:41 2014 us=454575 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 10 ]
Thu Dec 4 15:16:41 2014 us=454623 TCPv4_CLIENT READ [126] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ 11 ] pid=39 DATA len=100
Thu Dec 4 15:16:41 2014 us=454730 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=40 DATA len=100
Thu Dec 4 15:16:41 2014 us=454778 TCPv4_CLIENT READ [96] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=41 DATA len=82
Thu Dec 4 15:16:41 2014 us=455128 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Dec 4 15:16:41 2014 us=455157 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Dec 4 15:16:41 2014 us=455180 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Thu Dec 4 15:16:41 2014 us=455254 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Dec 4 15:16:41 2014 us=455302 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 39 ]
Thu Dec 4 15:16:41 2014 us=455404 TCPv4_CLIENT WRITE [26] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 40 41 ]
Thu Dec 4 15:16:41 2014 us=455459 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Thu Dec 4 15:16:41 2014 us=455541 [FreeVPN.me] Peer Connection Initiated with [AF_INET]93.115.83.250:443
Thu Dec 4 15:16:43 2014 us=814138 SENT CONTROL [FreeVPN.me]: 'PUSH_REQUEST' (status=1)
Thu Dec 4 15:16:43 2014 us=814256 TCPv4_CLIENT WRITE [104] to [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=12 DATA len=90
Thu Dec 4 15:16:43 2014 us=911787 TCPv4_CLIENT READ [22] from [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 12 ]
Thu Dec 4 15:16:44 2014 us=51636 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=42 DATA len=100
Thu Dec 4 15:16:44 2014 us=51861 TCPv4_CLIENT READ [114] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=43 DATA len=100
Thu Dec 4 15:16:44 2014 us=51915 TCPv4_CLIENT READ [48] from [AF_INET]93.115.83.250:443: P_CONTROL_V1 kid=0 [ ] pid=44 DATA len=34
Thu Dec 4 15:16:44 2014 us=52032 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.13.0.1,topology net30,ping 15,ping-restart 120,ifconfig 10.13.0.94 10.13.0.93'
Thu Dec 4 15:16:44 2014 us=52202 OPTIONS IMPORT: timers and/or timeouts modified
Thu Dec 4 15:16:44 2014 us=52224 OPTIONS IMPORT: --ifconfig/up options modified
Thu Dec 4 15:16:44 2014 us=52242 OPTIONS IMPORT: route options modified
Thu Dec 4 15:16:44 2014 us=52258 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Dec 4 15:16:44 2014 us=52563 ROUTE_GATEWAY 192.168.2.1/255.255.255.0 IFACE=wlan0 HWADDR=00:24:01:ee:91:3d
Thu Dec 4 15:16:44 2014 us=53073 TUN/TAP device tun1 opened
Thu Dec 4 15:16:44 2014 us=53110 TUN/TAP TX queue length set to 100
Thu Dec 4 15:16:44 2014 us=53142 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Dec 4 15:16:44 2014 us=53207 /sbin/ip link set dev tun1 up mtu 1500
Thu Dec 4 15:16:44 2014 us=55739 /sbin/ip addr add dev tun1 local 10.13.0.94 peer 10.13.0.93
Thu Dec 4 15:16:44 2014 us=56888 TCPv4_CLIENT WRITE [22] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 42 ]
Thu Dec 4 15:16:44 2014 us=57018 TCPv4_CLIENT WRITE [26] to [AF_INET]93.115.83.250:443: P_ACK_V1 kid=0 [ 43 44 ]
Thu Dec 4 15:16:46 2014 us=237316 /sbin/ip route add 93.115.83.250/32 via 192.168.2.1
Thu Dec 4 15:16:46 2014 us=238627 /sbin/ip route add 0.0.0.0/1 via 10.13.0.93
Thu Dec 4 15:16:46 2014 us=240611 /sbin/ip route add 128.0.0.0/1 via 10.13.0.93
Thu Dec 4 15:16:46 2014 us=243113 /sbin/ip route add 10.13.0.1/32 via 10.13.0.93
Thu Dec 4 15:16:46 2014 us=245592 Initialization Sequence Completed
The vpn is now mounted:
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.13.0.94 P-t-P:10.13.0.93 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Here is the routing table when vpn is in place:
ubuntu@ubuntu:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.13.0.93 128.0.0.0 UG 0 0 0 tun1
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 wlan0
10.13.0.1 10.13.0.93 255.255.255.255 UGH 0 0 0 tun1
10.13.0.93 0.0.0.0 255.255.255.255 UH 0 0 0 tun1
93.115.83.250 192.168.2.1 255.255.255.255 UGH 0 0 0 wlan0
128.0.0.0 10.13.0.93 128.0.0.0 UG 0 0 0 tun1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
ubuntu@ubuntu:~$ ip route show
0.0.0.0/1 via 10.13.0.93 dev tun1
default via 192.168.2.1 dev wlan0
10.13.0.1 via 10.13.0.93 dev tun1
10.13.0.93 dev tun1 proto kernel scope link src 10.13.0.94
93.115.83.250 via 192.168.2.1 dev wlan0
128.0.0.0/1 via 10.13.0.93 dev tun1
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.79
I can ping the stack:
ubuntu@ubuntu:~$ ping 10.13.0.94
PING 10.13.0.94 (10.13.0.94) 56(84) bytes of data.
64 bytes from 10.13.0.94: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from 10.13.0.94: icmp_seq=2 ttl=64 time=0.054 ms
I can ping the vpn server:
ubuntu@ubuntu:~$ ping 10.13.0.1
PING 10.13.0.1 (10.13.0.1) 56(84) bytes of data.
64 bytes from 10.13.0.1: icmp_seq=1 ttl=64 time=96.1 ms
64 bytes from 10.13.0.1: icmp_seq=2 ttl=64 time=99.6 ms
I cannot ping the tunnel end host (which is normal):
ubuntu@ubuntu:~$ ping 10.13.0.93
PING 10.13.0.93 (10.13.0.93) 56(84) bytes of data.
From 10.13.0.1 icmp_seq=1 Destination Host Prohibited
From 10.13.0.1 icmp_seq=2 Destination Host Prohibited
I can ping any ip on internet through the tunnel:
ubuntu@ubuntu:~$ ping 212.27.40.240
PING 212.27.40.240 (212.27.40.240) 56(84) bytes of data.
64 bytes from 212.27.40.240: icmp_seq=1 ttl=49 time=138 ms
64 bytes from 212.27.40.240: icmp_seq=2 ttl=49 time=137 ms
64 bytes from 212.27.40.240: icmp_seq=3 ttl=49 time=137 ms
ubuntu@ubuntu:~$ ping 173.194.44.18
PING 173.194.44.18 (173.194.44.18) 56(84) bytes of data.
64 bytes from 173.194.44.18: icmp_seq=1 ttl=51 time=140 ms
64 bytes from 173.194.44.18: icmp_seq=2 ttl=51 time=1722 ms
64 bytes from 173.194.44.18: icmp_seq=3 ttl=51 time=809 ms
I can ping both dns provided by the vpn
ubuntu@ubuntu:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=130 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=130 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=133 ms
ubuntu@ubuntu:~$ ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=52 time=128 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=52 time=127 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=52 time=128 ms
I made a little dump to be sure the tunnel is used when pinging an ip over internet:
root@ubuntu:~# tcpdump -ni any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol dec ode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:18:12.091704 IP 10.13.0.94 > 212.27.40.240: ICMP echo request, id 6625, seq 1, length 64
11:18:12.227045 IP 212.27.40.240 > 10.13.0.94: ICMP echo reply, id 6625, seq 1, length 64
11:18:13.093187 IP 10.13.0.94 > 212.27.40.240: ICMP echo request, id 6625, seq 2, length 64
11:18:13.228153 IP 212.27.40.240 > 10.13.0.94: ICMP echo reply, id 6625, seq 2, length 64
11:18:14.094211 IP 10.13.0.94 > 212.27.40.240: ICMP echo request, id 6625, seq 3,
dump above shows there is no routing issue as well.
but I cannot resolve anything:
ubuntu@ubuntu:~$ nslookup www.google.com 8.8.8.8
;; connection timed out; no servers could be reached
ubuntu@ubuntu:~$ nslookup www.google.com 8.8.4.4
;; connection timed out; no servers could be reached
tcpdump shows that the dns requests are sent, but we never see any response back to our requests:
root@ubuntu:~# tcpdump -ni any port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
15:31:42.213105 IP 10.13.0.94.36335 > 8.8.8.8.53: 55836+ A? www.google.com. (32)
15:31:47.213243 IP 10.13.0.94.36335 > 8.8.8.8.53: 55836+ A? www.google.com. (32)
15:31:52.213427 IP 10.13.0.94.36335 > 8.8.8.8.53: 55836+ A? www.google.com. (32)
No filter is in place:
root@ubuntu:~# ufw status
Status: inactive
iptables not installed
I dont think it’s a routing problem, because ping to an internet ip or to the dns ips (of the vpn) gets back normally.
I checked syslog but did not find any vpn related logs.
I have tried another free vpn provider and have the exact same problem.
I have digged over and over again through google but could not find any accetable answer or lead. It starts becoming insame at this point, because I start doing the same tests over and over and dont know what to do.
the posts I have already read in stackoverflow:
No internet on OpenVPN connection -> the solution is to put ‘push «dhcp-option DNS 8.8.8.8» ‘ in the server conf. As for me, this option appears in the debug output when starting the client.
OpenVPN + iptables: not forwarding traffic -> it’s a server related issue + iptables rules.
(SOLVED) OpenVPN — Ubuntu network manager connection ok, but not resolving, not pinging, no internet -> this one looked very interesting, but dns issue was solved with dnsmasq command on the vps.
https://superuser.com/questions/717383/vpn-dns-resolution -> I think this is a server related issue.
OpenVPN server does not provide access to internet -> no solution provided, but I guess this is more an iptables (forwarding option) or server related issue.
I sent a mail to both vpn providers but no answer after more than 2 days.
any idea? thank you so much folks.
One of the VPNs I connect to sets the DNS server for the link. It is an OpenVPN with DNS option. The problem is that is doesn’t really work out of the box in Ubuntu (at least 18.04 and 18.10) — the VPN DNS is not consulted.
At the time of writing, I’m on 18.10, and I write it from that perspective. Ubuntu uses systemd-resolved service to provide a local DNS resolution. We need to “push” the VPN DNS address to this service. We can do it using jonathanio/update-systemd-resolved helper script.
systemd-resolved for DNS resolution #
Consult its readme for details, but the steps are these:
git clone https://github.com/jonathanio/update-systemd-resolved.git
cd update-systemd-resolved
sudo make # By default it installs the script to /etc/openvpn/scripts/update-systemd-resolved, so you need root permissions
Make sure the systemd-resolved is up and running (and autostarts).
systemctl enable systemd-resolved.service
systemctl start systemd-resolved.service
And that you have resolve somewhere in the hosts section of /etc/nssswitch.conf:
$ cat /etc/nsswitch.conf | grep hosts
hosts: files resolve mdns4_minimal [NOTFOUND=return] dns
Note This may not be needed as ubuntu moved to use /etc/resolv.conf and DNS stub directly; this may also result in a weird “bug” if your 18.10 is updated from a previous version. See the last section
Interlude: Why is this helper script needed? #
OpenVPN (at least on Ubuntu 18.10), comes with its own helper script /etc/openvpn/update-resolv-conf, but the problem is that the script relies on resolvconf service which is replaced with systemd-resolved. This is why we need the helper.
.ovpn client configuration #
Now that we have the helper script setup, we need to make the *.ovpn profiles us it. We can either edit the files directly and add the lines below to the *.ovpn:
script-security 2
up /etc/openvpn/scripts/update-systemd-resolved
down /etc/openvpn/scripts/update-systemd-resolved
down-pre
Or, if you don’t want to edit it, you can pass them to the openvpn call:
## Something like:
sudo openvpn --config ${NAME}.ovpn
--script-security 2
--up /etc/openvpn/scripts/update-systemd-resolved
--down /etc/openvpn/scripts/update-systemd-resolved
--down-pre
Troubleshooting #
You’ve followed all the steps, but the DNS is not being consulted.
Conflict between resolvconf and systemd-resolved #
This is common if your Ubuntu 18.10 is migrated from the older version, or if you’ve installed resolvconf package manually.
If the systemd-resolved.service log reports something along the lines of
Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying
You can check it like that:
$ systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-01-08 10:05:11 CET; 1 day 4h ago
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 1087 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 4915)
Memory: 6.5M
CGroup: /system.slice/systemd-resolved.service
└─1087 /lib/systemd/systemd-resolved
Jan 09 13:13:27 p51 systemd-resolved[1087]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying
Jan 09 13:13:55 p51 systemd-resolved[1087]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying
## (...)
It may indicate a conflict between resolvconf and systemd-resolvd. Make sure that resolv.conf points to the systemd version:
$ ll /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Jan 9 13:40 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
If there is some other target of the symlink, then:
cd /etc
sudo rm resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf
Will do the trick.
See this ask ubuntu post which put me on the right track.
>> Home
OpeVPN is a great tool to implement secure point to point connections.
But, often a single wrong step during the setup can break the connection and result in errors.
One such error in OpenVPN is “cannot resolve host address“.
At Bobcares, we help users resolve OpenVPN connection errors as part of our Managed VPN services.
Today, we’ll discuss the top 4 reasons for the error cannot resolve host address in OpenVPN and how we fix them.
Cannot resolve host address in OpenVPN – What this means?
Customers usually face this error when trying to make an OpenVPN connection. This error means that the DNS servers refused to resolve the hostname. Here, our Support Engineers check the server logs and detailed error looks like this:
2019-01-21 20:19:01 MANAGEMENT: >STATE:1489260308,RESOLVE,,, 2019-01-21 20:19:01 RESOLVE: Cannot resolve host address: vpn.xx.xx.xx.xx.com: nodename nor servname provided, or not known
Cannot resolve host address in OpenVPN – Causes & Fixes
Now, let’s see the main reasons for this error and how our Dedicated Engineers fix them.
1) Firewall restrictions
One of the common reasons for this error is customer’s local firewall blocking the connection to the OpenVPN server. Additionally, firewall rules can block the DNS connections on the system. Similarly, the Antivirus program installed on the customer’s system can also hamper the VPN functionality.
So, in such cases our Support Experts temporary disable the security applications and the Antivirus program one by one. Thus, we can determine which application is blocking the connections and fix it’s settings.
Moreover, we ensure to allow the following in firewall.
- Loop backup interface or hostname itself.
- Interface created by OpenVPN.
- UDP packets on port 53 for DNS queries.
In addition to that, we ensure that the ports required for the OpenVPN to communicate are included in the router settings.
2) Incorrect hostname
Similarly, a typo in the hostname or an inactive host specified in the OpenVPN settings can lead to this error.
Firstly, our Support Experts confirm whether the host is active using the ping command.
ping vpn.xx.xx.xx.xx.comIn addition to that, we check the DNS connectivity of the hostname using dig and nslookup commands.
dig vpn.xx.xx.xx.xx.com
nslookup vpn.xx.xx.xx.xx.comIn this way, we confirm that whether the customer uses a valid and correct hostname.
If we find any problems with the hostname, we’ll contact the customer and update them to use the correct hostname. Alternatively, we update the customer to use the explicit IP address instead of the domain name.
3) DNS servers
If that doesn’t work, this error can be caused by the DNS settings.
Sometimes, DNS servers doesn’t resolve the server name translating it to the IP address. This can be due to DNS spoofing in some countries that censor websites. In other words, the DNS servers in these countries refuse to resolve the hostname or provide the wrong IP address leading to a dead link.
Our Support Experts easily fix this by helping the customer to switch the DNS servers on their computer to the ones outside the country. There are many free DNS servers available such as Google, OpenDNS, etc.
Google DNS : 8.8.8.8 and 8.8.4.4
OpenDNS server : 208.67.222.222 and 208.67.220.220
For example on a Mac system, we modify the DNS servers from System Preferences > Network > Select the connections through which you connect > Advanced > DNS > DNS servers > Update the new DNS servers > OK > Apply.
Most importantly, we update the customers to change the network adapter settings as well.
4) OpenVPN client configuration
Similarly, this error can also be caused by misconfigured OpenVPN client configuration. A sample OpenVPN configuration looks like this.
client
dev tun
proto tcp
remote vpn.xx.xx.xx.xx.com 1194
resolv-retry infinite
remote-cert-tls server
nobind
persist-key
persist-tun
verb 3
pkcs12 D:\{cert}.p12
A single wrong entry in this file can affect the working of the VPN service. In such cases, our Server Experts get the OpenVPN client configuration and correct the wrong entries to fix the issue. Sometimes, we need to switch the protocol from TCP to UDP in the configuration to fix the issue.
4) Incorrect host file entry
Also, incorrect entries in the /etc/hosts file of your system may result in this error. Ideally, the localhost entry should be in the /etc/hosts file of your system, so that localhost name can be resolved. Missing localhost entry or typo mistakes in this file will create problems.
Here, our Support Engineers get the /etc/hosts entry details from the customers and make sure that the first entry is given as below.
127.0.0.1 localhost[And do you need a server expert to resolve your OpenVPN errors. Our Experienced System Experts can help you here.]
Conclusion
In short, “cannot resolve host address” error in OpenVPN can occur due to firewall restrictions, OpenVPN client configuration errors, and so on. Today, we’ve discussed the top 4 reasons for this error and how our Support Engineers fix them.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
How to fix DNS issues when using OpenVPN.
Sometimes you successfully connect to vpn server but nothing still seems to work. Well, one of the reasons could be the DNS.
Firstly, you should check your vpn logs, that would be for instance,
for MacOS:
/Library/Application Support/Tunnelblick/Logs
or Linux in:
journalctl -u NetworkManager.service on linux
2019-06-11 23:30:25.110048 MANAGEMENT: >STATE:1560292225,GET_CONFIG,,,,,, 2019-06-11 23:30:25.110251 SENT CONTROL [openvpn.example.com]: 'PUSH_REQUEST' (status=1) 2019-06-11 23:30:25.252005 PUSH: Received control message: 'PUSH_REPLY,route .... dhcp-option DOMAIN dev.example.com,dhcp-option DOMAIN prod.example.com,dhcp-option DOMAIN int.example.com' ... .... 2019-06-11 23:30:25.252374 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:13: dhcp-option (2.4.7)
In the example above, openvpn client complaints about not recognising dhcp-options, because server pushes multiple ‘dhcp-option DOMAIN value’ config params whereas
client expects a single command with multiple values: ‘dhcp-option DOMAIN value1 value2’.
This normally happens when your client version doesn’t match with your server version, so you client doesn’t know what to do with them.
As a result you may not get correct settings in your ‘/etc/resolv.conf’, for example missing or incomplete ‘nameserver’ or ‘search’.
In this example we won’t get ‘search’ set up correctly meaning if there was a DNS record like something.int.example.com, we wouldn’t be able
to refer to it without FQDN like just ‘something’, that is what ‘search’ parameter does in ‘/etc/resolv.conf’.
If ‘nameserver’ was not configured then our DNS won’t work at all.
But there is a solution.
In this example, we can configure our client to ignore specific configs from server and instead configure it on the client side as below:
pull-filter ignore "dhcp-option DOMAIN" dhcp-option DOMAIN "dev.example.com prod.example.com int.example.com"
If it doesn’t work for some reason, or your client doesn’t support them at all, you can always run a custom script that adds those parameters to your resolve.conf, or whatever your system
uses, important thing is to know what server trying to set up, and just set them by yourself:
[[ "$vpn_connection" == "mywork_vpn" ]] && echo "setting-up-dns manually..." && sudo bash -c 'echo -e "search dev.example.com prod.example.com int.example.comnnameserver 172.16.0.03" > /etc/resolv.conf'
It is not probably best idea todo so, but in worst case it may still help, this file will be overriten by other tools like wifi connection or other vpn connection or you
can just store old version and write it after disconnecting from your mywork_vpn.
https://community.openvpn.net/openvpn/ticket/809
http://man7.org/linux/man-pages/man5/resolv.conf.5.html
I have a VPN set up on some virtual machines using OpenVPN. One of the VMs is running dnsmasq to provide a basic DNS for inside the network. My client is running Ubuntu, which now more or less forces systemd-resolved. I am finding that although it claims to have configured DNS, I can’t actually do an nslookup or dig on hostnames inside the VPN. I can ping them by IP, but not by name.
Let’s dive into configuration files.
OpenVPN server conf:
mode server
local 192.168.50.101
port 1194
proto udp
dev tun
ca /etc/openvpn/server/ssl/ca.pem
cert /etc/openvpn/server/ssl/cert.pem
key /etc/openvpn/server/ssl/key.pem
dh /etc/openvpn/server/ssl/dh2048.pem
topology subnet
server 10.99.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.10.0.0 255.255.255.0"
push "dhcp-option DNS 10.99.0.1"
keepalive 10 120
cipher AES-128-CBC # AES
comp-lzo
push "comp-lzo yes"
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 6
mute 20
Client conf:
client
dev tun
proto udp
remote 192.168.50.101 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca REDACTED
cert REDACTED
key REDACTED
remote-cert-tls server
cipher AES-128-CBC
comp-lzo
verb 3
mute 20
ping-restart 30
script-security 2
setenv PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
down-pre
I have installed https://github.com/jonathanio/update-systemd-resolved, as seems to be recommended. It does, in fact, update the DNS settings as can be shown by the systemd-resolved logs (Switching to DNS server 10.99.0.1 for interface tun0.) and --status output:
Link 26 (tun0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 10.99.0.1
/etc/resolve.conf points to 127.0.0.53, as is the default for using systemd-resolved.
I’ve tried using NetworkManager’s built-in OpenVPN connection, and it neither fixes the DNS issue, nor even sets up routes correctly (so I can’t even ping or connect by IP).
Just a few other things that people will probably ask about:
- This setup works for my coworkers on Macs, using Viscosity. It’s only Ubuntu/Linux that’s failing here on the client side.
- Firewall on OpenVPN server allows port 53 and I can verify with telnet.
- If I set up
/etc/resolv.confto point to my VPN’s DNS server (on 10.99.0.1), then DNS resolution works fine. However, resolv.conf is managed by either systemd-resolved or NetworkManager via resolvconf and I’d like to keep those if possible so as not to upset the Ubuntu apple cart.