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

    pfBlockerNG-devel and Squid Proxy compatibility

    Scheduled Pinned Locked Moved pfBlockerNG
    1 Posts 1 Posters 362 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
      SCU
      last edited by

      Hello Community,

      I'm currently evaluating the pfSense Firewall, with the Squid Proxy/pfBlockerNG/Snort combo.
      This software stack is installed on a miniPC with an Intel Core i7 + 24Gb RAM.

      I'm having trouble with Squid and pfBlockerNG when they are running at the same time. If I only activate one at a time, each works as expected, if I activate them both, things get more complicated!

      My Test Environment:
      • 2 VLANs (VLAN_50 for PCs, VLAN_30 for Printers) and 1 LAN to host these VLANs.
      • 1 single WAN interface connected to the internet

      Packages versions:
      • pfBlockerNG-devel: 3.2.0_6
      • Squid: 0.4.46
      • Snort : 4.1.6_12
      • pfSense : 2.7.0

      c042cee2-3360-40c9-ad33-d01eea18501c-image.png

      I've configured only the PRI1 IPs of pfBlockerNG:
      755b8dee-84b6-4c63-a95e-893732af4dad-image.png

      With the associated rule in the VLAN_50:
      0affa107-18ea-4e2a-bb84-b022f12e5de4-image.png

      From my PC, on the VLAN_50, I enter an IP from the PRI1 list (1.25.58.63) and it is blocked : perfect !
      25875207-999b-4a37-8ffc-8de49df0b433-image.png

      I then activate Squid Proxy in transparent mode, which listens on the VLAN_50:
      From my PC, on the VLAN_50, I enter the same IP from the PRI1 list (1.25.58.63) and this one is no longer blocked: Squid replaces the source IP in the request with its WAN IP and the request exits pfSense to the WAN
      8108afc6-359c-4c06-b920-cc53f72ca37c-image.png

      This behavior may seem logical, since it is the principle of a proxy, it is more the order of application of the rules that is questionable: why pfBlocker filtering is not applied first before entering in the proxy ?

      To solve this problem, I tried another approach:
      • I use Squid proxy only on the LAN
      • I add a NAT rule to forward http and https requests from the VLAN_50 to the LAN

      0a139bc4-e7e7-42c6-b2b3-273657f1b420-image.png

      681cd43f-fb56-4127-9eec-2761a74437eb-image.png

      From my PC, on the VLAN_50, I enter an IP of the PRI1 list (1.25.58.63) and it is blocked: perfect!
      Authorized requests are successfully transferred to the LAN:

      2696cc0c-b843-4fd5-8ac9-16645f378d52-image.png

      But nothing comes out on the WAN !

      • No LAN-to-WAN trace in the system log

      • list itemNo trace with tcpdump

      • list itemSquid seems to nothing with the request, by the way in Squid's logs, we find the request with a NONE state

      5f5e0861-a5ce-4ca8-885c-0b555674ac60-image.png

      My questions:
      Does the Squid approach, listening over LAN and NAT from VLAN_50 to LAN, make sense and should work?
      If so, any idea what's stuck?

      Thanks for your help !

      Stéphane

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