Support

Blog

Browsing all articles tagged with dnscache

Flattr this!

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…
Generate key’s etc (tons of other tutorials on that)

Prelim info
My vpn server has a static ip address, in the 66.xx range. Our local client machines use a 192.x range (typically).
I setup a tun address for 10.1.0.1 for the server.

As we don’t want to have routing issues, I set openvpn to use the 10.x range for any vpn connections.
(Essentially all clients connected to the openvpn ip will get a 10.1.0.x address).

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’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’ve put in on port 8080 for our users, as this seems to work without issue.

To do all that, I created an openvpn.conf file with the following:

port 8080
#proto tcp
#dev tun
proto udp
dev tap
ca keys/ca.crt
cert keys/server.crt
key keys/server.key
dh keys/dh1024.pem
server 10.1.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
client-to-client
push "redirect-gateway"
push "dhcp-option DNS 10.1.0.1"
link-mtu 1456
mssfix 1412
cipher AES-256-CBC

(You can read the standard install stuff for your own key generation)

Next we need to tell our server to route stuff appropriately for vpn traffic

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A INPUT -p udp --dport 8080 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.1.0.0/24 -o eth0 -j MASQUERADE

(You’ll need to change the 10.1.0.0 to your actual vpn user subnet if you change in the openvpn.conf)

OpenVPN should start, and be connectable.

My client config looks approximately something like this:

client
dev tap
proto udp
remote mysupersekritvpnserver.com 8080
comp-lzo
verb 3
mute 20
nobind
persist-key
persist-tun
cipher AES-256-CBC
ca ca.crt
cert my.crt
key my.key

my.crt, my.key, ca.crt should be copied / generated from the server, and copied over to the client machine.
mysupersekritvpnserver.com should be changed to your server name.
We use Mac’s mostly, so we use tunnelblick, copy that config in, check the “Set NameServer” box in Details.

You should be able to connect now and ping remotely with that.
Next, we need to setup DNS

For the longest time I couldn’t get this working, despite me reading and re-reading the doc’s.

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

This wasn’t working at all.

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’t.

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 “just add the ip address for the computers allowed to connect” to the dnscachefolder/root/ip, you really need to bind it to all the ports you will want lookups to work for.

    Which is not clearly mentioned in any documentation I saw on the net.

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.

Hours of fun and joy.

Worth it though, I can now connect to bookface and toobyou, yay!

Archives

Categories

Tags

PHOTOSTREAM