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

    Squid: howto seperate subnets from each other?

    Scheduled Pinned Locked Moved General pfSense Questions
    11 Posts 3 Posters 3.5k 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.
    • chpalmerC
      chpalmer
      last edited by

      Put your outgoing rules (to block) first for each interface.

      In my example below- the public interface is blocked from seeing the LAN interface (plus a couple of other public subnets) before the allow all rule.

      public net and 192.168.15.0/24 are the same.

      OutboundPublic.JPG
      OutboundPublic.JPG_thumb

      Triggering snowflakes one by one..
      Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

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

        Thanks for your reply. Blocking each subnet makes total sense to me.

        However, please have a look at my ruleset:

        Action: Reject
        Source: VBOX net (192.168.3.0/24)
        Port: *
        Destination: 192.168.3.1
        Port: 443/tcp
        

        I would have expected that this rules blocks access to pfSense webinterface, but it doesn't. The user connects via proxy so the rule will never match!

        The same applies to this rule.

        Action: Reject
        Source: VBOX net (192.168.3.0/24)
        Port: *
        Destination: LAN net (192.168.1.0/24)
        Port: *
        

        The rule above clearly blocks access to the LAN subnet - but only if not connecting via squid.

        My test setup shows, that I can access the LAN subnet from VBOX subnet via proxy (destination ports 80/tcp & 443/tcp)

        So how can I configure squid to block this access?

        Unbenannt.PNG
        Unbenannt.PNG_thumb

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          One thing you could do is change the pfSense webgui port and then block all connections to that port.

          Something to watchout for is that the webgui listens on every interface and so you have to be careful to block access to each of those from your VBOX interface. For example you will be able to access it on your WAN IP from the VBOX subnet.

          A slightly odd thing here is that unless you are running some experimental version of Squid it doesn't normally proxy https traffic.  :-\

          Steve

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

            Hello Steve

            Thanks for replying. I also would love to configure the interface on which the webConfigurator is listening on.

            But anyway I solved my issue in the meantime by simply blacklisting the relevant subnets:

            
            192.168.1.0/24
            192.168.2.0/24
            192.168.3.0/24
            
            

            Mission completed!

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              It's probably still accessible on the WAN address.  ;)

              Steve

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

                Ehrm, it shouldn't as squid is only listening on my internal vlan interface. Also 443/tcp from WAN is blocked…

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

                  Maybe I should open another thread for this question, but is there a way I can prevent DNS tunneling from my DMZ to the outside? E.g. by disabling TXT records within DNS?

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    To access the WAN interface from an internal subnet you are only filtered by the firewall rules on the internal interface. Since the WAN IP is public it will not be caught by any of your rules or your squid blacklist. I'm not sure how squid comes into effect here though if it was proxying connections to internal interfaces ok I see no reason why it shouldn't do so for WAN.

                    You mean like vpn-over-dns?

                    Steve

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

                      Ouch! Never thought about that! :-\

                      No, I am not talking about DNS in VPN, I am talking about TCP/UDP in DNS txt records:

                      http://www.sans.org/reading_room/whitepapers/dns/detecting-dns-tunneling_34152

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Neither did I until I stumbled across it by accident one day and was forced to think about it.
                        I don't think I've ever tested it on a box running Squid though so your situation may be different.

                        That's what I meant by VPN-over-DNS, hiding an encrypted tunnel inside dns queries. I have never looked into blocking/detecting it, mostly because last time I looked into setting it up it was not trivial. However I see that Softether supports it so maybe it will be more common: http://www.softether.org/1-features/1._Ultimate_Powerful_VPN_Connectivity#1.6.VPN_over_ICMP.2C_and_VPN_over_DNS%28Awesome!%29
                        I assume to do this you still need to actually own a domain though.  :-\

                        I'd be interested in any thoughts.

                        Steve

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