Posted: Sat Jun 01, 2019 19:15 Post subject: Transmission Daemon, OpenVPN and Killswitches
(edit: Serious massive thanks in advance, I am way out of my depth here)
Hello, I have been going at this for.. about a day and a half. I will start by explaining what I would like, what I have so far, and how I have done it (I so close I can taste it!)
What I want:
1) Ethernet networking/wifi on the same network so everyone on this can access file shares and the internet, without using the VPN.
2) A guest network accessible by another wifi SSID, again not through the VPN. Isolated from 1)
3) A VPN network accessible by another wifi SSID. Does not need to be linked to my main network 1).If the VPN goes down, this network should lose access to the net.
4) A torrent daemon that runs through the VPN, and if the VPN goes down, it must stop.
What I have so far:
I have sucessfully done 1, 2 and 3. Number 4: The torrent daemon works, but if the VPN goes down it gets around it.
How I did it:
(apologies, this is probably all wrong, but it works, apart from point 4)
1) My normal ethernet and ath1 (well ath0 as well for 5ghz, but lets ignore that). The "main" DHCP on the settings page hands out IPs in the range 192.168.1.100-150
2) is done by making a virtual interface, ath1.1, and setting up a DHCP under the DHCPD settings that serves on this interface, handing out IPs ranging from 192.168.2.100-150
3) As 2), but 192.168.3.100-150. Set up OpenVPN, and I have policy based routing set up that covers the entirety of this IP range.
For a kill switch: this is an example, which is copied and adjusted for the different ranges covered in the PBR table.
This I struggled with for ages. Eventually I stumbled on this solution to get transmission actually working through the VPN:
Set transmission to use the IP 192.168.1.99 (this is not a IP that is covered by anything else, or can be handed out by DCHP, but do notice this isnt an IP in the range of ath1.2, which is my VPN WiFi.) Making transmission attempt to use this IP is done in settings.json.
Code:
"bind-address-ipv4": "192.168.1.99",
Add 192.168.1.99 to policy based routing for openVPN
Code:
192.168.1.96/30
And the key to making it work, and what I suspect is messing up the kill switch: To allow transmission to actually connect to anything, I had to do put this in my startup commands:
Code:
ip addr add 192.168.1.99 dev br0
Without this, it would not ever connect to anything.
The problem is: Whatever form of kill switch I try to stop 192.168.1.99 from accessing the internet when the VPN is down, it bypasses it!
Sad times, sorry for the wall of text.
I can add more detail as required, I am very set on making this work! I might edit this post for clarity later on.
Right, well, you said I could do away with the binding of 192.168.1.99, I left that in and used that to define the source port of the outgoing connection (I think). Is there an advantage of removing this binding?
I really dont understand this iptables stuff, but what I added to the killswitch is:
And that seems to work, but it does seem reliant on the binding mentioned above.
Please let me know if I have done something really stupid here, I must admit I am basically doing this monkey at a typewriter style (ie try 1000 things until by sheer luck one of them works)
eibgrad: I totally see what you mean, and if it wasnt for my way of using policy based routing on the VPN I could see that working.
As EGC mentions, it is used for PBR and although I feel like PBR isnt the way to do things (see my note below), well it seems to work.
Anyway, it works so far, and thank you so much for your help.
The last piece of the puzzle is port forwarding / proxy servers. I seem to get better performance running a torrent client with uPNP on my PC and using NordVPNs VPN software compared to what I am getting with the transmission daemon, so that is my next task.
(Note: I sort of envisioned the VPN being its own interface, and then assigning certain IPs or virtual interfaces to use the VPN as the interface, IE: everything on the 192.168.3.xx range only can get access through the VPN interface)
Final note: My VPN wifi network seems to have broken at some point during all this, but I am assuming its a simple fix once i start looking at it.
So far this morning, in order to get port forwarding working, I am trying out PIA as a VPN rather than nord and fighting my way through their API for port forwarding, which I have partially cracked, albeit manually so far. I managed to get a port, and then some more iptables based port forwarding, which again I have stumbled on some sort of solution possibly.
I will test it properly later, then post the weird forwarding rules here if that is ok so people more knowledgeable that I can tell if it's a security risk or not.
Then, if it's wanted, I can post a step by step guide assuming zero knowledge to where I got to. I know I could have done with it from the start.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Sun Jun 02, 2019 21:39 Post subject:
Hi etalon3141.
Random suggestion, just to simplify (I've also seen either eibgrad or egc suggest something similar): For DHCP servers, use Start 128, Max 64. Then PBR for subnet 1, for example, would be the one line 192.168.1.128/26. Further, I assign static leases in the range 96-127 so that I can add one more PBR line to cover those: 192.168.1.96/27. Of course you could avoid even that second line if you obtained space for N static leases beginning at 128 by adjusting the DHCP Start up by N and the Max down by N.
Cheers... _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Good shout, I have done that. Makes my firewall rules much nicer. I finally go around to finding out what CIDR addresses actually are, so yeah that was worth it.
I tried eibgrad's script, but... no matter what I do, I am getting some weirdness with just running it. It refuses to think the file exists for me to execute it.
The file *is* there, I can vi edit it too, but it refuses to think it exists for the purposes of execution.
I managed to get request the ports from PIA manually using this as a guide which I was quite pleased with.
edit: I am temporarily manually setting these rules which seem to work to bring the port forwarded through PIA to the torrent client, unproven, but seem to be OK. I cant see anything about them which is a security issue
Another common problem is ppl who create the file on a Windows machine, then upload it to the router. The problem is that Windows and Linux editors use different EOL chars. And Linux can NOT read Windows files. It will just report not found.
You should always use a Linux compatible editor before uploading (e.g., notepad ++), and make sure the current format in the editor is Linux.
The telltale sign of this problem is when you dump the file, it's double spaced.
Verified the issue by checking the file with vi. Serves me right for shortcutting instructions. Will get the file on a different way and check it again.
To be fair, a file format error is not something I have ever come across when dealing with what appears to be plain text files, so there was little reason for me to think the error was anything to do with the editing process. Live and learn though.