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.
Add 192.168.1.99 to policy based routing for openVPN
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:
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:
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: 1057 Location: Appalachian mountains, USA
Posted: Sun Jun 02, 2019 21:39 Post subject:
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... _________________ Five WRT1900ACSv2's on 42926, 44048.
VLANs, VAPs, NAS, client-mode travel router, OpenVPN client (AirVPN), DDNS, wireguard servers, wireguard clients (AzireVPN), two DNSCrypt DNS providers (incl Quad9) via OpenVPN/wireguard clients.
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.