OpenVPN Kill Switch (LAN Only - Access Point Mode)

Discussion in 'Tomato Firmware' started by GraemeG, Jan 6, 2019.

  1. GraemeG

    GraemeG New Member Member

    Hi
    I have spent a while searching the net looking for an answer to the following, but I'm beginning to think I'll be forced to use the WAN port, but here goes..

    Let's say you have a fritzbox router/PBX and you decide to add a 2nd router running tomato (running OpenVPN, but no DHCP) and hook it up via the LAN ports (with the 2nd router on the same subnet, using the fritzbox router as its gateway) is it possible to kill all the traffic to the default gateway (the fritzbox) should the OpenVPN fail?

    I've seen many iptables examples and none of them seem to achieve this..

    Is it technically possible to block all traffic, outside the current subnet (as I need access to both the 2nd router and any client PC using the 2nd router as its gateway) when the VPN fails..?

    I appreciate this is easy via the WAN port, but I'm a little stumped at the moment..

    I did consider changing the gateway to an invalid IP on the 2nd router AFTER the VPN had connected, but unfortunately tomato restarts the VPN following any network changes (and therefore fails to locate the external VPN server)..

    Any ideas would be most welcome :)

    Regards
     
  2. rs232

    rs232 Network Guru Member

    If I "guessed" well the question yes this is possible not hugely difficult but yes it does equires few bits of config.

    Before going into that:
    - why are you not willing to use the wan port of tomato?
    - do existing clients have to use the fritxbox DHCP necessarily?

    P.S. I suggest you edit your OP to make it more meaningful. e.g. it is a clever question but needs to be rephrased and detailed.
     
  3. GraemeG

    GraemeG New Member Member

    Hi
    Basically, the main 192.168.0/24 subnet is my main network/gateway, it allows all clients to communicate with each other on the LAN and other devices connect to the PBX (telephone) system & NAS running on the Fritzbox. It also enables VNC access to local clients from remote locations over the fritz's VPN.

    I needed to place one (maybe more) clients on an 3rd party VPN and decided to add a secondary gateway by means of a 2nd router (192.168.0.2) running tomato with its DHCP disabled, using a gateway of 192.168.0.1 (fritzbox).
    [I only use DHCP for WLAN clients, everything else is static]

    This means I can simply switch clients between either gateway.

    All I need to do is prevent all non LAN traffic (except traffic to the VPN over UDP 443) from leaving the default gateway (192.168.0.1) of the tomato router (acting more like a managed switch) when the VPN tunnel (tun11) is down.

    Removing the default gateway is not an option as it resets the VPN connection..

    Does that help?

    Regards
     
  4. rs232

    rs232 Network Guru Member

    I'm really sorry but your second post is even more confusing that the first one (I'm sure it's me).

    - What is the Fritz VPN??
    - Do you have a network diagram?

    Also my previous questions were not answered...
     
  5. GraemeG

    GraemeG New Member Member

    :)
    I know what you mean (I'm a s/w engineer), it's always easier in your own head :D

    ok, The Fritzbox is the main router (192.168.0.1), it also provides VPN access to the LAN via the VDSL (fibre) WAN connection.

    The Fritz also handles my PBX phone system (DECT) and provides a music store for various devices (PCs, SONOS etc) on the LAN (this is the NAS feature).

    Anyways, none of this matters really as the Fritz is not specifically relevant to this configuration.

    I have added a tomato router (192.168.0.2), acting as a managed switch with an OpenVPN client in operation.

    It is merely another client on the main LAN.

    The only difference is, it has an OpenVPN tunnel configured so it can act as a gateway to other clients on the LAN.

    99% of the clients on the LAN are using the Fritz as a gateway as it's the fibre internet router.

    I only wanted 1 LAN subnet (192.168.0.0/24) as all the devices must be able to communicate with each other, with some of them now using the tomato router as their gateway (so they use the OpenVPN tunnel for traffic outside the local subnet).

    All I need to do is configure the tomato router so that it either drops all traffic outside the local subnet when the VPN tunnel (tun11) is down, or force all external traffic to tun11, while allowing local traffic to function..

    I appreciate I could use the WAN port and have the tomato router use a LAN IP of 192.168.2.0/24 and configure a routing path on either router to allow access between both subnets, but as I have clients historically configured with drive maps and shares etc (based on IP, rather than hostnames) it was easier to add the second gateway on the same subnet..

    The other plan I had, considering the tomato router is actually located on a different floor to the Fritz, was to configure the 5G WiFi to act as an access point to the main (non OpenVPN) connection to extend the limited performance of the Fritz's 5G WiFi.
    Clients would be able to join the 5G WiFi, hosted by the tomato router, and be issued an IP from the Fritzbox which would use the primary gateway. (but that's a job for later).

    Any better :)
     
  6. rs232

    rs232 Network Guru Member

    ok this is better.

    Even without the Fritz implication this is a technically challenging question as it needs to be acted on at the correct iptables level.

    Also the fact that your tomato is not the default gateway adds an extra layer of complexity.
    Can you post the output of these commands while the OpenVPN client is connected?

    iptables -t nat -nvL

    and

    netstat -r
     
  7. GraemeG

    GraemeG New Member Member

    Sure :)
    Code:
    Chain PREROUTING (policy ACCEPT 44894 packets, 12M bytes)
     pkts bytes target     prot opt in     out     source               destination                                     
        0     0 DNAT       udp  --  tun11  *       0.0.0.0/0            0.0.0.0/0                                               udp dpt:92** to:192.168.0.6
     1983  120K DNAT       tcp  --  tun11  *       0.0.0.0/0            0.0.0.0/0                                               multiport dports 92**,92**,16**,16** to:192.168.0.6
        0     0 DROP       all  --  vlan2  *       0.0.0.0/0            192.168.0.0/                                    24
    
    Chain POSTROUTING (policy ACCEPT 2006 packets, 121K bytes)
     pkts bytes target     prot opt in     out     source               destination                                     
     1383 83709 MASQUERADE  all  --  *      tun11   192.168.0.0/24       0.0.0.0/0                                     
        0     0 MASQUERADE  all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0                                     
        0     0 SNAT       all  --  *      br0     192.168.0.0/24       192.168.0.0/                                    24      to:192.168.0.2
    
    Chain OUTPUT (policy ACCEPT 23 packets, 1595 bytes)
     pkts bytes target     prot opt in     out     source               destination                                     
    
    Chain WANPREROUTING (0 references)
     pkts bytes target     prot opt in     out     source               destination
    
    Code:
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    89.249.**.**   192.168.0.1     255.255.255.255 UGH       0 0          0 br0
    10.10.88.0      *               255.255.255.0   U         0 0          0 tun11
    192.168.0.0     *               255.255.255.0   U         0 0          0 br0
    127.0.0.0       *               255.0.0.0       U         0 0          0 lo
    default         10.10.88.1      128.0.0.0       UG        0 0          0 tun11
    128.0.0.0       10.10.88.1      128.0.0.0       UG        0 0          0 tun11
    default         192.168.0.1     0.0.0.0         UG        0 0          0 br0
    
    ** Denotes data removed for security.

    There are some firewall rules port forwarding incoming connections over the VPN to a server on 192.168.0.6.

    Regards
     
  8. rs232

    rs232 Network Guru Member

    So with the current config if you point one client to use 192.168.0.2 as a default gateway will this use the tomato VPN to go in internet? e.g. does traceroute say so?
     
  9. GraemeG

    GraemeG New Member Member

    Yup

    WAN Trace:
    Code:
    Tracing route to google.co.uk [172.217.17.3] over a maximum of 30 hops:
    
      1    <1 ms    <1 ms    <1 ms  router2 [192.168.0.2]
      2    15 ms    14 ms    14 ms  10.10.88.1
      3    15 ms    19 ms    15 ms  *.*.*.*.*.com [89.249.*.*]
      4     *        *        *     Request timed out.
      5    15 ms    16 ms    15 ms  *.*.*.*.*.com [77.243.*.*]
      6    21 ms    21 ms    51 ms  212.103.*.*
      7    21 ms    28 ms    21 ms  google1.lonap.net [5.57.80.136]
      8    31 ms    22 ms    28 ms  74.125.242.114
      9    22 ms    22 ms    23 ms  216.239.57.207
     10    29 ms    29 ms    29 ms  108.170.236.73
     11    45 ms    55 ms    44 ms  172.253.50.202
     12    56 ms    49 ms    45 ms  74.125.242.177
     13    45 ms    46 ms    50 ms  74.125.253.199
     14    44 ms    44 ms    44 ms  mad07s09-in-f3.1e100.net [172.217.17.3]
    
    Trace complete.
    
    LAN Trace:
    Code:
    Tracing route to computer01 [192.168.0.3] over a maximum of 30 hops:
    
      1    <1 ms    <1 ms    <1 ms  computer01 [192.168.0.3]
    
    Trace complete.
    
     
  10. rs232

    rs232 Network Guru Member

    OK "on paper" I think what you need tomato is to:

    A- only allow connection to happen towards OpenVPN Server IP : PORT on the OUTPUT table. if the server is identified as a FQDN you need to make sure the host is resolved too so allowing DNS as well I guess.
    B- disable/block forwarding of traffic from 192.168.0.0/24 on br0 towards 192.168.0.1 on the FORWARD table

    A final piece of info (asking all this just because an OpenVPN client from a LAN router (no gateway) is not something you normally do):

    iptables -nvL FORWARD
     
    GraemeG likes this.
  11. GraemeG

    GraemeG New Member Member

    Hi
    If I block all traffic from 192.168.0.0/24 > 192.168.0.1, will my LAN clients (using 192.168.0.1 as their gateway) still be able to connect to clients using 192.168.0.2 as their gateway?

    Code:
    root@unknown:/tmp/home/root# iptables -nvL FORWARD
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
     299K   29M ACCEPT     tcp  --  tun11  *       0.0.0.0/0            192.168.0.6         multiport dports 92**,92**,16**,16**
     326K   20M ACCEPT     all  --  tun11  *       0.0.0.0/0            0.0.0.0/0  
     858K   66M            all  --  *      *       0.0.0.0/0            0.0.0.0/0           account: network/netmask: 192.168.0.0/255.255.255.0 name: lan
        0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0  
      352 15244 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
     855K   66M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
        0     0 wanin      all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0  
        0     0 wanout     all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0  
     2219  129K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
    
    Regards
     
    Last edited: Jan 7, 2019
  12. rs232

    rs232 Network Guru Member


    LAN traffic is unaffected by the suggested solution e.g. a client with default gateway point to 192.168.0.1 will have no involvement with tomato.
     
    GraemeG likes this.
  13. GraemeG

    GraemeG New Member Member

    ok cool.
    How about this?

    Code:
    iptables -A OUTPUT -o tun11 -j ACCEPT #allow VPN tunnel
    iptables -A OUTPUT -p udp --destination-port 443 -j ACCEPT #allow connection to VPN
    iptables -A FORWARD -i br0 -d 192.168.0.1 DROP #drop all to main gateway
    
    ..with my port forwarding entries afterwards.

    Regards
     
  14. rs232

    rs232 Network Guru Member

    Not really, try this:

    Code:
    iptables -I OUTPUT 1 -d 192.168.0.1 -p udp --destination-port 53 -j ACCEPT
    iptables -I OUTPUT 2 -d mycoolvpnprovider.com -p udp --destination-port 443 -j ACCEPT
    iptables -I OUTPUT 3 -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables --policy OUTPUT DROP
    
    iptables -I FORWARD 1 -i br0 -s 192.168.0.0/24 -o br0 -d 192.168.0.1 -j DROP
    just run via SSH first (e.g. do not run automatically as yet) and be ready to restart your router if you get locked out (just in case).

    P.S. what is 192.168.0.6 as per first line of your FORWARD iptable? Have you added this manually?
     
    Last edited: Jan 7, 2019
    GraemeG likes this.
  15. GraemeG

    GraemeG New Member Member

    Hi
    That IP is a server and the following rules are present in tomato to allow port forwarding over the tunnel

    Code:
    iptables -I FORWARD -i tun11 -p udp -d 192.168.0.6 --dports 92** -j ACCEPT
    iptables -I FORWARD -i tun11 -p tcp -d 192.168.0.6 --match multiport --dports 92**,92**,16**,16** -j ACCEPT
    iptables -t nat -I PREROUTING -i tun11 -p tcp --match multiport --dports 92**,92**,16**,16** -j DNAT --to-destination 192.168.0.6
    iptables -t nat -I PREROUTING -i tun11 -p udp --dport 92** -j DNAT --to-destination 192.168.0.6
    
    I assume these are ok to leave AFTER the code you mention above..

    Regards
     
  16. rs232

    rs232 Network Guru Member

    These are all in input so not they have no effect on the killswitch outbound config
     
  17. GraemeG

    GraemeG New Member Member

    Updated via SSH and disabled the key services on the server before stopping the VPN.
    Stopped the VPN and pinged google.co.uk and it replied :(

    I even tried

    iptables -I FORWARD 1 -i br0 -s 192.168.0.0/24 -o br0 -d 192.168.0.2 -j DROP

    and the server could still ping via the 192.168.0.2 (tomato) gateway (which in turn, diverts to the Fritz gateway on 192.168.0.1)..

    I see the logic of the chains but I can't see why whatever I do doesn't prevent WAN traffic outside the tunnel.

    It doesn't even lock me out of either the router or the server (I use RDP from another PC on the LAN to connect to the server).

    Are we even sure iptables works ok on tomato :)

    I do appreciate your helping on this though ;)

    Regards
     
  18. rs232

    rs232 Network Guru Member

    iptables on tomato are just fine it's just that the way routing has been implemented within tomato is something different from what you would see anywhere else.

    I'm afraid I won't go on guessing, your setup is rather peculiar and you'll have to do your tests/attempts. But you're not too far away.

    Just one final thing that came to my mind is: you could try to remove the default gateway on tomato and then add a static route towards Fritz when it comes to contacting the OpenVPN server only. Once again, not guaranteed just keep trying.
     
    Last edited: Jan 8, 2019
  19. GraemeG

    GraemeG New Member Member

    Yes. that's not a bad idea, I could add a rule that would divert to an alternate gateway for a specific destination ip (the vpn) :)

    I'll give that a go :D

    Funny thing is, quite a few people use routers as access points (to provide, say, a VPN'd LAN/WiFi network without altering their main network) so one day maybe someone will see this and need it lol

    Thanks again

    Regards
     
  20. GraemeG

    GraemeG New Member Member

    The following answered my question :)
    Code:
    https://www.linksysinfo.org/index.php?threads/shibby-iptables-block-local-ip-addresses.72317/#post-273626
    So I'm using the WAN port of the tomato router and have a secondary subnet.
    KillSwitch added (specific to server IP).

    I'll add a 2nd NIC to one of my other clients so I can bridge both networks for RDP/VNC access to the server and everything (offsite) can be accessed via TeamViewer (while the VPN is up).
    [no drama, as I can VNC into the twin NIC machine and access tomato in case of a VPN issue]

    All seems to be working ok now. So the rule of thumb is, unless you plan to use VLANS, use the WAN port :)

    Thanks for your time though, much appreciated.

    Regards
     
  21. rs232

    rs232 Network Guru Member

    Ok let me clarify not to be right all the time but in the interest of the technical issue here.

    - I'm not sure this post you're referencing is relevant to you. LAN communication given a default gateway is within the LAN in your case 192.168.0.2 *I think* is still relevant. E.g. if you point to 192.168.0.2 from e.g. 192.168.0.3 and you traceroute from the latter you'll see packets flowing via 192.168.0.2 that has to come via routing hence iptables should be involved. Having said that, I never tested this and once again, your scenario is a one off never seen it before.

    - Will all the due respect but your solution was to change what you didn't want to change as per OP. Of course using the WAN is the obvious answer but you clearly stated you are not willing to do so hence this long thread

    Regardless, glad you made it working somehow, but I think this should be further investigates as a killer-switch for OpenVPN client is has not been made yet :)
     
  22. GraemeG

    GraemeG New Member Member

    Hi
    Using SSH, I was only ever able to kill the tomato gui using DROP filters. No matter what filters were applied, traffic flowed between client 192.168.0.6 (using tomato as its gateway) and 192.168.0.1 (main router) [or to any other client using the main router as their gateway].

    The information in that post seemed to explain why.

    I appreciate this really required a VLAN arrangement, I was just being lazy re the RDP/VNC setup :)
    (it worked fine until needing to drop all traffic outside the tunnel lol)

    Thanks anyways though :D
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice