RPi2 with OMV, OpenVPN and Transmission firewall settings.

  • Learnt a lot and finally have OMV, OpenVPN and Transmission working correctly together on a Raspberry Pi2.
    The main requirement was to block Transmission if the VPN disconnected.


    Just hoping someone would be so kind as to check my Firewall settings. I am using the OMV Firewall gui but I've shown them here as iptables for ease of display.


    Code
    iptables -A INPUT -m conntrack --ctstate ESTABLISHED -i tun0 -j ACCEPT
    iptables -A INPUT -p tcp --dport 51413 -i tun0 -j ACCEPT
    iptables -A INPUT -p udp --dport 51413 -i tun0 -j ACCEPT
    iptables -A INPUT -i tun0 -j REJECT
    iptables -A OUTPUT -d 192.168.0.0/24 -p tcp --sport 9091 -m owner --gid-owner debian-transmission -o eth0 -j ACCEPT
    iptables -A OUTPUT -d 192.168.0.0/24 -p udp --sport 9091 -m owner --gid-owner debian-transmission -o eth0 -j ACCEPT
    iptables -A OUTPUT -m owner --gid-owner debian-transmission -o tun0 -j ACCEPT
    iptables -A OUTPUT -m owner --gid-owner debian-transmission -o lo -j ACCEPT
    iptables -A OUTPUT -m owner --gid-owner debian-transmission -j REJECT
    iptables -A OUTPUT -s 192.168.0.0/24 -o tun0 -j REJECT


    Is that all I need?


    Thanks for your help.

  • Some time ago i did some research, and i spent like a month testing with deluge and ipvanish. This is what it came out

    https://github.com/subzero79/O…b/master/selective-vpn.sh


    This is based linux routing policy i guess an alternate approach of what you're trying


    Two things:
    1) looks alright if you're binding to the tun interface. About binding i am not sure if this works, neither with transmission or deluge, always gave me the impression that it didn't work very well. But if you fire iftop and see the tun iface trafficking i guess is working.


    2) The peer port rule seems unnecessary IMO and rule #9 could be MAYBE iptables -A OUTPUT -m owner --gid-owner debian-transmission ! -o tun0 -j REJECT


    The last rule #10 was the purpose to avoid lan clients using the VPN?

  • Thank you for the info and help. It is going to take me a while to understand your solution as Linux is a bit new to me.


    When you say "The peer port rule seems unnecessary....." are you referring to rules #2 and #3?


    I'm not sure I understand your suggestion for rule #9 fully. I'm thinking they both achieve the same thing? I'll go back and read the debian man pages for iptables to try and understand what that "!" does


    I'm not binding to the tun0 interface but I have been using netstat -an and iftop to view traffic and it appears to be working ok...... That is -
    If I look at eth0, I only see traffic to and from my Network to the VPN and other local network traffic.
    If I look at tun0, I only see upside VPN traffic and No local traffic.


    If I stop OpenVPN there is no unusual traffic on eth0 and of course there is no tun0 interface.


    Yes with rule #10 the intention was to block any chance of local network traffic using the VPN. I only use the VPN for transmission. I usually stop both the openvpn and transmission-daemon services as I'm not using the VPN and transmission 24/7.


    Yes, I have been reading about the up/down scripts and will use them once I understand how to :-)


    So much to learn........

  • 2) The peer port rule seems unnecessary IMO and rule #9 could be MAYBE iptables -A OUTPUT -m owner --gid-owner debian-transmission ! -o tun0 -j REJECT


    I've deleted rules #2 and #3. Not sure now, why I thought I needed them but as you say and looking back at my notes they aren't needed as they don't do anything because of rule #1.


    Oh ok the "!" inverts the test of the argument so "! -o tun0" means all other interfaces accept tun0
    so rule #9 iptables -A OUTPUT -m owner --gid-owner debian-transmission ! -o tun0 -j REJECT - means reject all outbound debian-transmission traffic unless it is on tun0


    but isn't that the same as
    rule #7 iptables -A OUTPUT -m owner --gid-owner debian-transmission -o tun0 -j ACCEPT - Accept all outbound debian-transmission traffic on tun0
    rule #9 iptables -A OUTPUT -m owner --gid-owner debian-transmission -j REJECT - Reject all outbound debian-transmission traffic on any interface


    my thinking is because of rule#7 debian-transmission tun0 traffic should never get to rule #9 right? or am I missing something? ;-)


    Thanks again :-)

  • If you're not binding, then i am guessing your vpn provider is replacing your default gateway, thus all traffic is being forwarded through the VPN. My guess is all traffic then should be denied from interfaces different to tun0 for transmission, this to avoid that when the vpn goes down transmission downloads or seeds from eth0. Then the set of rules could be more simpler.


    IMO opinion this is incorrect, are you gonna download debian updates and other stuff through the VPN?
    If not then you should consider maybe the option of a secondary routing table for traffic generated by transmission, like the one i put from github.


    But if that works for you i guess is ok. You can perform tests killing the openvpn and watch with iftop that no traffic goes out from transmission

  • Thanks for all your help with this.


    DHT hasn't been working and I just realised that is what rules 2 & 3 were needed for. I think DHT only uses udp but I'm still researching that.

    Code
    iptables -A INPUT -p tcp --dport 51413 -i tun0 -j ACCEPT
    iptables -A INPUT -p udp --dport 51413 -i tun0 -j ACCEPT
  • This was getting a bit hard for me to understand so to take a break I have started a new installation on the Raspberry pi2 using your script.


    So far -
    I've installed openvpn.
    Copied and saved the .conf (from my vpn, ipredator), the .auth and firewall.sh (your script) file
    Installed and configured transmission in OMV
    ipredator required lines 34,35 & 37 to be added to the .conf and I also put the firewall.sh into the file at line 36
    There is a problem with openvpn and TLS in the .conf so I have to comment out line 40 "tls-version-min 1.2" in the file.



    To test the setup I uploaded the torrent IP test file "checkMyTorrentIp.png.torrent" to transmission and it gave me the correct vpn IP.


    The problem came when I stopped the openvpn service, everything that was on tun0 just continued on eth0 and my real IP was exposed.


    Obviously something is wrong (I just can't see it) so your help to sort out my mess would be greatly appreciated.


  • It looks like it is all going through tun0 (output of iftop) I started an Update Check in OMV


  • I think i have some error in one of the vars at the end. Don't execute the script inside openvpn yet (up)


    This line at the end "ip rule add from all fwmark 0x1 lookup $VPNUSER" (VPNUSER should be VPNTABLE)


    After you fire openvpn in terminal say (openvpn file.conf) in another terminal execute the script like ./firewall.sh to check any errors that might come up.

  • If I execute the script outside openvpn (up) it now gives this


    Code
    Error: argument "vpn" is wrong: invalid table ID
    Error: argument "vpn" is wrong: table id value is invalid
    Error: argument "vpn" is wrong: "table" value is invalid
    Error: argument "vpn" is wrong: "table" value is invalid
  • A quick test with a free vpn provider (says it allows p2p, but i am sure is blocked so i can't tell well) is somehow working for me. Remember i tested this with ipvanish by the time.


    You can give a temporal bash login to debian-transmission at /etc/passwd


    debian-transmission:x:111:114::/home/debian-transmission:/bin/bash


    Then access as user su debian-transmission and do curl -s echoip.com, that shoud spit the openvpn server public ip


    then run again curl as root should give your public ip address. If you cut the vpn, then pinging as debian-transmssion won't pass

  • Did you added the table as mentioned in github?


    echo 200 vpn >> /etc/iproute2/rt_tables


    Oh how embarrassing........... I just didn't miss that but missed the whole README.md.


    I have now done those changes and the errors have gone but unfortunately there doesn't seem to be a gateway for the vpn


    Code
    ip route show
    default via 192.168.0.200 dev eth0
    192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.12
  • Code
    # ip r s t vpn
    default via 127.0.0.1 dev lo
    # ip route show
    default via 192.168.0.200 dev eth0
    46.246.44.0/24 dev tun0 proto kernel scope link src 46.246.44.90
    192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.12


    Still can't download any torrents :-( just won't connect and there is no activity on tun0 using iftop -i tun0

  • Code
    # ifconfig tun0
    tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
    inet addr:46.246.41.60 P-t-P:46.246.41.60 Mask:255.255.255.0
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)


    Code
    # ip r s t vpn
    default via 46.246.61.237 dev tun0
    default via 127.0.0.1 dev lo
    # ip route show
    default via 192.168.0.200 dev eth0
    46.246.61.0/24 dev tun0 proto kernel scope link src 46.246.61.237
    192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.12

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!