{"id":286,"date":"2009-11-30T08:00:20","date_gmt":"2009-11-30T00:00:20","guid":{"rendered":"http:\/\/www.computersolutions.cn\/blog\/?p=286"},"modified":"2009-11-30T08:00:20","modified_gmt":"2009-11-30T00:00:20","slug":"openvpn-setup-notes-with-dnscache-goodness","status":"publish","type":"post","link":"https:\/\/www.computersolutions.cn\/blog\/2009\/11\/openvpn-setup-notes-with-dnscache-goodness\/","title":{"rendered":"OpenVPN setup notes (with dnscache goodness)"},"content":{"rendered":"<p>Setting up OpenVPN was a real PIA for a number of reasons DNS, crap documentation, and general issues with vpn clients.  <\/p>\n<p>My working notes are below:<\/p>\n<p>Install OPENVPN from tar.gz or apt-get install&#8230;<br \/>\nGenerate key&#8217;s etc (tons of other tutorials on that)<\/p>\n<p><strong>Prelim info<\/strong><br \/>\nMy vpn server has a static ip address, in the 66.xx range.  Our local client machines use a 192.x range (typically).<br \/>\nI setup a tun address for 10.1.0.1 for the server.<\/p>\n<p>As we don&#8217;t want to have routing issues, I set openvpn to use the 10.x range for any vpn connections.<br \/>\n(Essentially all clients connected to the openvpn ip will get a 10.1.0.x address).<\/p>\n<p>I also force clients to use our DNS server (more on that later), as China does some DNS lookup interceptions which break stuff if you are using a tunnel. I also don&#8217;t use openvpn on the standard port 1194, as I was seeing mysterious tcp resets when using the common vpn ports. Amazing how that happens in China.  Lastly, I&#8217;ve put in on port 8080 for our users, as this seems to work without issue.  <\/p>\n<p>To do all that, I created an openvpn.conf file with the following:<\/p>\n<p><code>port 8080<br \/>\n#proto tcp<br \/>\n#dev tun<br \/>\nproto udp<br \/>\ndev tap<br \/>\nca keys\/ca.crt<br \/>\ncert keys\/server.crt<br \/>\nkey keys\/server.key<br \/>\ndh keys\/dh1024.pem<br \/>\nserver 10.1.0.0 255.255.255.0<br \/>\nifconfig-pool-persist ipp.txt<br \/>\nkeepalive 10 120<br \/>\ncomp-lzo<br \/>\nuser nobody<br \/>\ngroup users<br \/>\npersist-key<br \/>\npersist-tun<br \/>\nstatus \/var\/log\/openvpn-status.log<br \/>\nverb 3<br \/>\nclient-to-client<br \/>\npush \"redirect-gateway\"<br \/>\npush \"dhcp-option DNS 10.1.0.1\"<br \/>\nlink-mtu 1456<br \/>\nmssfix 1412<br \/>\ncipher AES-256-CBC<\/code><\/p>\n<p>(You can read the standard install stuff for your own key generation)<\/p>\n<p>Next we need to tell our server to route stuff appropriately for vpn traffic<\/p>\n<p><code>echo 1 > \/proc\/sys\/net\/ipv4\/ip_forward<br \/>\niptables -A INPUT -p udp --dport 8080 -j ACCEPT<br \/>\niptables -A INPUT -i tun+ -j ACCEPT<br \/>\niptables -A FORWARD -i tun+ -j ACCEPT<br \/>\niptables -A INPUT -i tap+ -j ACCEPT<br \/>\niptables -A FORWARD -i tap+ -j ACCEPT<br \/>\niptables -t nat -A POSTROUTING -s  10.1.0.0\/24 -o eth0 -j MASQUERADE<\/code><\/p>\n<p>(You&#8217;ll need to change the 10.1.0.0 to your actual vpn user subnet if you change in the openvpn.conf)<\/p>\n<p>OpenVPN should start, and be connectable.<\/p>\n<p>My client config looks approximately something like this:<\/p>\n<p><code>client<br \/>\ndev tap<br \/>\nproto udp<br \/>\nremote mysupersekritvpnserver.com 8080<br \/>\ncomp-lzo<br \/>\nverb 3<br \/>\nmute 20<br \/>\nnobind<br \/>\npersist-key<br \/>\npersist-tun<br \/>\ncipher AES-256-CBC<br \/>\nca ca.crt<br \/>\ncert my.crt<br \/>\nkey my.key<\/code><\/p>\n<p>my.crt, my.key, ca.crt should be copied \/ generated from the server, and copied over to the client machine.<br \/>\nmysupersekritvpnserver.com should be changed to your server name.<br \/>\nWe use Mac&#8217;s mostly, so we use tunnelblick, copy that config in, check the &#8220;Set NameServer&#8221; box in Details.<\/p>\n<p>You should be able to connect now and ping remotely with that.<br \/>\nNext, we need to setup DNS<\/p>\n<p>For the longest time I couldn&#8217;t get this working, despite me reading and re-reading the doc&#8217;s.<\/p>\n<p>We use dnscache for dns lookups on our servers. DNS Cache allegedly allows lookups from other ip addresses by sticking whats allowed into \/etc\/dnscache\/root\/ip<\/p>\n<p>This wasn&#8217;t working at all.<\/p>\n<p>Eventually I twigged that dnscache binds to one ip address, and ignores the others, which is why local lookups worked, but tunnel started ones didn&#8217;t.<\/p>\n<p>Took me a while to see that though.  Was only when I did an nmap 10.1.0.1 and saw port 53 was closed, that I realised, despite the misleading fscking documentation which says &#8220;just add the ip address for the computers allowed to connect&#8221; to the dnscachefolder\/root\/ip, you really need to bind it to all the ports you will want lookups to work for.<\/p>\n<ul>Which is not clearly mentioned in any documentation I saw on the net.<\/ul>\n<p>I ended up making another dnscache specifically for our tun address on 10.1.0.1, and telling it to allow queries from the actual server ip 66.x, and from 10.x, *then* it started working.<\/p>\n<p>Hours of fun and joy.<\/p>\n<p>Worth it though, I can now connect to bookface and toobyou, yay!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Setting up OpenVPN was a real PIA for a number of reasons DNS, crap documentation, and general issues with vpn clients. My working notes are below: Install OPENVPN from tar.gz or apt-get install&#8230; Generate key&#8217;s etc (tons of other tutorials on that) Prelim info My vpn server has a static ip address, in the 66.xx [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[25],"tags":[146,145],"class_list":["post-286","post","type-post","status-publish","format-standard","hentry","category-technical-mumbo-jumbo","tag-dnscache","tag-openvpn"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/286","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/comments?post=286"}],"version-history":[{"count":1,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/286\/revisions"}],"predecessor-version":[{"id":287,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/286\/revisions\/287"}],"wp:attachment":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/media?parent=286"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/categories?post=286"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/tags?post=286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}