Openvpn connection

L

locutus24

[H]ard|Gawd
Joined
Sep 13, 2004
Messages
1,642
Was using Tcpview for watching my traffic and weeding out possible bad connections, but while I was downloading a large file I noticed something unusual. Firefox was receiving/sending more then my Openvpn connection, which led to my realizing that the TAP-Win32 connection for my VPN runs slower then my actual internet.

Cliffs:
1) Why is Firefox sending/receiving more than my VPN connection?
2) Is it bad that my OpenVPN is 10MB/s whereas my DSL is 12MB/s?
 
i-2ZMpK8P.jpg


Not sure what else will help, this screen shot shows that they both have been connected for within 1sec of the same time. But noticing data flow, there is a disparity. IP Geo websites properly show my IP for my VPN, but I still am wondering if all my data is actually being encapsulated.
 
Would this then mean that some of my web traffic is sent in the clear. Damn!

Thank you
 
Yes. Split tunneling. The stuff destined to the resources at the other end, say your "work" network goes through the tunnel. The stuff, say "youtube" is not going though the tunnel.
 
sc0tty8 said:
Yes. Split tunneling. The stuff destined to the resources at the other end, say your "work" network goes through the tunnel. The stuff, say "youtube" is not going though the tunnel.
Click to expand...

Would quote them except I didn't save the chat log, but my VPN provider said by default all traffic was routed through their connection.

I am going to have to Wireshark these shenanigans and see if any traffic comes up in the clear, particularly my Norp downloads
 
Compression?

Edit: nvm, makes no sense.

Check that you have 0/1 and 128/1 routes so all traffic goes via OpenVPN.
 
TCM said:
Compression?

Edit: nvm, makes no sense.

Check that you have 0/1 and 128/1 routes so all traffic goes via OpenVPN.
Click to expand...

Current Config:

remote *.*.*.*
proto udp
ca ca.crt
cert ovpn.crt
key ovpn.key
tls-auth ta.key 1
cipher AES-128-CBC
client
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
verb 4
mute 5
tun-mtu 1500
route-method exe
route-delay 2
comp-lzo adaptive
explicit-exit-notify 2
fragment 1390
mssfix 1390

I need my youtube encrypted
 
locutus24 said:
Current Config:

remote *.*.*.*
proto udp
ca ca.crt
cert ovpn.crt
key ovpn.key
tls-auth ta.key 1
cipher AES-128-CBC
client
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
verb 4
mute 5
tun-mtu 1500
route-method exe
route-delay 2
comp-lzo adaptive
explicit-exit-notify 2
fragment 1390
mssfix 1390

I need my youtube encrypted
Click to expand...

You need your "youtube" encrypted?
 
http://openvpn.net/index.php/open-source/documentation/howto.html#redirect
Routing all client traffic (including web-traffic) through the VPN
Overview

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN.

In certain cases this behavior might not be desirable -- you might want a VPN client to tunnel all network traffic through the VPN, including general internet web browsing. While this type of VPN configuration will exact a performance penalty on the client, it gives the VPN administrator more control over security policies when a client is simultaneously connected to both the public internet and the VPN at the same time.
Implementation

Add the following directive to the server configuration file:

push "redirect-gateway def1"

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

push "redirect-gateway local def1"

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.

On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.

When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:

push "dhcp-option DNS 10.8.0.1"

will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.
Caveats

Redirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:

Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease.
Issues exist with respect to pushing DNS addresses to Windows clients.
Web browsing performance on the client will be noticably slower.

For more information on the mechanics of the redirect-gateway directive, see the manual page.
 
You must log in or register to reply here.
Back
Top