lmonti Since I wish to reach my home network from work, I installed OpenVPN on a Raspberry Pi in my home LAN, behind a router. Installed OpenVPN client on a PC @ work and, after some hours of tests, everything is running through the corporate HTTP proxy! To be sure that everything was running fine, I checked the traffic generated by the PC running OpneVPN client and with surprise I can see that the DNS queries are generated against the corporate DNS server! The address of the PC in the corporate network is: 170.110.10.15\255.255.255.0\170.110.10.2 and the DNS is 170.110.13.135 from the OpenVPN server i push to the client the Google DNS 8.8.8.8 When I open the browser and point to http://www.something.com, the wireshark is telling me that the first query of "something" is performed on the 170.110.13.135 then the web traffic goes correctly to the VPN interface. Why this behaviour? this is the config dev tun #proto udp proto tcp port 8297 ca /etc/openvpn/easy-rsa/keys/ca.crt cert /etc/openvpn/easy-rsa/keys/server.crt key /etc/openvpn/easy-rsa/keys/server.key dh /etc/openvpn/easy-rsa/keys/dh2048.pem server 10.8.0.0 255.255.255.0 # server and remote endpoints ifconfig 10.8.0.1 10.8.0.2 # Add route to Client routing table for the OpenVPN Server push "route 10.8.0.1 255.255.255.255" # Add route to Client routing table for the OPenVPN Subnet push "route 10.8.0.0 255.255.255.0" # your local subnet push "route 192.168.1.0 255.255.255.0" # Set your primary domain name server address for clients push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" # Override the Client default gateway by using 0.0.0.0/1 and # 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of # overriding but not wiping out the original default gateway. push "redirect-gateway def1" client-to-client duplicate-cn keepalive 10 120 tls-version-min 1.2 tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 cipher AES-256-CBC auth SHA256 comp-lzo user nobody group nogroup persist-key persist-tun #crl-verify /etc/openvpn/crl.pem status /var/log/openvpn-status.log 20 log /var/log/openvpn.log verb 1 # This configuration file was originally written by Lauren Orsini at ReadWrite.
lmonti Sorry for my fault in the first post. I worked some more time on this issue... First af all, if i flush the DNS cache of my Windows client PC, then Windows does not ask anymore to my corporate DNS for resolve the DNS queries, but I am facing a new problem. Wireshark is running on a PC and logs everything generated by the machine where OpenVPN client is running. Why Wireshark sniff DNS query of something.com against the Google DNS 8.8.8.8 ? Now the query is correct... 8.8.8.8 is the right one, but this query should be tunneled. Of course 8.8.8.8 does not provide any answer. Let me say that I am expecting not the able to see any activities in clear... but everything encrypted... Maybe I am not understanding in the correct way the behaviour of this setup... I appreciate your help.
TinCanTech lmonti wroteWhy Wireshark sniff DNS query of something.com against the Google DNS 8.8.8.8 ? Now the query is correct... 8.8.8.8 is the right one, but this query should be tunneled.Openvpn Log files please.
lmonti here is the openvpn log file. Mon Nov 14 15:58:40 2016 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016 Mon Nov 14 15:58:40 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08 Mon Nov 14 15:58:40 2016 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet. Mon Nov 14 15:58:40 2016 Control Channel Authentication: using '/etc/openvpn/easy-rsa/keys/ta.key' as a OpenVPN static key file Mon Nov 14 15:58:40 2016 TUN/TAP device tun0 opened Mon Nov 14 15:58:40 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Nov 14 15:58:40 2016 /sbin/ip link set dev tun0 up mtu 1500 Mon Nov 14 15:58:40 2016 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2 Mon Nov 14 15:58:40 2016 GID set to nogroup Mon Nov 14 15:58:40 2016 UID set to nobody Mon Nov 14 15:58:40 2016 Listening for incoming TCP connection on [undef] Mon Nov 14 15:58:40 2016 TCPv4_SERVER link local (bound): [undef] Mon Nov 14 15:58:40 2016 TCPv4_SERVER link remote: [undef] Mon Nov 14 15:58:40 2016 Initialization Sequence Completed Mon Nov 14 15:58:45 2016 TCP connection established with [AF_INET]131.22.22.11:47118 Mon Nov 14 15:58:48 2016 131.22.22.11:47118 [muletto] Peer Connection Initiated with [AF_INET]131.22.22.11:47118 Mon Nov 14 15:58:48 2016 muletto/131.22.22.11:47118 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled) Mon Nov 14 15:58:51 2016 muletto/131.22.22.11:47118 send_push_reply(): safe_cap=940 Mon Nov 14 15:58:54 2016 muletto/131.22.22.11:47118 Connection reset, restarting [0] Mon Nov 14 15:59:00 2016 TCP connection established with [AF_INET]131.22.22.11:48843 Mon Nov 14 15:59:04 2016 131.22.22.11:48843 [muletto] Peer Connection Initiated with [AF_INET]131.22.22.11:48843 Mon Nov 14 15:59:04 2016 muletto/131.22.22.11:48843 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled) Mon Nov 14 15:59:06 2016 muletto/131.22.22.11:48843 send_push_reply(): safe_cap=940 Mon Nov 14 16:16:28 2016 muletto/131.22.22.11:48843 Connection reset, restarting [0] Mon Nov 14 16:18:20 2016 TCP connection established with [AF_INET]131.22.22.10:55809 Mon Nov 14 16:18:24 2016 151.88.22.10:55809 [muletto] Peer Connection Initiated with [AF_INET]131.22.22.10:55809 Mon Nov 14 16:18:24 2016 muletto/131.22.22.10:55809 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled) Mon Nov 14 16:18:26 2016 muletto/131.22.22.10:55809 send_push_reply(): safe_cap=940 Mon Nov 14 16:24:30 2016 muletto/131.22.22.10:55809 Connection reset, restarting [0]
lmonti adding some more infos: The OpenVPN client PC (windows) has a phisical network interface and, as soon OpenVPN connects, a secondary virtual interface. I am pushing Google DNS from OpenVPN server to the client Every DNS queries running on the client (when connected) is performed at first to the Google DNS (correct) but originated from the phisical interface (not correct) and obviosuly they fail. There is not response at all to these queries... of course since the client PC is in our corporate LAN and there is no way to go to the internet but through the http proxy.
