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

Block access to WAN, for a single client [SOLVED]

Scheduled Pinned Locked Moved Firewalling
7 Posts 3 Posters 9.4k 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.
  • L
    lavito
    last edited by Nov 6, 2017, 9:53 PM Nov 6, 2017, 1:10 AM

    I have a simple setup WAN/LAN1/LAN2.  All LAN1/2 clients have access to WAN and can access the internet.
    However, I wanted to block access to the Internet for one of the clients form LAN1, 192.168.0.3, but was not able to do so.

    I have no floating rules or other special routing setup. The only rules I have is:

    WAN:

    • BLOCK * RFC 1918 networks * * * * * Block private networks

    • BLOCK * Reserved Not assigned by IANA * * * * * Block bogon networks

    LAN1:

    • PASS * * * LAN1 Address 443 80 61000 * * Anti-Lockout Rule

    • BLOCK IPv4 * 192.168.0.3 * WAN net * * none

    • PASS IPv4 * LAN1 net * * * * none

    I can block 192.168.0.3 by adding a floating rule but I was hoping I can just add a normal rule to the interface.

    Can anybody shed some light on what I may be missing?

    1 Reply Last reply Reply Quote 0
    • D
      Derelict LAYER 8 Netgate
      last edited by Nov 6, 2017, 1:44 AM

      Destination WAN net is not the internet. Destination any is the internet.

      And you can't block source 192.168.0.3 using a floating rule because NAT has already occurred so the source at that point would be WAN address.

      Chattanooga, Tennessee, USA
      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
      Do Not Chat For Help! NO_WAN_EGRESS(TM)

      1 Reply Last reply Reply Quote 0
      • L
        lavito
        last edited by Nov 6, 2017, 8:27 PM Nov 6, 2017, 7:38 PM

        @Derelict:

        Destination WAN net is not the internet. Destination any is the internet.

        And you can't block source 192.168.0.3 using a floating rule because NAT has already occurred so the source at that point would be WAN address.

        Thank you for clarifying what the "WAN net" alias is not, however can you explain why when adding a rule to the WAN interface:

        BLOCK
        Protocol/Port: Any
        Source: 192.168.0.3 and
        Destination: "Any"

        still does not block "192.168.0.3" from accessing the internet via WAN?

        1 Reply Last reply Reply Quote 0
        • K
          KOM
          last edited by Nov 6, 2017, 8:04 PM

          Rules are applied to traffic that enters an interface.  If you want to fiddle with your LAN clients, you need to put your rule on the LAN interface.  Also, if you add a rule that blocks particular traffic, you will need to reset any existing states of that traffic.

          1 Reply Last reply Reply Quote 0
          • L
            lavito
            last edited by Nov 6, 2017, 8:27 PM Nov 6, 2017, 8:20 PM

            OK, I  added a BLOCK rule !192.168.0.0/16 to LAN and it works, thank you for that!

            However I was wondering why it does not work when you put the below rule in WAN?
            Strictly speaking, traffic "enters" the WAN interface from LAN1, so I don't  understand why below WAN rule does't work:

            BLOCK
            Protocol/Port: Any
            Source: 192.168.0.3 and
            Destination: "Any"

            @KOM:

            Also, if you add a rule that blocks particular traffic, you will need to reset any existing states of that traffic.

            Yes, I was aware of this.

            1 Reply Last reply Reply Quote 0
            • K
              KOM
              last edited by Nov 6, 2017, 8:57 PM

              But the traffic from LAN never enters WAN, it leaves it.  You have to imagine pfSense as a central object with the interfaces at the edge.  Traffic enters an interface from the network it came from IN to pfSense.  pfSense then decides what to do with the traffic and sends it OUT a different interface.

              Downloading a file from the Internet involves traffic going IN to WAN and OUT to LAN.
              Uploading a file involves traffic going IN to LAN and OUT to WAN.

              This is a simplification of course, as there is communication back and forth in any TCP connection.

              Below is an image which may help explain how it works.

              ![pfSense Inbound vs Outbound.png](/public/imported_attachments/1/pfSense Inbound vs Outbound.png)
              ![pfSense Inbound vs Outbound.png_thumb](/public/imported_attachments/1/pfSense Inbound vs Outbound.png_thumb)

              1 Reply Last reply Reply Quote 2
              • L
                lavito
                last edited by Nov 6, 2017, 9:49 PM Nov 6, 2017, 9:40 PM

                Thank you very much for that !!! This was the detail I was missing.  8)

                In my mind traffic, in case of e.g. HTTP get,  was taking the route below:

                [IN -> (LAN interface) ->  OUT] –--router------>  [[size=12pt]IN -> (WAN interface) ->  OUT]

                So I thought, when the rule is evaluated, as far as the traffic is concerned, the traffic from LAN arrives to WAN and therefore enters traffic into the WAN interface (the red IN)

                Now I can see why it does not work. Essentially I now visualise it as below:

                [IN -> (LAN interface) ] –--router------>  [(WAN interface) ->  OUT]

                Thanks again!

                1 Reply Last reply Reply Quote 0
                7 out of 7
                • First post
                  7/7
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                  This community forum collects and processes your personal information.
                  consent.not_received