E
Eric Hansen
Guest
So now we have a VPN client, VPN server and now we’re ready to get our pseudo site-to-site network going. We’ll test this with a simple web server first. While I hate using it, for this purpose we’ll be using Apache and we’ll test both HTTP and HTTPS.
On the client machine lets install Apache:
Apache should auto-start on the client server, so visit your client machine via web browser and see if a web page shows up. Cool huh?
Well, we’ll take this a step further. Remember the inet address I told you to make note of in the last part? This is where it’ll come in handy. On the server we are going to mess with iptables a little bit.
We’ll enter two iptables commands on the server:
While I won’t get into a whole guide on how iptables works, basically since we want to forward traffic to another machine without ever concerning ourselves with it on the VPN server we need to use the NAT (network address translation) table. If you are familiar with basic iptables then PREROUTING can be compared to the INPUT chain and POSTROUTING compared to the OUTPUT chain. So everything on the server end we want to route to a client machine should go in the NAT’s PREROUTING chain.
For prerouting we are basically saying any traffic on TCP/80 is to be redirect to 10.8.0.6:80 (our client machine). if you set up Apache to run on a different port then you would just change “80” to whatever port its running on.
Now, I’m not going to pretend to be a guru with iptables (i.e.: man pages are my friend), but the postrouting table basically says “any packet leaving me will have my IP address”. Per the man pages themselves regarding MASQUERADE:
What about HTTPS, though? Well, lets do that now! First, on the server we’ll add a new rule to iptables’ PREROUTING:
This is exactly the same and shouldn’t come to any surprise, either.
Now, on the client, we’ll need to generate some SSL information:
This will create a CA file of sorts. It’ll require you enter a passphrase. Since I’m lazy and this is only for demonstration purposes I just entered a short 4-character password. We’ll be removing it anyways (optional but less annoying if the server has to be restarted for any reason).
Next is a certificate signing request (CSR):
You’ll be prompted for the passphrase of the server.key file we just created so enter that, and I just allowed all the default values since you’ll get an SSL error regardless when you browse to it (its the fault of self-signed certificates period).
Here’s the optional step of removing the passphrase:
Now you won’t be prompted for the passphrase.
To top off the certificate process we create the certificate itself:
Lets make sure SSL is enabled for Apache (don’t restart it just yet):
What we need to do is enable our SSL site so we don’t get cryptic errors in our log file:
Now we’ll restart Apache:
Now when you browse to https://cs01.example.com you should see the same page as http://cs01.example.com!
There’s a multitude of applications for this (though not sure on using this for email purposes...have ran into issues). This is a great way to combat the threat of a DMZ and still provide security. You could also further increase the security of OpenVPN as well to help ensure data is left encrypted. This was just an overview.
On the client machine lets install Apache:
Code:
root@SKYNet:/etc/openvpn# apt-get install apache2
Well, we’ll take this a step further. Remember the inet address I told you to make note of in the last part? This is where it’ll come in handy. On the server we are going to mess with iptables a little bit.
We’ll enter two iptables commands on the server:
Code:
root@cs01:/etc/openvpn/easy-rsa# iptables -t nat -I PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.8.0.6:80
root@cs01:/etc/openvpn/easy-rsa# iptables -t nat -I POSTROUTING -j MASQUERADE
For prerouting we are basically saying any traffic on TCP/80 is to be redirect to 10.8.0.6:80 (our client machine). if you set up Apache to run on a different port then you would just change “80” to whatever port its running on.
Now, I’m not going to pretend to be a guru with iptables (i.e.: man pages are my friend), but the postrouting table basically says “any packet leaving me will have my IP address”. Per the man pages themselves regarding MASQUERADE:
Since this is on a VPS it would be safe to do the SNAT route instead, but rather be on the safe side knowing how my luck with VPSes is. Basically, if you have a static IP it recommends using SNAT, otherwise use MASQUERADE.It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. Masquerading is equivalent to specifying a mapping to the IP address of the interface the packet is going out, but also has the effect that connections are forgotten when the interface goes down. This is the correct behavior when the next dialup is unlikely to have the same interface address (and hence any established connections are lost anyway).
What about HTTPS, though? Well, lets do that now! First, on the server we’ll add a new rule to iptables’ PREROUTING:
Code:
root@cs01:/etc/openvpn/easy-rsa# iptables -t nat -I PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.8.0.6:443
Now, on the client, we’ll need to generate some SSL information:
Code:
root@SKYNet:/etc/apache2# openssl genrsa -des3 -out server.key 1024
Next is a certificate signing request (CSR):
Code:
root@SKYNet:/etc/apache2# openssl req -new -key server.key -out server.csr
Here’s the optional step of removing the passphrase:
Code:
root@SKYNet:/etc/apache2# cp server.key server.key.org
root@SKYNet:/etc/apache2# openssl rsa -in server.key.org -out server.key
Enter pass phrase for server.key.org:
writing RSA key
To top off the certificate process we create the certificate itself:
Code:
root@SKYNet:/etc/apache2# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Code:
root@SKYNet:/etc/apache2# a2enmod ssl
Code:
root@SKYNet:/etc/apache2# ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/001-default-ssl
Code:
root@SKYNet:/etc/apache2# service apache2 restart
There’s a multitude of applications for this (though not sure on using this for email purposes...have ran into issues). This is a great way to combat the threat of a DMZ and still provide security. You could also further increase the security of OpenVPN as well to help ensure data is left encrypted. This was just an overview.