Browsing all articles from November, 2009

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 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
ifconfig-pool-persist ipp.txt
keepalive 10 120
user nobody
group users
status /var/log/openvpn-status.log
verb 3
push "redirect-gateway"
push "dhcp-option DNS"
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 -o eth0 -j MASQUERADE

(You’ll need to change the 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:

dev tap
proto udp
remote 8080
verb 3
mute 20
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. 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 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, 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!

Flattr this!

Unfortunately, its back to the techie stuff for a few posts!

Here are my crib notes on installing NGinx on one of our client servers.

Add spawn-fcgi (cos its split from litettpd now)

cd /downloads
svn co svn:// spawn-fcgi

No svn..grrr

apt-get install subversion subversion-tools
svn co svn:// spawn-fcgi
cd spawn-fcgi
make install

spawn-fcgi should be happily installed in /usr/local/bin/spawn-fcgi now

make sure we have php5-cgi
apt-get install php5-cgi

Check spawn-fcgi runs –
In my case not, had to rebuild eAccelerator @#$@#$!, did that, and all ok

/bin/spawn-fcgi -f /usr/bin/php5-cgi -a -p 53217 -P /var/run/

Note port 53217 can be any unused port from some high unused number though to 65535
We’re going to be installing NGinx from debian packages, but probably better from source long term…

apt-get install nginx

pico /etc/nginx/nginx.conf

change some default settings

user www-data;
worker_processes 1;

error_log /var/log/nginx/error.log;
pid /var/run/;

events {
worker_connections 1024;

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

access_log /var/log/nginx/access.log;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 5;
tcp_nodelay on;

client_max_body_size 8m;

gzip on;
gzip_comp_level 9;
gzip_types text/plain text/html text/css text/xml application/xml application/xml+rss text/javascript application/x-javascript;

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Now we add our virtual hosts in /etc/nginx/sites-available

pico /etc/nginx/sites-available

Lastly, we add our fast-cgi settings, using our port from above 53217

fastcgi stuff here

Flattr this!

If anyone wants to mess around with the settings for the Huawei eHome router EchoLife HG522-c (typically the ones supplied with the “3M or 4M” connection), then here are the user / pass settings.

User: telecomadmin

Useful if you want to rejig the QoS settings.

If that login doesn’t work, try this – which is usually seen on the HG226 models –
User: fiberhomehg2x0
Pass: hg2x0

The other standard modem HG520S is easier – admin / admin

Might be useful for some folks. I’m mostly posting here for myself, as I’ll probably forget and need to google it later.