Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    LAN clients leaking out VPN GWs

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 2 Posters 293 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      scratchydog
      last edited by

      I sense this is going to be a face palm moment. But I just can't figure out how my LAN clients can leak out the VPN GWs that I have no FW rules defined for on the LAN Interface.

      I have basically got:
      LAN to specific destination IPs or Alias rules defined and I select the GW I want that traffic to flow out of. The GW is the Open VPN interface. This works fine.

      At the bottom of the rule stack, I have a LAN -> WAN Deny All. Preventing LAN from using the WAN, therefore, if the VPN is down, the LAN can't go out the WAN and obviously connectivity is down. This is good and what I want.

      However, I have about 4 Open VPN instances and route traffic mostly by specific Geolocation needs down the VPNs etc.
      What I am seeing is if the "catch all" VPN GW (Lets call it VPN-GW1) for the LAN at the bottom of my rule stack goes down, somehow, without any rules defined, the LAN seems to automatically route out VPN-GW2 and I have no rules defined to allow this.

      I must be missing something stupidly obvious, like a static route or something ( cant seem to find anything).
      Im getting ready to face palm... Does Pfsense process all FW rules top to bottom and revert to some other "path" function? I thought there was an implicit deny all if a rule match isn't found for the interface ?

      So in Summary the rules look a bit like:

      LAN -> Europe Dest = VPN-EU GW
      LAN -> USA Dest = VPN-USA GW
      LAN -> AISA Dest = VNP-AISA GW
      LAN -> ANY Dest = VPN-GW Local Exit
      LAN -> WAN = Deny

      Unrelated to LAN FW rules I have a DMZ VPN GW off another interface on the PFsense
      Somehow traffic for the "any" rule finds a way to exit this GW that only the DMZ network can use.
      I have a LAN -> DMZ FW rule, but that is restricted to certain ports and the destination IP range for that rule is the DMZ range.
      So theoretically, traffic from LAN can't route out via the DMZ lan to the VPN.

      I realise how difficult this is to diagnose without the ruleset to view. But I would be happy with any ideas people may have regarding checking the PFsense traffic processing functions and the order it processes rules, routes GW's etc.

      1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by

        @scratchydog said in LAN clients leaking out VPN GWs:

        Does Pfsense process all FW rules top to bottom

        Yes.. First rule to trigger wins, no other rules are evaluated. How about you post up screenshot of your rules. But if a gw goes down, rule just leaves off the gateway.. Have to look at that setting.

        gatewayremoved.png

        In system, advanced, misc

        So if you have a rule that allows traffic based on source and dest, but the gateway is down the rule would allow the traffic using whatever the default gateway is, normal routing.

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • S
          scratchydog
          last edited by

          Ok great info. Let me take a look at that more. If I can't figure it out i'll post up some rules. This is likely the cause though. I now its first triggered rule wins, but i couldn't immediately see how any rule would allow traffic to a GW that isn't specified... what you're saying makes perfect sense. Thanks, I'll investigate.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.