Transmission Daemon, OpenVPN and Killswitches

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page 1, 2  Next
Author Message
etalon3141
DD-WRT Novice


Joined: 01 Jun 2019
Posts: 9

PostPosted: Sat Jun 01, 2019 19:15    Post subject: Transmission Daemon, OpenVPN and Killswitches Reply with quote
(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.

Code:
WAN_IF=`nvram get wan_iface`
iptables -I FORWARD -s 192.168.3.100/30 -o $WAN_IF -j REJECT --reject-with icmp-host-prohibited
iptables -I FORWARD -s 192.168.3.100/30 -p tcp -o $WAN_IF -j REJECT --reject-with tcp-reset
iptables -I FORWARD -s 192.168.3.100/30 -p udp -o $WAN_IF -j REJECT --reject-with udp-reset


4) The transmission daemon and its kill switch:

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.
Sponsor
etalon3141
DD-WRT Novice


Joined: 01 Jun 2019
Posts: 9

PostPosted: Sat Jun 01, 2019 19:28    Post subject: Reply with quote
If it helps, screenshot of my networking setup.
https://imgur.com/a/jGRExxB
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Sat Jun 01, 2019 19:41    Post subject: Reply with quote
When any service is running on the router itself, it uses the OUTPUT chain of the filter table, NOT the FORWARD chain, as is the case w/ clients on the LAN behind it. So you need to block on the OUTPUT chain. The trick is determining how to block only transmission and not every other service the router is managing over the WAN, including the VPN itself. If the outbound connection was to a specific public IP + port, that would be easy. Since I'm not all that familiar w/ transmission, that's perhaps were you can solve the problem yourself.

Code:
iptables -I OUTPUT --p <tcp|udp> -o $(nvram get wan_iface) --sport <port> -d <ip-address> --dport <port> -j REJECT


IOW, some combination of these options should be able to uniquely identify that specific traffic. I just don't know which ones you need or will work.

You can do away w/ the additional binding of 192.168.1.99. It doesn't help in this case. And obviously then don't bind transmission to that IP.

_________________
DD-WRT: DNS Leak Detection w/ VPNs (updated 6/5/19)
NEW SCRIPT!: ddwrt-mount-usb-drives.sh
NEW SCRIPT!: ddwrt-blacklist-domains.sh
NEW SCRIPT!: ddwrt-ovpn-remote-access.sh
NEW SCRIPT!: ddwrt-pptp-policy-based-routing.sh
etalon3141
DD-WRT Novice


Joined: 01 Jun 2019
Posts: 9

PostPosted: Sat Jun 01, 2019 21:20    Post subject: Reply with quote
I could kiss you!

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:

Code:
iptables -I OUTPUT -o $(nvram get wan_iface) -s 192.168.1.99 -j REJECT --reject-with icmp-host-prohibited
iptables -I OUTPUT -o $(nvram get wan_iface) -p tcp -s 192.168.1.99 -j REJECT --reject-with tcp-reset
iptables -I OUTPUT -o $(nvram get wan_iface) -p udp -s 192.168.1.99 -j REJECT --reject-with udp-reset


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
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Sat Jun 01, 2019 22:18    Post subject: Reply with quote
Since I'm not familiar w/ transmission specifically, let me use another example to illustrate my point.

Let's say you wanted to force the time service on the router (which uses the well-known destination port of 123) to use the VPN, and NOT the WAN. And you wanted therefore to add a kill switch. The following would do the job.

Code:
iptables -I OUTPUT -o $(nvram get wan_iface) -p udp --dport 123 -j REJECT


IOW, reject all attempts to use the WAN network interface when you see udp packets headed outbound for port 123 (the ntp service port).

When the VPN is up and running and the default gateway points to the VPN, the ntp service will be accessible to the router over the VPN. But when the VPN is down, and the default gateway returns to the WAN, the kill switch will take affect.

What I *think* you were trying to do initially is create a forwarding situation, where you could use a rule like the following to prevent access over the WAN.

Code:
iptables -I FORWARD -o $(nvram get wan_iface) -j REJECT


IOW, if you bound transmission to a local IP, somehow the above rule would take effect. But that's NOT the case!

The fact that transmission is bound to a local IP only means the input network interface is br0, but nothing is ever forwarded from one network interface to another network interface on the same device. It just means you used a different network interface on that device. And regardless which network interface you use, the only relevant chain in the filter table is the OUTPUT chain.

So in weird way, you stumbled into one way of uniquely identifying that specific transmission traffic; by giving it it's own unique source IP. Normally, as in the example above w/ the ntp service and destination port 123, that's not necessary. We can uniquely identify that service based on that destination port.

So the bottomline is, whatever way you can find to uniquely identify that transmission traffic is sufficient. Personally, I think that binding a local IP to the router for these purposes is probably unnecessary, but again, I don't use transmission myself. I don't know if it uses a specific destination IP, destination port, source port, etc. I would assume so, and if so, that should be enough to build the OUTPUT firewall rule without having to resort to binding the service to a unique local IP. But at the end of the day, if all else fails, I suppose if it works, it works!

_________________
DD-WRT: DNS Leak Detection w/ VPNs (updated 6/5/19)
NEW SCRIPT!: ddwrt-mount-usb-drives.sh
NEW SCRIPT!: ddwrt-blacklist-domains.sh
NEW SCRIPT!: ddwrt-ovpn-remote-access.sh
NEW SCRIPT!: ddwrt-pptp-policy-based-routing.sh
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 3988
Location: Netherlands

PostPosted: Sun Jun 02, 2019 6:09    Post subject: Reply with quote
I think the binding is used for the Policy based routing?
_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
etalon3141
DD-WRT Novice


Joined: 01 Jun 2019
Posts: 9

PostPosted: Sun Jun 02, 2019 8:40    Post subject: Reply with quote
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.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Sun Jun 02, 2019 13:35    Post subject: Reply with quote
Sorry guys, I was completely unaware of any ongoing issues you had w/ PBR. I was looking at this problem in complete isolation. My final comment on the issue is that binding transmission to a local IP means you'll have a slight inefficiency due to NAT. If it's bound to the WAN, NAT is eliminated for that service.
_________________
DD-WRT: DNS Leak Detection w/ VPNs (updated 6/5/19)
NEW SCRIPT!: ddwrt-mount-usb-drives.sh
NEW SCRIPT!: ddwrt-blacklist-domains.sh
NEW SCRIPT!: ddwrt-ovpn-remote-access.sh
NEW SCRIPT!: ddwrt-pptp-policy-based-routing.sh
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Sun Jun 02, 2019 14:06    Post subject: Reply with quote
etalon3141 wrote:
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.


You're never going to get the kind of VPN performance from the router that you do w/ the PC.

https://www.snbforums.com/threads/expressvpn-setup-app-vs-manual-configuration-in-asus-routers.46341/#post-482239

For this reason and others, there are just some things better left off the router. Any service offered directly off the router is generally more vulnerable than having that same services managed at least one step removed from the router (i.e., on the LAN). Many ppl place too much blind faith in the belief the router is just as hardened against attack as some device behind it. In most cases, it's more secure to manage your non-routing services behind the router, and leave the router to routing. Of course, this often makes it less convenient. But that's always the debate; how much are you willing to sacrifice in terms of security (and in this case, performance too) for the convenience.

_________________
DD-WRT: DNS Leak Detection w/ VPNs (updated 6/5/19)
NEW SCRIPT!: ddwrt-mount-usb-drives.sh
NEW SCRIPT!: ddwrt-blacklist-domains.sh
NEW SCRIPT!: ddwrt-ovpn-remote-access.sh
NEW SCRIPT!: ddwrt-pptp-policy-based-routing.sh


Last edited by eibgrad on Sun Jun 02, 2019 14:24; edited 1 time in total
etalon3141
DD-WRT Novice


Joined: 01 Jun 2019
Posts: 9

PostPosted: Sun Jun 02, 2019 14:16    Post subject: Reply with quote
It's all good!

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.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Sun Jun 02, 2019 14:26    Post subject: Reply with quote
etalon3141 wrote:
It's all good!

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.


https://pastebin.com/P9nmpyxh

_________________
DD-WRT: DNS Leak Detection w/ VPNs (updated 6/5/19)
NEW SCRIPT!: ddwrt-mount-usb-drives.sh
NEW SCRIPT!: ddwrt-blacklist-domains.sh
NEW SCRIPT!: ddwrt-ovpn-remote-access.sh
NEW SCRIPT!: ddwrt-pptp-policy-based-routing.sh
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 3988
Location: Netherlands

PostPosted: Sun Jun 02, 2019 15:27    Post subject: Reply with quote
for some background see: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=313661&postdays=0&postorder=asc&start=30&sid=92d8fe387a5ed33eb97a3abcbbe51024

Especially look at the last post for Transmission setup

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
SurprisedItWorks
DD-WRT User


Joined: 04 Aug 2018
Posts: 423
Location: Appalachian mountains, USA

PostPosted: Sun Jun 02, 2019 21:39    Post subject: Reply with quote
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...

_________________
Six of the Linksys WRT1900ACSv2 on r38159 (solid), r39144 (very solid), r40009 (solid), and r40784 (trying out). On various:
VLANs, client-mode travel router, two DNSCrypt servers (incl Quad9), multiple VAPs, USB/NAS, QoS, OpenVPN client/PBR (AirVPN and NordVPN).
etalon3141
DD-WRT Novice


Joined: 01 Jun 2019
Posts: 9

PostPosted: Mon Jun 03, 2019 20:24    Post subject: Reply with quote
Hi SurprisedItWorks (good name btw)

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.
etalon3141
DD-WRT Novice


Joined: 01 Jun 2019
Posts: 9

PostPosted: Mon Jun 03, 2019 20:29    Post subject: Reply with quote
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 have attached screenshots showing what I mean. What am I missing? https://imgur.com/a/nLyFtLw

Oh yes, and https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=313661&postdays=0&postorder=asc&start=30&sid=92d8fe387a5ed33eb97a3abcbbe51024 was a thread a found a few days ago, it has been my bible for this.

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

iptables -t nat -I PREROUTING -p tcp --dport 45500 -j DNAT --to 192.168.1.32:45500
iptables -I FORWARD -p tcp -d 192.168.1.32 --dport 45500 -j ACCEPT
Goto page 1, 2  Next Display posts from previous:    Page 1 of 2
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum