Another VPN Question (this time for OpenVPN)

From: David White 
------------------------------------------------------
In addition to this WatchGuard project I'm working on for a client, I've
finally decided to setup my own VPN server on one of my own servers so that
I can use it for personal stuff for when I'm traveling and need some sort
of secure connection if I'm on public Wifi.

I've installed OpenVPN onto a CentOS 6 box and am able to connect to the
VPN fine. Obviously, I want to route 100% of my traffic through the VPN for
security reasons, so I'm doing that.

Up until recently, I could ping the VPN server's IP address of 10.8.0.1.
However, I'm unable to ping / resolve anything outside of the VPN (i.e.
can't get to the outside world). I *can* resolve addresses, though.

(And recently, I've mad a change - I can't figure out what it was - that
broke the ability to resolve anything).

Everything I've read indicates that this is a routing issue between the VPN
server and the public IP address interface on the server (eth0).

Per things I've read, I've tried adding the following to IP Tables:
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -S 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Here's the relevant information in the *server's* OpenVPN config file:
[root@elmer openvpn]# grep -v "#" server.conf | sed -e 's/^\s*//' -e '/^$/d'
port 1194
proto tcp
dev tun
ca ca.crt
cert server.crt
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
client-to-client
keepalive 10 120
comp-lzo
max-clients 10
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log-append  openvpn.log
verb 6

Does anyone know what I'm missing / doing wrong?

-- 
David White
Founder & CEO
*
*
*CENTS *
Computing, Equipping, Networking, Training & Supporting
Nonprofit Organizations Worldwide
http://developCENTS.com 
423-693-4234

=============================================================== From: "kitepilot@kitepilot.com" ------------------------------------------------------ Hello David, please provide the output of (both, the server and your box): ip addr show ip route show ET David White writes:

=============================================================== From: Mike Harrison ------------------------------------------------------ If you are doing this with pfSense, the VPN address range should be different than the local one, and must be allowed specifically out through the firewall. Your VPN is working... your firewall is probably not allowing it to see the outside world. Your DNS resolution my be masked or your firewall allows UDP DNS but not other connections.

=============================================================== From: David White ------------------------------------------------------ I'm doing this with straight OpenVPN (via the EPEL repository and CentOS) as the server, and a Windows 7 machine as the client. Regardless, the local IP address range is typically a 192.168.x range (and the VPN range is obviously a 10.8.0.x range). Here's my ipconfig /all from the Windows Box (for the VPN adapter): Ethernet adapter MyTap: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-3D-C6-25-13 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::94d0:3aa:50b7:1e6c%17(Preferred) IPv4 Address. . . . . . . . . . . : 10.8.0.6(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.252 Lease Obtained. . . . . . . . . . : Wednesday, July 10, 2013 2:56:11 PM Lease Expires . . . . . . . . . . : Thursday, July 10, 2014 2:56:10 PM Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 10.8.0.5 DHCPv6 IAID . . . . . . . . . . . : 268500797 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-36-D0-79-48-5D-60-3B-CF-5B DNS Servers . . . . . . . . . . . : 208.67.222.222 208.67.220.220 NetBIOS over Tcpip. . . . . . . . : Enabled And here's the output on the server of ip addr show and ip route show: *[root@elmer ~]# ip addr show* 1: lo:

=============================================================== From: kitepilot@kitepilot.com ------------------------------------------------------ I am trying to understand this problem because I've been running OpenVPN for years and I have been able to connect to, and work with, from Chile, Venezuela, Mexico, some Caribbean islands, all over the lower 48 and Alaska. No firewall rules or anything fancy, pretty much plug-and-play. Yeah, that easy... Wondering why you are having so many problems... ET David White writes:

=============================================================== From: David White ------------------------------------------------------ Looking at the output of the client machine's ipconfig /all, we can see that it thinks the DHCP server is 10.8.0.5. That's wrong, as the VPN server should be 10.8.0.1. That's weird.

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My OpenVPN server hands out PtP links, and has a unique IP address on the server side for each connection. ie, Server has 10.8.0.5, Client will have 10.8.0.6. Next client will have 10.8.0.8, talking to server at 10.8.0.7. Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3cB1AAoJEMP+wtEOVbcdUcgIAK8tp1We0lhWcP/OjTuY0Mff IBNJaGd61qlwVoOwsx0R5ifBQzh26N65upJpbtg6m8wKbNO3NZDef+eQuazetE5K tpvtHDKl8BGT+HLJnexi5YRrOuxJnWNq0JprJ2zdHBsVdksJjsTue++MatAs/jNg kX4+BPMqhOQ0mZABz+zoW6OZS0YSltonoopkgtn9U++/WDoe5Xls3hRzHBI47q5M khBivtqC/Yw4z5CgK7VWImZ2fzPM24aQP5D3x+kbcsOI4CwJOkpYgmOqjKouHgiP hp3pQGlyeACU4LBFVjLFXlH/UvpxGTrI13Ap/DrQjYLLT291bHP8nTNCngopD0E= =NlN+ -----END PGP SIGNATURE-----

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Confirming after looking at a connected client. Client receives a /30 as mentioned above. I do not push default route, I push a specific route, which shows up in the routing table on the client, with the client side IP as the on-link gateway. From the client, I cannot ping the DHCP Server address, but I can ping the configured IP address on the server itself (.1 as in your case). I'm using pfsense for my OpenVPN server, so I don't a straight Linux server config to look at presently. Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3dF/AAoJEMP+wtEOVbcdRf4H/3eg/Bx6GvEVIQsL60zEn7vw IMpVxC3th+czZwEKbjjLgFqDuTNgoUB2gf+fJrfKZVqHERepmLYoohD+cB1axG2Y EadoAZaWKeQIvU6bpxQUh/splyMMXw1nr/Hs9qpAwX0YdciB5LC9mxNTp5QqqoEF 2TN154K+yU/1S7iycApG6D89/7wymLYC/62j/0VmariV99sEVQ/lvzMyksKSIVu2 VRH3lB1YUfPxaA/aZunqZlZbcX8FIry6yMdnTeYh8DKOBkd0LdA5a97guFcwt9mE J/IwAoeh9e/SM93ef0XmqDfIIj9ggQNnoOd4ZNljv3vIIM5tiLPrrmef5GXIuAc= =JvOC -----END PGP SIGNATURE-----

=============================================================== From: kitepilot@kitepilot.com ------------------------------------------------------ Why don't you shutdown pfsense until you sort out the routing problem? ET Dave Brockman writes:

=============================================================== From: kitepilot@kitepilot.com ------------------------------------------------------ Please somebody correct my if I am wrong, but if eth0 is the public interface, it will never 'see' packets from the 10.8.0.0/24 network because that network is not routable and any traffic to and from those addresses is encrypted and encapsulated over packets addressed to and from public the addresses. No? ET

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm good, I was just pointing out what David thought was strange regarding the DHCP server on the client is in fact the same behavior I see on my clients connected to the VPN. Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3eAPAAoJEMP+wtEOVbcdDNoH/2WBFFz/pQzG2N0smtubX2M/ s2CccTIg4c1RwIl48i1V4SJVPNqSgEYjr8sjAFMiTWWVTKqhoQ7QsDoOk9Cai2b7 JOUsMWLIYIehSSZLTnhLeSpM7bE5UldSUQLa+lkjecmhWq28vEVsHDARtpd5mnUd tPtTmFe98ja0gPIERIfypu+2WMWJwiwduppXdq4rW9s0R4PEBTM3jZRCPJaldEbv KTIdjbFMnrVHKQQw/BM8L+zoGom4u2SHdjlWPw8h+hF1mPvAAxEhH40ZgurazgQj RXwSKVD7ZtooJ1X7+GhdzbNeCrlGMcvCwlNMBYSKLmUvgg7SwbCUIdXxQEghFRc= =Avlj -----END PGP SIGNATURE-----

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You may have hit the nail on the head ET! That should probably be the VPN adapter interface, eth0 shouldn't see that traffic. Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3eC8AAoJEMP+wtEOVbcd2/YH/1nCpZR6Ku6/N9npiMFINiZp wdWTPBdGuHxTSVArfb79XFnuCSTvTbE1XN5saKEOI259yLnGQuFi0sfhudLvZ2n4 8nqwA6OTDuQCoDMTpiDo+uSY1AqX3AAbzCJtxoJus+krY418lz+lH1dt+H89wRGt cgFeVzcpSoT0CvYM2b0cch/15oNkG6EixrT9lK1zW8/gtAslt9lOsnygNYhcddAj xIfqRqEfU9MoYphWkvsBzJ/4jRmNFE4zNvPERXLsoBINkNh8VpoUZ43ogvlro+u2 jKX4RGflEiT7QFrrzpPoer8mz/5MkMaix+q0/sfC07JQvYz8F694TI9jG1DwU7o= =Av5G -----END PGP SIGNATURE-----

=============================================================== From: David White ------------------------------------------------------ Hmm.... so would I need to add another route for 10.8.0.0/24 to go through the virtual tap adapter? Or any other bright ideas on how I can fix this?

=============================================================== From: Sudo Bash ------------------------------------------------------ First you'll want to use UDP for OpenVPN most of the time. Two what are the gateways of the VPN Server and the DHCP Server attached to your home network? If pfSense is your gateway, you might as well just use the OpenVPN server in there as it would be the easiest solution as it is already being used as Router/Firewall/Gateway most likely...

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Give me the output of ifconfig -a from the server and ipconfig /all route -4 print on the client when it is connected to the VPN (assuming it's Windows) Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3g0HAAoJEMP+wtEOVbcdGU4IAK+MwneYjxvztEm29lqNvyoM +VLpDhj2dKvcprxuw2tU6P0EzBFzCEbqSUSl5qxbDw2WTEiw5xCgv0sStdTKlbWJ fkLsEWFUmiWOeOyKOqRvDnui/NIypmNRI0Rvoush6Y5+lcXsPOvdwFD55yKu11t3 ra1h6mI4cNMheZR/LzvoaOjKdGyyszPYE58k3H/FjkT4UU/zvbeMvHu7XshDWWth Myo0moQVDP/Zi9e8XcNzCyaaSwN9EfZugWFAC0kCzk8rRJnCXtDNe2s8FAgn/suu uNE0Gp0Iy4fjdVXesUo1MI2xAjd+ZpeoyfKCO1Y7g9TsKHXp2686UmFh1wz+GJE= =qHXU -----END PGP SIGNATURE-----

=============================================================== From: Sudo Bash ------------------------------------------------------ That's actually: route PRINT -4 on Windows ;-)

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 True dat :) Regards, dtb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3jQcAAoJEMP+wtEOVbcdWpQH/ieEAJQgeRFgVc8NBGr06O+i bhSwOx8J0RskLZqY4LotJZ9MxCusMyiPcAUanO1g/R8R5rNIw3t2GxLVQMd0MoZN ijc43qBwPSxAZyVexTR9YCK0XcMEtMa3lmtyHvCVKClob8XYc91WM9CnIAlA0K2y czET0yhQEF8sXSuBZogsK01ibsSpxZLNM46P/kIjpkky4z43NKpa/ZsATuCTtAZ1 EoS2RfPbx7iAux1Pc50LNgk30qIfLtpruIYuuzj02tjurTozkMpy8rM4eR/fEML1 cDWnx7TGGu4J3UEwF4MJ9DP8tbKtkJ/8itFzb3uguvZbR3SkdhD7PqQRvM4L9Gc= =l4Q5 -----END PGP SIGNATURE-----

=============================================================== From: Sudo Bash ------------------------------------------------------ I think it's related to a gateway issue, but it's hard to tell really without that routing information.

=============================================================== From: Mike Harrison ------------------------------------------------------ Just out of curiosity, if you run MTR or Traceroute to the outside world, how far does it go? I have forgotten the windows version syntax, but from my Linux desktop on OpenVPN as 192.168.42.10 connected to pfSense at 192.168.42.9 it looks like: # mtr -r -c 1 12.1.1.1 HOST: gem Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.41.1 0.0% 1 10.4 10.4 10.4 10.4 0.0 2.|-- gw177.networksonline.net 0.0% 1 10.9 10.9 10.9 10.9 0.0 3.|-- static-host-66-18-35-65.e 0.0% 1 10.7 10.7 10.7 10.7 0.0 4.|-- atl-edge-24.inet.qwest.ne 0.0% 1 13.9 13.9 13.9 13.9 0.0 Because in my case, I don't want all my traffic to go out the VPN, I usually change my routes with: route del default route add default gw 192.168.1.1 So I only use the VPN for things that need it, (Saving the Networks Guys some redundant bandwidth, and I get a more direct connection) and then that same command looks like: mtr -r -c 1 12.1.1.1 HOST: gem Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.1.1 0.0% 1 0.4 0.4 0.4 0.4 0.0 2.|-- 69.24.139.129 0.0% 1 5.6 5.6 5.6 5.6 0.0 3.|-- 209.235.164.93 0.0% 1 6.7 6.7 6.7 6.7 0.0 4.|-- te-3-2.car2.Atlanta1.Leve 0.0% 1 4.8 4.8 4.8 4.8 0.0 If you run "tracert" or whatever b0rken command on your MS boxen, how far and out which port does it go?

=============================================================== From: David White ------------------------------------------------------ When the VPN is connected.... *[root@elmer ~]# ifconfig -a* dummy0 Link encap:Ethernet HWaddr CA:BF:92:B2:31:ED BROADCAST NOARP 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:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth0 Link encap:Ethernet HWaddr FE:FD:42:E4:3B:67 inet addr:66.228.59.103 Bcast:66.228.59.255 Mask:255.255.255.0 inet6 addr: fe80::fcfd:42ff:fee4:3b67/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2646696 errors:0 dropped:0 overruns:0 frame:0 TX packets:2433127 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:996269219 (950.1 MiB) TX bytes:858723536 (818.9 MiB) Interrupt:78 gre0 Link encap:UNSPEC HWaddr 00-00-00-00-09-47-A1-DC-00-00-00-00-00-00-00-00 NOARP MTU:1476 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:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ip6gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1448 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:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ip6tnl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:1452 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:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:255753 errors:0 dropped:0 overruns:0 frame:0 TX packets:255753 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:110932022 (105.7 MiB) TX bytes:110932022 (105.7 MiB) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 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:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) teql0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP 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) tunl0 Link encap:IPIP Tunnel HWaddr NOARP MTU:1480 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:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:1801 errors:0 dropped:0 overruns:0 frame:0 TX packets:1486 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:93177 (90.9 KiB) TX bytes:65383 (63.8 KiB) *ipconfig /all (on client) *(but only the relevant information of connected adapters) Ethernet adapter MyTap: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : TAP-Windows Adapter V9 Physical Address. . . . . . . . . : 00-FF-3D-C6-25-13 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::94d0:3aa:50b7:1e6c%17(Preferred) IPv4 Address. . . . . . . . . . . : 10.8.0.6(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.252 Lease Obtained. . . . . . . . . . : Thursday, July 11, 2013 7:46:57 AM Lease Expires . . . . . . . . . . : Friday, July 11, 2014 7:46:56 AM Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 10.8.0.5 DHCPv6 IAID . . . . . . . . . . . : 268500797 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-36-D0-79-48-5D-60-3B-CF-5B Wireless LAN adapter Wireless Network Connection: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Atheros AR9285 Wireless Network Adapter Physical Address. . . . . . . . . : 48-5D-60-3B-CF-5B DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::7599:d89b:b76c:2471%10(Preferred) IPv4 Address. . . . . . . . . . . : 192.168.252.133(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Thursday, July 11, 2013 6:43:32 AM Lease Expires . . . . . . . . . . : Thursday, July 18, 2013 6:43:35 AM Default Gateway . . . . . . . . . : 192.168.252.1 DHCP Server . . . . . . . . . . . : 192.168.252.1 DHCPv6 IAID . . . . . . . . . . . : 239623520 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-36-D0-79-48-5D-60-3B-CF-5B DNS Servers . . . . . . . . . . . : 192.168.252.1 NetBIOS over Tcpip. . . . . . . . : Enabled *C:\Users\David>route -4 PRINT* =========================================================================== Interface List 17...00 ff 3d c6 25 13 ......TAP-Windows Adapter V9 15...6a 5d 60 3b cf 5b ......Microsoft Virtual WiFi Miniport Adapter 11...20 cf 30 6a 59 df ......JMicron PCI Express Gigabit Ethernet Adapter 10...48 5d 60 3b cf 5b ......Atheros AR9285 Wireless Network Adapter 1...........................Software Loopback Interface 1 19...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface 18...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2 =========================================================================== IPv4 Route Table =========================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.252.1 192.168.252.133 25 0.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 31 10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 31 10.8.0.4 255.255.255.252 On-link 10.8.0.6 286 10.8.0.6 255.255.255.255 On-link 10.8.0.6 286 10.8.0.7 255.255.255.255 On-link 10.8.0.6 286 66.228.59.103 255.255.255.255 192.168.252.1 192.168.252.133 26 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 128.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 31 192.168.252.0 255.255.255.0 On-link 192.168.252.133 281 192.168.252.1 255.255.255.255 192.168.252.1 192.168.252.133 26 192.168.252.133 255.255.255.255 On-link 192.168.252.133 281 192.168.252.255 255.255.255.255 On-link 192.168.252.133 281 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 10.8.0.6 286 224.0.0.0 240.0.0.0 On-link 192.168.252.133 281 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 10.8.0.6 286 255.255.255.255 255.255.255.255 On-link 192.168.252.133 281 =========================================================================== Persistent Routes: None *C:\Users\David>tracert 8.8.8.8* Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops: 1 * 74 ms * 10.8.0.1 2 * 10.8.0.1 reports: Destination protocol unreachable. Trace complete.

=============================================================== From: Mike Harrison ------------------------------------------------------ Cutting that to the relevant parts gives us: ---------------------------------------------------------------------- eth0 66.228.59.103  Bcast:66.228.59.255  Mask:255.255.255.0 tun0 10.8.0.1   P-t-P:10.8.0.2  Mask:255.255.255.255 Network Destination        Netmask          Gateway       Interface Metric           0.0.0.0          0.0.0.0    192.168.252.1  192.168.252.133     25           0.0.0.0        128.0.0.0         10.8.0.5         10.8.0.6     31          10.8.0.0    255.255.255.0         10.8.0.5         10.8.0.6     31          10.8.0.4  255.255.255.252         On-link          10.8.0.6    286          10.8.0.6  255.255.255.255         On-link          10.8.0.6    286          10.8.0.7  255.255.255.255         On-link          10.8.0.6    286     66.228.59.103  255.255.255.255    192.168.252.1  192.168.252.133   26 C:\Users\David>tracert 8.8.8.8 Tracing route to google-public-dns-a.google.com [google-public-dns-a.google.com] [8.8.8.8] over a maximum of 30 hops:   1     *       74 ms     *     10.8.0.1   2     *     10.8.0.1  reports: Destination protocol unreachable. -------------------------------------------------------------------------- This tells me: You can see 10.8.0.1, the OpenVPN router address. That in trying to get to 8.8.8.8, it goes that way. That at 10.8.0.1 it apparently reports back it can't do a traceroute past that point.. and you got the response. Your issue is PROBABLY (may not be) at 10.8.0.1 with a firewall rule or route back to 10.8.x.x. Make sure on your CentOS boxen, you are NATing your VPN address range (10.8.x.x) and that it is allowed to do all going out.. What are your relevant (not all) iptables restrictions / NAT's? on the CentOS box: ie: What do yo get from "iptables -L" that addresses 10.8.x.x Got accepts? Got forwards.. etc.. ?

=============================================================== From: Dave Brockman ------------------------------------------------------ I suspect his NAT rule is incorrect. Server forwarding packets from VPN to Internet still using RFC1918 addresses. Would be interesting to see tcpdump on eth0 while VPN traffic is being sent to the interwebs. Please excuse brevity and grammar, sent from my mobile device.

=============================================================== From: David White ------------------------------------------------------ I just ran a grep for 10.8 on iptables -L, and there's no rules for that IP address range right now.

=============================================================== From: Sudo Bash ------------------------------------------------------ *Are you specifically wanting all DNS lookups going through the VPN?* *;push "redirect-gateway"* *# If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # the TUN/TAP interface to the internet in # order for this to work properly). # CAVEAT: May break client's network config if # client's local DHCP server packets get routed # through the tunnel. * *Solution: make sure client's local DHCP server is reachable via a more specific route than the default route of 0.0.0.0/0.0.0.0. * *Just as a test try to push a route of 10.8.0.0/8*

=============================================================== From: David White ------------------------------------------------------ A couple of you guys have emailed me directly or through this thread. I'll try to get back to you soon. This still isn't resolved, but I've been a bit tied up the past few days. :) Thanks for your emails.