Hi,
Something odd is happening with a vpn of mine. here are the running versions:
server: Debian Wheezy 64 bit, OpenVPN 2.2.1, installed from debian stable repository.
client: Windows 8.1 Pro Enterprise, OpenVPN 2.3.5, installed from install-kit @openvpn.net website
Server has 1 public IP adress (IPv4) so clients do a NAT on internal subnet, 10.8.0.1/24
I use redirect-gateway def1 bypass-dhcp and it works fine, the client can access the internet via the VPN server.
I also use a localhost unbound instance on the VPN server, for DNS resolving, which listens on IP 10.8.0.1 (vpn server IP) and the client is able to resolve DNS just fine via the VPN server, with no DNS leaks on client side. Checked it via multiple ways and it's ok.
This happens while connected to the internet and obviously to the VPN via a Wireless base connection (the initial network connection, where the client-server VPN tunnel is built into).
When I am on wired network connection, the same client-server analogy, the same config files and versions, the leak tests detect my non-VPN IP address using RTCPeerConnection.
While when connected to the VPN server via a wireless network connection it says RTCPeerConnection not available, when on wired network connection RTCPeerConnection is available and the initial non-VPN IP address along with its DNS servers is disclosed.
P.S. Tests were done in Mozilla Firefox and Google Chrome latest versions.
Why would things happen different when on Wired network connection as opposite to wireless (wi-fi)?
Proper gateway redirect leaks real IP on wired network
Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech
-
s7r
- OpenVpn Newbie
- Posts: 11
- Joined: Mon Feb 07, 2011 1:38 pm
-
s7r
- OpenVpn Newbie
- Posts: 11
- Joined: Mon Feb 07, 2011 1:38 pm
Re: Proper gateway redirect leaks real IP on wired network
FIXED.
In short, it's not an OpenVPN related problem. Will explain more in detail.
The problem is comprised of 2 things:
1.WebRTC IP leaks.
WebRTC is a HTML5 element compatible with the majority of web browsers, implementing Real-time Transport Protocols peer-to-peer in order to transmit live streaming (audio/video).
WebRTC or RTP/SRTP protocols work by transmitting data over UDP with DTLS (TLS for UDP transport protocol). WebRTC tries to create a peer-to-peer connection between users. Since the world of IP connectivity is a mess, in many cases users(peers) are on different network and separated by NAT (Network Address Translation). In these cases, the clients (peers) public and internal (NAT) IP addresses should be bound.
The IP addresses of the relay servers needed to connect 2 clients behind NAT are known as NAT traversal. WebRTC achieves this using 3 protocos:
STUN (Session Traversal Utilities for NAT)
TURN (Traversal Using Relays around NAT)
ICE (Interactive Connectivity Establishment).
These 3 protocols work together to gather IP addresses (traceroute) and ports that allow NAT traversal.
The collected data collected by these protocols is transmitted to the browser / server running the WebRTC service - this way one client / peer knows how to peer-to-peer connect to the other client / peer. It's a combination between peer-to-peer and client-to-server models. A close analogy would be Bittorrent trakcers - they do not serve the data themselves, but they offer the required information so peers can connect to other peers.
So, in order for your connectivity information to be available to the peer you are trying to connect to (or the peer which tries to connect to you) you have to trust the developer of the WebRTC service, which is the messenger between you and your peer, transmitting this data.
How to disable it?
Firefox: type about:config and scroll to media.peerconnection.enabled and set it to false.
Google chrome: no setting to disable it at the time I write this, but probably the newer versions will make it possible.
2. DNS Server leaks. This is a Windows related problem. As opposite to Linux, Windows does not know a certain set of DNS resolvers, instead each network interface has its own DNS resovlers.
For example, the wired default connection (my ISP connection) is labeled Ethernet and has the ISP DNS servers assigned via DHCP.
My OpenVPN connection (tun adapter) is labeled OpenVPN and has the DNS server set to 10.8.0.1 (a local instance of unbound DNS resolver running on the VPN server and listening on the VPN IP 10.8.0.1). My VPN client IP is 10.8.0.4
Everything works fine, the default gateway and the routing table is properly modified and traffic to any destination goes through the VPN. This is expected.
DNS is also resolved at VPN end, so there are no leaks.
Except, when you are served a DNS record which does not exist (or the VPN DNS resolver can't resolve), instead of getting a failure, Windows fails back and tries all the DNS resolvers it knows, like the ones from other network interfaces, herein the DNS resolvers from Ethernet, which are my ISPs DNS resolvers.
How to fix?
Well, technically Windows offers no fix for this. What I have done is I have went to Ethernet (my wired network connection), right-click and went to Properties, Internet Protocol Version 4 (TCP/IPv4) and clicked on Properties again. Pay attention not to uncheck it.
I left the IP address to obtain automatically (DHCP), and in the lower field, at Obtain DNS Servers automatically I have unchecked that option, enabled the second one and manually added the fist and only DNS resolver to 10.8.0.1 (VPN server IP and DNS resolver).
Now there are no leaks, since the only DNS resolver known to the Windows system is the VPN one. This means that when you are connected to the internet but not connected to the VPN, you will not be able to resolve DNS hostnames until you connect to the VPN or change the DNS servers of Ethernet (the wired network connection) back to Obtain automatically (DHCP).
This applies to Wireless connections also, follow the same steps except don't go for the connection labeled Ethernet, go to your wireless connection instead.
In short, it's not an OpenVPN related problem. Will explain more in detail.
The problem is comprised of 2 things:
1.WebRTC IP leaks.
WebRTC is a HTML5 element compatible with the majority of web browsers, implementing Real-time Transport Protocols peer-to-peer in order to transmit live streaming (audio/video).
WebRTC or RTP/SRTP protocols work by transmitting data over UDP with DTLS (TLS for UDP transport protocol). WebRTC tries to create a peer-to-peer connection between users. Since the world of IP connectivity is a mess, in many cases users(peers) are on different network and separated by NAT (Network Address Translation). In these cases, the clients (peers) public and internal (NAT) IP addresses should be bound.
The IP addresses of the relay servers needed to connect 2 clients behind NAT are known as NAT traversal. WebRTC achieves this using 3 protocos:
STUN (Session Traversal Utilities for NAT)
TURN (Traversal Using Relays around NAT)
ICE (Interactive Connectivity Establishment).
These 3 protocols work together to gather IP addresses (traceroute) and ports that allow NAT traversal.
The collected data collected by these protocols is transmitted to the browser / server running the WebRTC service - this way one client / peer knows how to peer-to-peer connect to the other client / peer. It's a combination between peer-to-peer and client-to-server models. A close analogy would be Bittorrent trakcers - they do not serve the data themselves, but they offer the required information so peers can connect to other peers.
So, in order for your connectivity information to be available to the peer you are trying to connect to (or the peer which tries to connect to you) you have to trust the developer of the WebRTC service, which is the messenger between you and your peer, transmitting this data.
How to disable it?
Firefox: type about:config and scroll to media.peerconnection.enabled and set it to false.
Google chrome: no setting to disable it at the time I write this, but probably the newer versions will make it possible.
2. DNS Server leaks. This is a Windows related problem. As opposite to Linux, Windows does not know a certain set of DNS resolvers, instead each network interface has its own DNS resovlers.
For example, the wired default connection (my ISP connection) is labeled Ethernet and has the ISP DNS servers assigned via DHCP.
My OpenVPN connection (tun adapter) is labeled OpenVPN and has the DNS server set to 10.8.0.1 (a local instance of unbound DNS resolver running on the VPN server and listening on the VPN IP 10.8.0.1). My VPN client IP is 10.8.0.4
Everything works fine, the default gateway and the routing table is properly modified and traffic to any destination goes through the VPN. This is expected.
DNS is also resolved at VPN end, so there are no leaks.
Except, when you are served a DNS record which does not exist (or the VPN DNS resolver can't resolve), instead of getting a failure, Windows fails back and tries all the DNS resolvers it knows, like the ones from other network interfaces, herein the DNS resolvers from Ethernet, which are my ISPs DNS resolvers.
How to fix?
Well, technically Windows offers no fix for this. What I have done is I have went to Ethernet (my wired network connection), right-click and went to Properties, Internet Protocol Version 4 (TCP/IPv4) and clicked on Properties again. Pay attention not to uncheck it.
I left the IP address to obtain automatically (DHCP), and in the lower field, at Obtain DNS Servers automatically I have unchecked that option, enabled the second one and manually added the fist and only DNS resolver to 10.8.0.1 (VPN server IP and DNS resolver).
Now there are no leaks, since the only DNS resolver known to the Windows system is the VPN one. This means that when you are connected to the internet but not connected to the VPN, you will not be able to resolve DNS hostnames until you connect to the VPN or change the DNS servers of Ethernet (the wired network connection) back to Obtain automatically (DHCP).
This applies to Wireless connections also, follow the same steps except don't go for the connection labeled Ethernet, go to your wireless connection instead.