Fedora :: Setup - And IPredator With Custom Routing

Background: Took a while to get this working correctly, so figured I'd save you all some time... I (finally) received the beta invite from iPredator. I wasn't happy with the NetworkManager-pptp implementation, I'm running the stock kernel, I stopped the NetworkManager service at this point.

Goals:
1. To be able to control the PPTP tunnel from a remote location over ssh
2. To have services I run from my box accessible via my public IP on the internet (sshd, httpd etc) whilst the tunnel is up
3. To route all Torrent traffic from Vuze out of the encrypted PPTP tunnel, and have it return over that interface
4. To route all other traffic, by default, to my ISP unencrypted
5. To block all Vuze traffic if the tunnel is down

Method:1. PPP config

First, I entered my login details (altered in the below output, of course!!) into chap-secrets and then used "chmod 600 chap-secrets" to make it read/write for root only:

Next, I created a peer file (644 permissions) for the VPN connection, the file name has to match the "iPred" I used above:

I stuck with the defaults in /etc/ppp/options.pptp

To initiate the tunnel, I use: pppd call iPred mtu 1435 mru 1435 persist nolog

Regarding the options used... I'll get onto the MTU/MRU later, persist has the tunnel attempt to reconnect 10 times if it drops, nolog reduces the high volume of syslog messages. The logs for the connection process are written to /var/log/messages, interface ppp0 was created and routing entries were set up (internal network stuff has been cut out below; we'll call 192.168.100.104 my WAN IP, though I've got a static internet-routable IP and wanted to mask it here). The (dynamic) endpoint of the tunnel is 93.182.164.2: you need two routes to this, one via eth0 (my WAN interface) for internet routing of the encrypted packets, and one through the tunnel itself to tunnel and encrypt the traffic:

References:[url] [url]

2. Firewall Setup

I'm a "belt-and-braces" kinda guy ("belt-and-suspenders" if you're from the US), and I've got a custom firewall setup. As I've brought a new interface into the equation, I needed to add some rules.

In order, the rules:

A. NAT the outgoing packets to the ppp0 interface IP
B. Allow established sessions back in
C. Allow the default ports for Vuze through, even if unsolicited, on port 63255 (TCP and UDP)
D. Drop traffic that originates from Vuze (identified by the IP of interface lo:0, which we'll see later) if it tries to exit via eth0 (useful if the tunnel drops or hasn't yet been started)

You can view the rules in place by issuing: iptables -nL

References:man iptables [url]

3. Routing Setup

Obviously, I didn't know who the Vuze peers are going to be and setting a default route via ppp0 means that all traffic would be encrypted. Instead, I created a new, distinct, routing table called IPRED in iproute.

Then I added a default route, via ppp0, into the IPRED routing table and checked that it was there:

The main (default) routing table is still there and has it's routes:

4. Traffic Identification

I tried setting the DSCP (ToS) in Vuze, but that didn't make it into the packets (checking the output packets with Wireshark). So, I created a new Loopback interface lo:0 on my box (later I entered this line into /etc/rc.local so it'll survive a reboot):

I then added a rule to pass traffic from this new lo:0 IP to the IPRED table:

There are a number of other ways to pick out traffic with "ip rule", but this seemed the most elegant solution in this situation.

5. Vuze Config

I looked down the list for the local IP addresses, then bound Vuze to the lo:0 interface which, in Vuze, is lo[1]

Whilst in here, I also dropped the Line MTU to 1435. You'll notice that this matches the MTU and MRU set when using pppd to establish the tunnel... I'm on DSL and have the MTU set to 1478 for the DSL link, the difference between the 1478 and 1435 is the overhead of the additional headers used with PPTP tunnelling (both PPP and GRE headers encapsulate the packets). With the MTUs set up in this way, I shouldn't get any fragmentation of packets on the link, packets with the DontFragment bit set shouldn't get dropped. I gave Vuze a restart.

6. Verifying Operation

I closed any apps that were using the internet, fired up Vuze, loaded a torrent, then opened two Wireshark windows.... Started Wireshark#1 on the eth0 WAN interface and Wireshark#2 on the ppp0 tunnel interface. I saw a long list of PPP and GRE packets (in white) scrolling on the eth0 window, showing that Vuze is going through the tunnel. Checking the ppp0 Wireshark window, I saw the actual Vuze traffic on the ppp0, with SYN's, ACK's, http packets etc as it's being sent down/back through the tunnel.

Starting firefox and visiting www.whatismyip.com, the IP reported was my eth0 address, I saw the http traffic on Wireshark on eth0. Starting e-mail, I saw the packets on eth0.

Dropping the tunnel, I checked Vuze, saw that torrents had stopped and confirmed that I couldn't connect to the net with it.

7. DNATing

Reconnecting everything, I sat and watched the Wireshark outputs on ppp0 and eth0 for a while to make sure everything was working. I noticed that the ppp0 interface was creating a lot of ARP requests for external IP's and sending them out, unencrypted, through eth0 - BAD news!! I'd forgotten that I would need to Destination NAT the unsolicited inbound connections... D'Oh!

As the unsolicited inbound connections are directed at the internet-routable tunnel IP of ppp0, we need to point these to the lo:0 interface that Vuze is listening on. Replies to these will be NAT'd back to the ppp0 address by the MASQUERADE rule we've already entered in iptables and, since the source IP will 172.27.72.64, the packets will match the ip rule pointing them to the IPRED routing table, thus they won't generate ARP requests.

Retrying everything with the firewall updated, everything is working 100% :-D

8. Misc

As the iptables rules have been saved, and lo:0 will survive a reboot in /etc/rc.local, the only commands that need to be run each time you want to bring up the tunnel are (easily scripted with a sleep statement of about 10 seconds after pppd call...):

And, if you wanted to just send all traffic over ppp0, this would be:

Conclusion: I love Linux, an intellectual challenge, having complete control over my PC; iPredator rocks and I hope this howto is of use to anyone running Fedora and iPredator :-D