Sat Jul 9 13:14:21 2011 WARNING: potential route subnet conflict between local LAN [192.168.80.0/255.255.255.0] and remote VPN [192.168.80.1/255.255.255.255]
Your vpn subnet must be different than your LAN subnet.
# shared.key: [???]
The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS.
# client1.csr: [???]
Certificate signing request. Basically this is a cert that has not been signed by the CA yet. In the most secure setups key signing would work like this: user generates a key and a csr, user sends csr to the CA, CA signs the csr and sends back a crt, then the user has his private key and crt, but nobody else ever had access to his private key.
I think your problem is related the the first error above, you need to use a different subnet for LAN than VPN. also, it looks like you're connecting to a local machine (192.168.1.1) which means you need to use the local flag to --redirect-gateway
heres what the manual says about redirect-gateway, look at the local flag:
Code: Select all
--redirect-gateway flags...
(Experimental) Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN.
This option performs three steps:
(1) Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.
(2) Delete the default gateway route.
(3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).
When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.
Option flags:
local -- Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.
def1 -- Use this flag to override the 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.
bypass-dhcp -- Add a direct route to the DHCP server (if it is non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).
bypass-dns -- Add a direct route to the DNS server(s) (if they are non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).
Using the def1 flag is highly recommended.