Problem Blocking External VPN Usage by Internal Users

  • I have set up a schedule to keep my kids from having internet access during night time. Generally blocks everything, except they have been able to tunnel out with VPN app on their iPhones.

    Here is my setup:

    1. Using a pfsense hardware appliance,running most recent version of pfsense.
    2. Using DHCP Server to assign IP addresses by MAC Address.
    3. Set up a Schedule in Firewall.
    4. Set up a two LAN firewall rules blocking all traffic in/out to those IP addresses. Specifically, I block IP4 + IP6, 'any' packet type.
    5. I can confirm that typical email, web browsing, messaging is blocked as expected.
    6. With Packet Capture, I can confirm nothing is getting through except for the VPN they have set up on their iPhones.
    7. In addition to fully resolved IP Addresses, I can verify that the assigned IP addresses are also passing

    Here is the output from a packet capture:
    23:21:27.982227 IP > UDP, length 116
    23:21:28.052145 IP > UDP, length 100
    23:21:28.088906 IP > UDP, length 100
    23:21:28.106436 IP > UDP, length 100

    Any suggestions would be welcome.



  • LAYER 8 Netgate

    Have you tried scheduling a pass rule for the times you want them to have access instead? It should be followed by a block all rule. That doesn't have to have a schedule on it.

    There is no way for a scheduled block rule to kill established states because it does not know what states to kill.

    A scheduled pass rule can kill all the states it created when it expires because they are flagged as such.

    If I'm misunderstanding your issue please let me know and post a screen shot of your LAN rules.

  • Derelict - Thanks very much for taking the time to respond. I've been using pfSense for years and have usually been able to figure things out. (Not a very high bar . . .) Your comment on States makes sense. If the kids had opened up a vpn connection during their window of usage, then perhaps the States persist. Not sure how to address, but here are my Firewall Rules.

    Thanks again.

  • LAYER 8 Global Moderator

    ok for starters why do you have dest of each source in the lan rules.  those are pointless and would never trigger.

    also you have a rule that says 1194 is allowed to the lan address just below a rule that says everything is allowed - pointless..  What is the point of allowing 1194 (vpn) to your pfsense lan address?  Why would you be creating a vpn to pfsense on the lan side in the first place.

    Rules are evaluated top down, first rule to trigger wins.  No other rules are looked at.  If you have a rule that says any any, any rule below that is pretty pointless.

    In your current rules you allow specific source on a schedule..  If not that schedule the rule would not fire, but then you would just go to the next rule, next, next, etc..  then the any any rule fires and there you go access.  If you want them to only be allowed on a schedule you can not have a rule below that that says hey everyone can go anywhere.  Your allows rules below the scheduled allow would have to not allow them.  then it wouldn't trigger and finally they would get to the default deny rule and be blocked.

    as to phones getting out..  What does that have to do with a vpn?  If you don't allow them out your connection, wouldn't they just use the phones cell data?  Kind of hard to block a phone that has its own connection via cell.  You could block wifi til your blue in the face..  Do these phones not have a data connection??

    that ip they are going to is owned by digital ocean.  They provide vps, not vpn services.  So they are connecting to some server on digital ocean.  Yeah it could be running a vpn service..  While their pricing is petty good, the bandwidth has limits - would seem odd a company would host vpn service on there.  Your kids or their friends running their own vpn??

  • LAYER 8 Netgate

    Thanks for posting your rules. There are several things that can be corrected that will probably help with your general understanding.

    The first thing is interface rules in pfSense only affect connections being established coming into an interface.

    So when you have a rule on LAN with a destination of Rebecca that rule will never match because you will never be sending traffic with a destination of Rebecca to the router's LAN interface. Note that all of the counters on all of those rules are zero bytes because they never match anything. You can just delete all of them. They do nothing and just needlessly complicate what you're looking at. That goes for all rules on LAN that have a destination set, including the OpenVPN rule at the bottom (which should probably be on WAN destination WAN address port UDP/1194), with the exception of the automatic anti-lockout rule at the top.

    All of the other firewall state information necessary such as passing traffic out WAN to the destination and reply traffic back into WAN and out LAN to the originating host is handled automatically by pf. You don't have to think about it in almost all scenarios. All of the states are automatically built based on the source and destination of the original packet into LAN. Routing is done, interfaces are chosen, and all necessary states in the state table are created for that traffic flow.

    Now let's look more closely at Rebecca. I am assuming you want that IP address to have internet access to anything from 10am until noon Tue, Wed, and Thu. I realize that is probably not the case but for a simple example I will use it.

    You will want to change that rule to protocol any, not just TCP. Different things like DNS lookups, etc, use UDP. Leave everything else the same in that rule.

    Remove the schedule in the next rule (The 4th Rebecca rule in your image). I would also change it from Block to Reject so a failure will be returned to the device instead of the connection just hanging until it times out. This rule will reject all connections if rule processing gets that far, which only happens when the schedule in the rule above does not match.

    If you want to open access at other hours, use another scheduled pass rule above the block rule.

    You can just remove the last Rebecca block rule on the NIGHT THROUGH EVENING different schedule.

    Repeat for the other source addresses.

    Word of caution - they sound pretty savvy with the VPN and all. This only works if their IP address does not change. There is probably nothing stopping them from setting a static IP address outside the DHCP range and bypassing all of this. And as @johnpoz noted above, I'm sure mine would just switch to cell data. Maybe your carrier has option$ for controlling that.

    In a nutshell: you pass traffic with scheduled rules and block everything else. That will probably get you much closer to your desired results.

  • jonPoz and Derelict,

    You guys are great! I really appreciate the tutorial. Sounds like my logic is just plain wrong. I was scheduling the BLOCKED times, assuming that once a BLOCK was triggered, that was it. Everyone else would just go through until the default PASS was triggered.

    I'm at work, so can't test all of this till later. But to summarize, here is what I will do:

    1. Eliminate all of the current scheduled rules.
    2. Create Schedules representing periods of PERMITTED usage, i.e, Noon-8PM.
    3. For each child, create a PASS rule PERMITTING usage during the SCHEDULE, indicating SOURCE of each child and DESTINATION of *.
    4. For each child, create a REJECT rule (after PASS rule) BLOCKING from SOURCE of each child and DESTINATION *.
      (From a style and/or convention perspective, are these specialized BLOCK rules typically right after the specialized PASS rules? Or is it more common to group these together later before the default PASS rule?)
    5. Make sure that there is a general PASS rule at end of Rule Set that PERMITS all else.


    1. I will clean up the vpn rule. Don't recall how that got there. It may have been generated as I was trying to set up a VPN Server on pfSense. That's a project for another day.
    2. Thanks for cell phone comments. Already got that covered with cell phone carrier, which allows scheduling.
    3. I've thought about static IP addresses. (I had hoped there was a way to filter on MAC addresses, but I assume that would require a layer 2 network filter.) I was going to lock down permitted IP addresses and then see if Snort would allow me to find unauthorized IP addresses. Alternatively, I was going to consider a Captive Portal. Any other ideas welcome.
    4. Other issue is MAC spoofing . . .
    5. Ultimately, I will have to enforce an ACCEPTABLE USAGE POLICY. Frankly, setting up the firewall and figuring out how effect this technically, is a good way for me to learn more about networking.

    Thanks again.

  • LAYER 8 Global Moderator

    If your kids know about mac spoofing your prob fighting a loosing battle ;)

    But mac spoofing on a phone is a bit more difficult then say on your typical PC.. Guessing their phones are jail broken as well..

    One technique that can help with traffic you don't really want other than actually stopping it is just make it so freaking slow its not worth it ;)  This method is less likely to find a way to circumvent the block.  And for the person to just think well something is wrong with the network..

    This isn't really a security measure but can be used as a deterrent to unwanted use..  When they ask you why the internet is slower then grass growing, you can play dumb and ground them for using the internet after hours anyway ;)

    Or show them hey my speed is working fine - must be something with your phone, what did do to it now ;)

    Why do you need a default pass rule.. if your trying to block access then you really would never have a general pass rule.  You want everything not allowed to hit your default deny.

    if you want your device(s) to have access then create a specific allow rule for your devices only.  This normally done with a dhcp reservation so your devices always get a same IP and those IPs are specifically allowed the access you want.  Devices not allowed or denied..  This keep them from changing their IP, and if you setup static arp this would prevent them from changing their macs.

    This sort of should be good as long as you don't have a lot of guest users to your network.

  • johnpoz,

    Very helpful. I don't think kids have figured out mac spoofing or static ip addresses (yet), but that's only because they haven't had to do so. . .

    I've used the default PASS rule just because I didn't want to white list all of my devices that hang out on my network, but it makes sense. Let me give it a try.

    Thanks again for your help.