Using VMs for Routing VPNs and Tor: Playing with Virtual Networks

I will keep this post relatively brief. Following the steps in my first two installments (-http://bit.ly/waziYl and -http://bit.ly/xzkD6u), you may have a VirtualBox host and three VMs: (1) a pfSense VM that connects to OpenVPN's PrivateTunnel service ("PrivateTunnel gateway"); (2) a Tor gateway VM from Ra ("Tor gateway"); and (3) an Ubuntu desktop VM for testing your gateway VMs ("Ubuntu").

The PrivateTunnel gateway VM has two network interfaces, WAN and LAN. You can attach the WAN interface to whatever you like. Typically, you would NAT WAN to the host, or attach it to an internal network that's attached to the LAN interface of another gateway VM.

pfSense runs DHCP server for the LAN interface, and routes it through the OpenVPN tunnel (which connects through WAN). You can attach the LAN interface to whatever you like. Typically, you would attach LAN to an internal network (such as "pfsense") that's attached to the WAN interface of another VM (either a desktop VM or another gateway VM). You could also bridge LAN to a free network interface on the host, and connect other computers.

Similarly, the Tor gateway VM has two network interfaces, WAN and LAN ("tor"). It runs OpenWRT. What I've written above about the PrivateTunnel gateway VM also applies to the Tor gateway VM (except that it routes LAN through Tor). Although the internal network "tor" will route everything, only TCP traffic will be routed through Tor. The rest will be dropped.

The Ubuntu desktop VM has just one network interface. You would typically NAT it to the host, or attach it to one of your internal networks. I don't recommend mixing different identities and network connectivities on a given desktop VM, especially if it's a Windows VM. However, it's OK to use the same desktop VM for testing purposes, as long as you don't compromise your identity through email, posting, chatting or whatever. If you're paranoid, you can use a LiveCD VM.

Start all three VMs. If you don't want anyone to know that you're using Tor, attach the Tor gateway VM's WAN interface ("Adapter_1") to the PrivateTunnel gateway VM's LAN internal network ("pfsense") before starting the Tor gateway VM.

First, NAT "Adapter_1" of your Ubuntu desktop VM to the host, using "Devices | Network Adapters..." in the top VirtualBox menu. Open Firefox, and check your IP address. Second, attach "Adapter_1" to the internal network "pfsense", and check your IP address again. Third, attach "Adapter_1" to the internal network "tor", and check your IP address yet again. You should get a different IP address for each.

Now create another pfSense VM that connects to a different VPN service, and play with other possible combinations. Enjoy

 

So please explain various ways we can create our layers, like how Tor routed everything, or as I mentioned I ran VPN then Tor through it...

How can we do all this with these 3 VMs, pfsense, ran tor and your guest?

So all I can get out of this for the moment is;

1. Start pfsense
2. Start RA Tor with adapter internet pfsense
3. Start guest with adapter internal pfsense

But with steps 1-3 as you suggested this is the Tor going through the VPN not the VPN going through Tor which is what you said before that you liked doing...

I'd also like to think it's possible to run the VPN on the host and then have the guest pick that up, of course this can happen with nat, so can two adapters on the guest work, nat and pfsense, routing through the vpn on the host and next through pfsense?


THANKS

 

To get VPN2 through Tor through VPN1:

1) run VPN1 on host
2) run Ra's Tor gateway VM with its WAN NATed to host
3) run pfSense VM with its WAN connected to internal network "tor"
4) run workstation VM connected to internal network "pfsense"

To just get VPN2 through VPN1:

1) run VPN1 on host
3) run pfSense VM with its WAN NATed to host
4) run workstation VM connected to internal network "pfsense"

And so on.

I prefer to run VPN1 on another pfSense VM, rather than on the host. That way, the VPN is seriously firewalled. But iptables is probably just as good (more complicated to set up, though).

 

The reason I said what I did, was you originally started out saying you were going to show how to route through Tor then you ended with routing through VPN hehe, so I was wondering when you were going to bring it up...

What you've shown now I thought was suppose to be everything routed through Tor, which is what I thought you liked. So starting VPN on host first, is still Tor going through the VPN as the starting point, not VPN through Tor.

So it looks like this is what we have now;

VPN Tor VPN= Tor going through VPN, then VPN going through Tor...

With pfSense, what difference is it going to make where it sits in the chain, also long as it's there somewhere? By the first example with Ra, starting pfsense number 3, isn't that putting pfsense ahead of the host's iptables as the first line of defense, which seems like a better place to be, then at the back of the chain as first?

Darn Ra Tor crashed on me and booted me off the desktop into the console and locked the box up, because I thought there was no means of shutdown, which in Linux is typically 'shutdown', so I've just been closing the window and letting VB shut it down, bad move. Now I see after digging around in /usr/sbin there's 'poweroff'. Guess it's time to start running that, LOL...

 

Well, that was what I asked about. And showing how I did it led to all that explanation. But in truth, I don't use Tor very much, because it's too slow. Also, it seems that forcing a VPN to connect through Tor leaves neither very happy It just won't work for some VPNs, presumably because their setups can't accommodate Tor's latency etc.

I never connect Tor directly. I don't want that attention. I'm just another VPN user. Move along, nothing to see here

Yes, that's it.

Actually, I run the "outer" VPN on another pfSense VM, rather than on the host. Also, there are actually two outer nested VPNs. So, altogether there are three VPNs and Tor.

I've found that Ra's Tor VM is generally OK with being killed by VirtualBox. However, especially if you've modified it by installing packages or whatever, doing that will corrupt the ext2 filesystem. But I've found that just halting it before killing the VM is enough.

PS -- A friend and I have just managed much of this (but not the Tor part) with VirtualBox on a remote server, using command line VBoxManage and VBoxHeadless. I'll post another topic soon.

 

Ahhhh all this time I thought you were the Tor junkie giving us the ultimate in Tor routing, LOL...

Ok so are you using Tor at all, then when you do it, you do it as you shown in the first example VPN Tor VPN?

As I mentioned Ra Tor has, well OpenWRT actually, 'poweroff', so I'll just run that now...

I understand that you run the "outer" VPN on another pfSense VM. But what I'd like to know is if it really matters where in the chain of things, how I'm doing it by your example above, if it really matters the placement?

I'd imagine since I have iptables on the host and guest sitting behind a router, this would be the order of things based on running the example above VPN Tor VPN; ---> (1st)Router;(2nd)iptables;(3rd)pfsense;(4th)iptables

 

Pretty much, I only use Tor for .onion sites, and I connect using Ra's Tor gateway, which connects via two nested VPNs. I just did the TCP VPN through Tor thing to see if it would work, because I thought that it should. Maybe some time it will be useful to know that.

OK. Maybe I will too

Basically, these are just virtual routers that you can connect in whatever order you like. Right now, I have six pfSense VMs and three Ubuntu VMs running on this host.

I'm not sure that I understand that. Is this what you mean?

(1st)Router; [physical, between modem and host machine]

(2nd)iptables; [on host machine]

(3rd)pfsense; [VM on host machine]

(4th)iptables [on workstation VM]
​

I don't see Tor in that

 

(3rd) pfsense is connecting to Tor

Ok I'm not to sure here, if I do everything through UDP on VPNs with pfsense connectivity is just fine sitting behind the router, iptables on both host and guest and running pfsense, but if I use TCP for a VPN connection that I have on pfsense, I connect to the VPN ok, but then I can't ping an IP or domain name... I just assumed if UDP worked I wouldn't need to change anything around to allow TCP traffic?


THANKS

 

OK, is this what you mean?

(1st)Router; [physical, between modem and host machine]

(2nd)iptables; [on host machine]

(2.1nd) Tor VM [VM on host machine]

(3rd)pfsense; [VM on host machine]

(4th)iptables [on workstation VM]
​

Maybe you have UDP-specific rules in iptables?

 

Yep that's what I mean for my routing and firewalls...

My bad I have to use the TCP VPN like a proxy and place it in the apps I want to use, so I guess I can configure it into pfsense, or directly to the app...

So does it really matter where pfsense sits in the scheme of things?

I guess it would be nice to somehow be the main router at the front of the chain, replacing my Netgear, but at this point in time that's not going to happen anytime soon...

So the order from the modem;

Netgear
iptables
pfsense
iptables

Sorta got a sandwich going on here, LOL...

 

I'm not sure what you mean. The pfSense VMs are just virtual routers. So are Ra's Tor gateway VMs. You can use them in VirtualBox just like you can use real routers.

 

I'm talking about the firewall aspect of pfsense, where it sits in that chain/order I have, if it really matters?

Well I know it matters, but as I said I can't change out the Netgear for now and actually have a pfsense hardware router taking it's place, but one day I'd like that...

By the way I feel like we're the only two around here, the mirimir and DasFox show, LOL...

Sheesh people get on here and say THANKS to mirimir for all his fine efforts for teaching you something GREAT!

My gosh man where all all the geeks out around this place?

By the way kiddies you can use VirtualBox in Windows to do all this, this isn't just for the Unix/Linux gurus.


THANKS mirimir

 

I don't think that it matters very much. Any NAT router is a basic firewall. With any VPN service, there's NAT between you and the Internet. Although the pfSense VMs are acting as firewalls, they're mostly just serving as extremely-persistent OpenVPN clients. Once you get the client configured properly, you can start it and forget. It just keeps trying until it connects. And when it's not connected, nothing gets through.

I am far from being any sort of guru. That is what's so cool about pfSense.

Please I'm glad to have taken the time to review all that.

 

For all the people I have read posts over how to protect against a VPN drop, using pfSense certainly takes care of that...

What are you giving the huh look for --> I mean look around, we're the only two on all three posts with hundreds of views, LOL...

Well if we're not gurus we are certainly geeks, LOL...

THANKS again...

 

mirmir can you post your lan&wan(bs these) ips, netmask and gateways for each vm you have in this structure?

ie
VM Box NAME
LAN IP & netmask
WAN IP (gateway, probably set via dhcp)
for each vm

curious if all your vms are on the same subnet etc

 

Here's the setup for two nested VPNs:

pfSense20x64VPN1
...em0 (WAN) [NAT to host (DHCP from VirtualBox)]
......inet 10.0.2.15
......netmask 255.255.255.0
......broadcast 10.0.2.255
...em1 (LAN) [attached to internal network pfs1]
......inet 192.168.1.1
......netmask 255.255.255.0
......broadcast 192.168.1.255
...ovpnc1
......inet 10.5.8.14 --> 10.5.8.13
......netmask 255.255.255.255

pfSense20x64VPN2
...em0 (WAN) [attached to pfs1 (DHCP from pfSense20x64VPN1)]
......inet 192.168.1.101
......netmask 255.255.255.0
......broadcast 192.168.1.255
...em1 (LAN) [attached to internal network pfs2]
......inet 192.168.2.1
......netmask 255.255.255.0
......broadcast 192.168.2.255
...ovpnc2 [there's a ovpnc1 that I'm not using currently]
......inet 10.17.0.6 --> 10.17.0.5
......netmask 255.255.255.255

U1010Dx86VPN12
...eth0 (LAN) [attached to pfs2 (DHCP from pfSense20x64VPN2)]
......inet 192.168.2.101
......netmask 255.255.255.0
......broadcast 192.168.2.255

 

Awesome!

I've got my bcast ips a little screwed up, where do you change those in pfsense?

This is vpn "node 1" pre se
em0 WAN 192.168.0.212 (set by DHCP on the standalone pfsense box who is 192.168.0.50) bcast 192.168.255.255
em1 LAN 10.10.0.50 bcast 10.10.255.255

I think the bcast on both pfsense boxes should be changed to match your config

If your DNS test shows your ISP DNS servers instead of your VPN's:
found out something here too.
You HAVE to connect the wintendo boxes (win vm guests) (haven't tried w anything else yet) via DHCP to "vpn node1"

Initially I used a static ip w DNS set to the node1 box ip 10.10.0.50
DNS tests FAILED and showed my isp dns (they showed moderate spoofability which is terrible bc they are a major isp)

After switching to DHCP then my dns while still showing 10.10.0.50 w ipconfig PASSED the dns test and showed none of my isp dns servers and all got excellent marks.

That's very interesting to know about pfsense and giant potential security issue depending on how you look at it. Statically set ips will default to the pfsense WAN dns which is set by the "real" pfsense box routing all my traffic to my isp and not the openvpn link so you have to use the node1 dhcp server to get ips. That makes sense because the VPN dns is only specified in DHCP server settings, so it operates as it should, but you can screw this up if not careful.

WAN dns settings takes prescience over OpenVPN even if your nat rules route all local traffic to the OpenVPN link IF you use static ips.

Definitely something to check if your DNS test fail.

Big thank you on this thread, everything worked first try w/o any problems.

How to troubleshoot VPN Client settings are setup correct, if they're not, how to get the right ones:
Here's another tip to make sure the openVPN client section is filled out correctly for your VPN provider. If you check off some boxes (or forget to check some) your OpenVPN log in Diag->system logs-> openvpn will show you warnings indicating what the server is expecting (ie config you should have) versus what you have checked off:

Jan 16 00:17:05 openvpn[46779]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Jan 16 00:17:05 openvpn[46779]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541', remote='link-mtu 1542'

In the above my VPN wanted lzo compression enabled but it was unchecked on my end. After checking the box, no more warning all is well, even took care of the MTU size error too

Why your fancy firewall software is USELESS when using VPN's:
Just checking the firewall logs, looks like im getting port scanned up the ying yang through this VPN lol so that means each on of these VPN nodes should be also running snort for IDS especially if wintendo is sitting behind it. Thats good to know too, even if your regular internet connection is firewalled, your vpn connection basically bypasses that and leaves you wide open to attack

That means that while your communication is encrypted, your machine is wide open to "burglars". So a best practice for any VPN user would be setup a vpn router like mirmir outlined and have that fire walled appropriately. This basically flies in the face of what most VPN providers want (or allow in their TOS) as you are essentially NATing your VPN and can connect X^n machines all using the same vpn. My VPN has no issues with this but buyer beware.

box has been up for just under 2 hrs and already 1524 blocks by the firewall.

Had we not ran this little experiment we would never have found out this giant trade off with using a VPN provider.
On the one hand, your communication is encrypted
On the other hand, your firewalls are totally bypassed unless you set everything up like we did in this thread.

Best practices to make sure your vpn connection is working properly before you start screwing around on the internet:
couple of things that are good habbit when using vpns in general: before you connect to anything from behind the vpn pf boxes,
1: run "tcpdump src PF_VPN_WAN_IP or dst PF_VPN_WAN_IP" from the console (or ssh in) of your pf box that connects directly to your ISP. you're looking for https to show up. You'll see a bunch of ICMP traffic from the local lan wich you can ignore with "tcpdump src PF_VPN_WAN_IP or dst PF_VPN_WAN_IP and not icmp". If you are super paranoid you can stream this all day long on a terminal near to you keep your eye on it
2: check to make sure your ip is that in which the vpn assigns, not your isps
3: run that DNS checker link posted by op http://grc.com/dns from this thread (thought i was posting in that one, guess not) https://www.wilderssecurity.com/showthread.php?t=315826

also im assuming (have to verify) that this setup has by default bound all your ips to boxes behind the pf vpn route such that if the vpn goes down you wont have any internet connection from them

Misc:
Next project..... load balancing all these VPNs
most VPN providers have X^n servers you can connect to of various reliability and speed..... wouldnt it be nice to automatically route to another server if needed har har har har

quick search revealed this http://forum.pfsense.org/index.php/topic,24436.msg126273.html will dig into when im more awake/have time.

Also i'll make iso's of Install Ra's Tor Gateway so you're not forced to use virtual box.... bc im not using virtual box =P Why that guy only released vms is beyond me.

Also want to screw around w HFSCing this pfVPN box on the real pf box -> isp

 

I don't see how to edit broadcast in the webconfigurator. You might need to reset interface IPs using the console.

Yes, management of DNS servers in pfSense can get very complicated, especially when you add VPN routing. There are some VPNs that I can only get to work by turning off DNS Forwarder, and specifying public DNS servers in the DHCP Server setup.

I probably didn't stress enough the wisdom of specifying public DNS servers in your perimeter router/firewall. That way, if DNS isn't getting handled correctly in your pfSense VMs, you won't leak anything crucial.

Oops. I forgot to mention that. I just added a note.

Some of that may be keep-alive pings from the OpenVPN server. It's not a problem for Ubuntu VMs, because they don't have any open ports (unless you install services that open them). Also, I'd be surprised if OpenVPN providers allow client-client connectivity through the VPN.

Yes, when a VPN is down, there's no connectivity that pfSense VM's LAN.

Using straight OpenVPN, you can specify multiple remote servers. Being limited to one is a limitation of the OpenVPN GUI. I've tried having multiple active OpenVPN connections in pfSense, and couldn't get it to work. However, you can add another pfSense VM that load balances connections from multiple VPN-connecting pfSense VMs.

Cool! Thats very interesting. Thanks.

 

another option worth looking into is on the pfvpn box to deny unknown clients from the DHCP Server section and explicitly allow whatever boxes you want connecting to it by MAC address.

had a situation where 1/2 my lan was getting assigned to the 10.10.x.x network vs the 192.168.x.x bc the wan on the pfvpn box is set to be part of the 192.168.x.x network.

 

OK these are simplified steps that I can conceptually follow. Please adjust them to include VPN1 being firewalled so I could recreate this confidentally.

 

Edit: I've added another Ununtu VM to administer pfSense VM1. The VirtualBox internal networks (pfsense1, tor and pfsense2) are mutually inaccessible, so you can't see the pfSense VM1 webconfigurator from pfsense2 (or vice versa).

To get VPN2 through Tor through VPN1:

1) run pfSense VM1
.....WAN NATed to host
.....LAN connected to internal network pfsense1
.....OpenVPN client for VPN1, routing through pfsense1
1.1) run workstation VM
.....WAN connected to internal network pfsense1 (for webconfigurator)
2) run Ra's Tor gateway VM
.....WAN connected to internal network pfsense1
.....LAN connected to internal network tor
.....Tor routed through tor
3) run pfSense VM2
.....WAN connected to internal network tor
.....LAN connected to internal network pfsense2
.....OpenVPN client for VPN2 in TCP mode, routing through pfsense2
4) run workstation VM
.....WAN connected to internal network pfsense2

To just get VPN2 through VPN1:

1) run pfSense VM1
.....WAN NATed to host
.....LAN connected to internal network pfsense1
.....OpenVPN client for VPN1, routing through pfsense1
1.1) run workstation VM
.....WAN connected to internal network pfsense1 (for webconfigurator)
2) run pfSense VM2
.....WAN connected to internal network pfsense1
.....LAN connected to internal network pfsense2
.....OpenVPN client for VPN2, routing through pfsense2
3) run workstation VM
.....WAN connected to internal network pfsense2

 

You've been very helpful so far thanks. I just have a few more conceptual questions in the case I would try an altered setup.
Lets say you have one vpn client installed on your guest system. And the tor gateway is setup to intercept all traffic, does this make you anonymous to the vpn - therefore adding an extra layer of anonymity?

Another question:
Would the guest be safe from any potential vpn client to client attacks with this setup below or is it only if the firewall is used as a gateway that you're ok?

Guest os + openvpn client installed > pfsense> Tor gateway

 

Also another thing, is this setup designed for diversion of the host traffic thorugh these mechanisms or is it used exclusively for anonymizing a specific guest vm traffic?

 

I'm not entirely sure which setup you're referring to. If you're connecting to a VPN server through Tor, you're anonymous to the VPN provider. If you're connecting to Tor through a VPN, the VPN provider knows who you are (unless you're using anonymous WiFi).

That would work too. In that case, you're using the pfSense VM only as a firewall, which is something that it does well. But you'd also need another VM, a workstation VM connected to the Tor gateway, in order to use the setup.

 

It's designed for the latter. One can tweak it to bridge the host network interface to the first VM in the routing chain, and then connect the last VM in the chain as host-only adapter. But I don't recommend that, because then you're doing your anonymous work on the host. I like to "firewall" each sort of work in its own VM.