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:
[root@minataur ppp]# cat /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client server secret IP addresses
Us3rNaM3 iPred "Pa55w0rd" vpn.ipredator.se
Next, I created a peer file (644 permissions) for the VPN connection, the file name has to match the "iPred" I used above:
[root@minataur peers]# cat /etc/ppp/peers/iPred
pty "pptp vpn.ipredator.se --nolaunchpppd --loglevel 0"
lock
noauth
nobsdcomp
nodeflate
name Us3rNaM3
remotename iPred
ipparam iPred
require-mppe-128
refuse-eap
file /etc/ppp/options.pptp
[root@minataur peers]#
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:
[root@minataur ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
93.182.164.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
93.182.164.2 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
0.0.0.0 192.168.100.104 0.0.0.0 UG 0 0 0 eth0
[root@minataur ~]#
References:
http://wiki.archlinux.org/index.php/...ith_pptpclient
http://rot13.baywords.com/2009/06/16...vpn-on-ubuntu/
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)
[root@minataur ~]# iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
[root@minataur ~]# iptables -A INPUT -t filter -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
[root@minataur ~]# iptables -A INPUT -t filter -i ppp0 -p tcp -m tcp --dport 63255 -j ACCEPT
[root@minataur ~]# iptables -A INPUT -t filter -i ppp0 -p udp -m udp --dport 63255 -j ACCEPT
[root@minataur ~]# iptables -A FORWARD -t filter -s 172.27.72.64/32 -o eth0 -j DROP
[root@minataur ~]# iptables-save
You can view the rules in place by issuing: iptables -nL
References: man iptables
http://www.linuxhomenetworking.com/w...Using_iptables
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.
[root@minataur ~]# echo 1 IPRED >> /etc/iproute2/rt_tables
[root@minataur ~]#
Then I added a default route, via ppp0, into the IPRED routing table and checked that it was there:
[root@minataur ~]# ip route add default dev ppp0 table IPRED
[root@minataur ~]# ip route show table IPRED
default dev ppp0 scope link
[root@minataur ~]#
The main (default) routing table is still there and has it's routes:
[root@minataur ~]# ip route show table main
93.182.164.2 dev eth0 scope link src 192.168.100.104
93.182.164.2 dev ppp0 proto kernel scope link src 93.182.164.50
default via 192.168.100.104 dev eth0
[root@minataur ~]#
References:
http://www.linuxhorizon.ro/iproute2.html
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):
[root@minataur ~]# ifconfig lo:0 address 172.27.72.64 netmask 255.255.255.255
I then added a rule to pass traffic from this new lo:0 IP to the IPRED table:
[root@minataur ~]# ip rule add from 172.27.72.64/32 table IPRED
[root@minataur ~]# ip rule show
0: from all lookup local
32765: from 172.27.72.64 lookup IPRED
32766: from all lookup main
32767: from all lookup default
[root@minataur ~]#
There are a number of other ways to pick out traffic with "ip rule", but this seemed the most elegant solution in this situation.
References:
http://www.linuxhorizon.ro/iproute2.html
http://lartc.org/howto/index.html
5. Vuze Config
Tools > Options (in Advanced mode) > Connections > Advanced Network Settings
I looked down the list for the local IP addresses, then bound Vuze to the lo:0 interface which, in Vuze, is lo[1]
lo (lo)
lo[0] 0:0:0:0:0:0:0:1%1
lo[1] 172.27.72.64
lo[2] 127.0.0.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.
[root@minataur ~]# iptables -A PREROUTING -t nat -i ppp0 -p tcp -m tcp --dport 63255 -j DNAT --to-destination 172.27.72.64
[root@minataur ~]# iptables -A PREROUTING -t nat -i ppp0 -p udp -m udp --dport 63255 -j DNAT --to-destination 172.27.72.64
[root@minataur ~]# iptables-save
Retrying everything with the firewall updated, everything is working 100% :-D
References: man iptables
http://www.linuxhomenetworking.com/w...Using_iptables
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...):
pppd call iPred mtu 1435 mru 1435 persist nolog
echo 1 IPRED >> /etc/iproute2/rt_tables
ip route add default dev ppp0 table IPRED
ip rule add from 172.27.72.64/32 table IPRED
And, if you wanted to just send all traffic over ppp0, this would be:
pppd call iPred mtu 1435 mru 1435 persist nolog
route del default dev eth0
route add default dev ppp0
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
Linear Mode
