Creating a non-vpn Firewall Rule

Discussion in 'privacy technology' started by n8chavez, Sep 13, 2012.

Thread Status:
Not open for further replies.
  1. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    2,305
    Location:
    Location Unknown
    I am having the hardest time creating firewall rules that will block anything not going through a vpn, should the connection drop. I don't know why, but the rule I've created doesn't seem to work right. For example, I know that AirVPN uses addresses 10.4.0.0 - 10.9.255.255. So creating a rule that tells my firewall to block everything not coming from that IP range as the source whenever application X is active that should work, right?

    It doesn't, at least here. Either the rule block everything, and drop the vpn connection itself, or doesn't block anything and allows app X to connect without the VPN. I've tried putting the rule at the top of the rulset and at the bottom, no effect.


    Any help would be appreciated.
     

    Attached Files:

    Last edited: Sep 13, 2012
  2. ComputerSaysNo

    ComputerSaysNo Registered Member

    Joined:
    Aug 9, 2012
    Posts:
    1,430
    openvpn uses port UDP 1194 & TCP 80 so your going to have to work with those two ports and block everything except them.,
     
  3. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    Those addresses (10.4.0.0 - 10.9.255.255) are "inside" the VPN tunnel. You need to block traffic through your physical NIC(s) to everything except the AirVPN server that you're using.
     
  4. CasperFace

    CasperFace Registered Member

    Joined:
    Jul 31, 2010
    Posts:
    200
    I'm not familiar with this particular firewall software, but basically all you should have to do is this:

    1. Allow: [your VPN client].exe
      Source: Local area network (192.168.x.x) Port: any​
      Destination: [VPN authentication server IP address] Port: 443​
    2. Allow: openvpn.exe
      Source: Local area network (192.168.x.x) Port: any​
      Destination: [VPN server IP address] Port: [VPN server port]​
    3. Allow: [all other applications]
      Source: Virtual private network (10.x.x.x) Port: any​
      Destination: any / Port: any​
    4. Block: [all other applications]
      Source: Local area network (192.168.x.x) Port: any​
      Destination: any / Port: any​
    In that order. Also, if the authentication server resides on a static IP address, then you should add the domain name <> IP address pairing to your local HOSTS file. Otherwise, svchost.exe has to send a DNS query to resolve the domain name via your LAN, leaving you open to DNS leaks.

    There may also be some miscellaneous loopback "stuff" you need to allow on the local network as well, but I can't think of it off hand.
     
  5. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    2,305
    Location:
    Location Unknown
    Thank you all for you help. I appreciate it.

    I use LooknStop firewall. I follow both sets of instructions, as well as the instructions given at the AirVPN forum, and I still haven't been able to create rules that will both allow me to connect to the VPN and block all connections if app X is active and the VPN is not connected. It seems like it would work with both sets of instructions, but it doesn't.

    I wonder if it could be a LnS issue. CasperFace - When I use your instructions the VPN loses connection if the block rule is enabled, despite the allow rules coming first in the hierarchy. mirimir - When I used the block rule you suggested nothing was blocked; I could disconnect from the VPN with app x running at still connect out.

    I wonder if I might need to switch firewalls do do this, or just switch to mullvad, which blocks dropped connections within the software.
     
  6. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    Or you could run your VPNs in Linux VMs. You get better isolation, and there are old Wilders threads with Shorewall rules.
     
  7. CasperFace

    CasperFace Registered Member

    Joined:
    Jul 31, 2010
    Posts:
    200
    Without knowing the intricacies of your network setup and applications, it's hard to pinpoint the problem. Looking at the FAQ for Look n' Stop, it certainly seems as though the firewall should be capable of doing what you want it to do.

    I suggest a step-by-step approach. Keep the 'allow' rules in place but disable the broad-based 'block' rule for now. Then set your firewall in interactive mode so that it ASKS about each connection attempt, from which you can create (temporarily, if necessary) various 'allow' rules for certain system processes that may be required for the proper interaction between your local network, the virtual network, and various external destinations. You also should also make sure that you have firewall logging turned ON so you can identify exactly where any hang-ups may be taking place.

    Finally, don't set any global or broad-based 'block' rule until you are absolutely sure that you have all of the necessary 'allow' rules in place. If all else fails, just forget the system-wide approach and make customized allow/block rules specific to each application instead. On a typical machine, there's really only a handful of applications that will want to "call out" to the internet anyway, so it shouldn't be that big of a deal to create a ruleset for each one.
     
  8. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    2,305
    Location:
    Location Unknown
    I think I might have figured it out. The right screenshot is the LnS "Allow" rule, which allows communication from my NIC to all servers on port 443 whenever openvpn.exe is active. The left screenshot is an LnS "block" rule, which blocks everything not in the AirVPN range that has a destination of my NIC when utorrent is active.

    Is it okay to have the block rule limited to tcp/upd, or do I need to alter it to be more restrictive in order to block all communication?
     

    Attached Files:

Loading...
Thread Status:
Not open for further replies.