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

    Question regards setup of a Guest WiFi

    Scheduled Pinned Locked Moved General pfSense Questions
    22 Posts 6 Posters 6.1k 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.
    • P
      pfsensefanboy
      last edited by

      Hello all,

      Whilst I'm new to pfSense, I already have the 2 basic interfaces setup and working i.e. WAN and LAN.

      I'm now trying to do something with the 3rd interface that I have in my box i.e. setup a Guest WiFi network, but I'm not exactly sure how to do it.

      Any pointers, and/or answers to the following questions will be greatly appreciated.

      So, my current setup is as follows:

      *  pfSense is the DHCP server
      *  LAN is 192.168.1.x (Linksys router E1000 is connected to the LAN interface, with a fixed IP of 192.168.1.2)
      *  OPT1 is 192.168.2.x (Linksys WRT54G is connected to the OPT1 interface, with a fixed IP of 192.168.2.1)

      All that I have done thus far, is to have setup the OPT1 interface (under INTERFACES => OPT1) with "Static IPv4" and an IPv4 address of 192.168.2.1…and under "SERVICES => DCHP SERVER" I have "Enabled DHCP server on OPT1 interface" and provided a Range of 192.168.2.100 to 192.168.2.254

      Is there anything else I need to do in order for clients of the OPT1 (Guest) network to have Internet access?

      What's currently happening is that clients who connect to this OPT1 network are provided an IP address in the range 192.168.2.x, but they really don't have internet access. Android phones also display the message "Your internet connection is unstable".

      I guess I have to add and/or change something in the NAT/Firewall section, correct? Or do I have to bridge one or more interfaces? I'm still learning, albeit at a slow pace.

      Thanks.

      1 Reply Last reply Reply Quote 0
      • dotdashD
        dotdash
        last edited by

        You will need at least firewall rules on OPT1 to allow the traffic out. Look at the rules on LAN. You could start will a rule to block OPT net to LAN net, then add a rule for OPT net to any. NAT should be good unless you are using Advanced Outbound Nat- if so, use the LAN rules as a template.

        1 Reply Last reply Reply Quote 0
        • DerelictD
          Derelict LAYER 8 Netgate
          last edited by

          Most people want to block guest network access to local assets.

          On OPT1:

          1. Pass to specific local assets they need (DNS)
          2. Reject to local assets they don't need (LAN net, RFC1918, This firewall)
          3. Pass everything else (internet)

          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
          • P
            pfsensefanboy
            last edited by

            Oh, silly me…and my untrained (read newbie) eyes! I didn't realize there were additional tabs (for LAN and OPT1) on the "Firewall: Rules" screen.

            Anyways, thank you Derelict and dotdash (for opening/training my eyes)!

            Using both of your instructions (which I'm still trying to decipher), I did a google search and found a reddit post at https://www.reddit.com/r/PFSENSE/comments/2kn8b6/one_wan_two_independent_lans_firewall_questions/ which was a lot simpler for me to understand and replicate.

            I am now able to access the internet from the Guest network…yaaaay!!!

            Another question I have (out of curiosity) is: what can I do/try, to ensure that I'm not able to access LAN (whilst connected to OPT1)....and conversely, that I can indeed access OPT1 (whilst connected to LAN, which is what I intend for now at least)?

            Thanks again.

            1 Reply Last reply Reply Quote 0
            • P
              pfsensefanboy
              last edited by

              Actually…@Derelict, I would appreciate if you could please elaborate on how I would go about enforcing rules # 1 and 2 that you suggested.

              In other words, for each of those two rules, what would I select against "Protocol", "Source (type)", and "Destination (type)", and perhaps any other fields.

              Sorry for these very stupid/basic questions....as I said, I'm new to this, and learning.

              Cheers.

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                The first step is identifying the traffic outlined in 1 and 2 as it pertains to your network.

                In general:

                Guest hosts need DHCP. pfSense automatically passes DHCP traffic into interfaces with a DHCP server enabled so you don't need to worry about this.

                Guest hosts need DNS. I don't know if you want them to resolve against pfSense or OpenDNS or google, etc. Whatever you decide, that traffic will need to be passed. TCP/UDP Port 53 to the DNS Servers.

                Guest hosts typically do not need access to trusted LAN hosts, so you typically block access to that. In a normal IPv4 NAT situation, this can often be most-easily-accomplished by creating an alias called RFC1918 containing the following networks:

                192.168.0.0/16
                172.16.0.0/12
                10.0.0.0/8

                Then blocking traffic to that alias destination.

                Guest hosts typically do not need access to firewall admin interfaces so block access to destination This firewall protocol any ports any.

                Guest hosts typically need access to the internet so pass traffic to any.

                I am currently working on a complete walkthrough of the attached. It will probably take me at least this weekend maybe next.

                IoT-Physical.png
                IoT-Physical.png_thumb

                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
                • P
                  pfsensefanboy
                  last edited by

                  Thanks again @Derelict…this was an excellent explanation indeed  :)

                  The only doubt I have (as in, how exactly to implement it within the pfSense GUI) is with your second point (within the "In general:" section) i.e. "... that traffic will need to be passed. TCP/UDP Port 53 to the DNS Servers.".

                  Would appreciate if you could take a look at the attached screenshot of my rules and let me know if there's anything that needs to be changed, added, or removed. My guess is that at least one rule is redundant.

                  Thanks.

                  MyFirewallRules.jpg
                  MyFirewallRules.jpg_thumb

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    You need to change the order of your rules, for starters.

                    Specific rules (like passing DNS) should go first, then less-specific, then general.

                    The first match is processed and then processing stops.

                    You need to add destination port 53 to the DNS rule (and possibly destination IP addresses if you want to dictate what DNS servers they can use.) Move it to the top.

                    I also generally add pass ICMP echo request to dest OPT1 address in case someone clueful is trying to debug a problem. Should also go at the top.

                    I also generally use Reject instead of Block for things like this so users get immediate feedback when opening connections that are rejected instead of just dropped packets.

                    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
                    • P
                      pfsensefanboy
                      last edited by

                      Okay…I've changed the order of my rules, and also added/changed other rules (based on your recommendations).

                      With regards to using "Reject" vs "Block"....that was something that I wasn't sure about....but I've now changed that as well based on your suggestion.

                      Does things look right now?

                      One thing I did notice is that when I use a laptop and connect (wirelessly) to the guest wifi (OPT1) I'm given an IP address of 192.168.2.100 (which is fine). The problem is that when I try to ping that IP from a desktop computer (wired) on the LAN network (192.168.1.x) I receive the message "Request timed out". Do you know what might be wrong, or how to fix this issue (if it is indeed an issue)?

                      Thanks again.

                      MyChangedFirewallRules.jpg
                      MyChangedFirewallRules.jpg_thumb

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        You probably want that RFC1918 rule to be protocol any instead of just TCP.

                        Being able to ping from LAN to OPT1 requires:

                        Rule on LAN that passes the traffic
                        No local firewall on the host you're pinging blocking incoming ICMP from foreign subnets (I'll bet it's this)
                        The host you're pinging has pfSense as its default gateway.

                        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
                        • P
                          pfsensefanboy
                          last edited by

                          Thanks again.

                          I have now actioned your first statement.

                          ??? As far as your last two (statements) are concerned, I have no clue what you're talking about! Pardon my ignorance  :-[

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by

                            Windows firewall will allow pings from other hosts on the local subnet but not from hosts on other networks. That might be why you cannot ping the host on OPT1 from LAN.

                            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
                            • P
                              pfsensefanboy
                              last edited by

                              Oh really 'eh?

                              So if I temporarily disable Windows firewall on the OPT1-connected laptop, I should then be successful….I'm guessing!?

                              I guess this isn't something I should be worried about, correct?

                              1 Reply Last reply Reply Quote 0
                              • kesawiK
                                kesawi
                                last edited by

                                A couple of additional suggestions:

                                RFC1918 Alias
                                Add the subnet 127.0.0.0/8 to the RFC1918 firewall alias

                                DNS Rule
                                For the  rule add "OPT1 address" as the destination. The rule as currently configured allows guests to query any DNS server on your LAN subnet. You don't want any traffic from the guest subnet being allowed to the LAN. The last catch-all allow any rule at the bottom of your rule set allows access to DNS servers on the internet.

                                RFC1918 Reject Rule
                                As well as changing the protocol to any, you should also change the source to any as this will block traffic where a malicious guest may be trying to spoof their IP.

                                This Firewall Reject Rule
                                This rule isn't really needed as the RFC1918 rule above will catch all of the traffic to the firewall.

                                Allow OPT1 Anywhere Rule
                                While this rule will work I would add  the RFC1918 alias to the destination and make sure the not box is ticked for the destination. If you've done it correctly the destination on the summary page will show as !RFC1918 for this rule. While traffic should get caught by the RFC1918 reject rule, this will act as a catch all if you've messed up something in your reject rules above.

                                Squid Transparent Proxy
                                If you are running squid and have enabled the transparent proxy on your guest subnet, you will need to add a rule to the OPT1 interface otherwise the traffic to the proxy will be blocked by the reject rules. The rule will need to be pass IPv4 TCP from OPT1 net to 127.0.0.1 port 3128 (or whatever your proxy port is). The rule will need to be placed above the reject rules.

                                EDIT: You will also want to ensure the option Bypass Proxy for Private Address Destination is selected under the squid transparent proxy configuration otherwise squid will forward HTTP requests from OPT1 to the LAN, bypassing the firewall rules.

                                @pfsensefanboy:

                                Oh really 'eh?

                                So if I temporarily disable Windows firewall on the OPT1-connected laptop, I should then be successful….I'm guessing!?

                                I guess this isn't something I should be worried about, correct?

                                Rather than disabling the firewall on the OPT1 connected laptop you can add a windows firewall rule on the laptop to allow ICMP traffic from your LAN subnet.

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pfsensefanboy
                                  last edited by

                                  Excellent suggestion @Derelict…I'll certainly try that out....but anyways, you were absolutely correct in your guess (that the Windows firewall - on the OPT1-connected laptop - will be blocking the ping request). Upon disabling the F/W, the ping was successful.

                                  @Kesawi, thanks for your suggestions as well. I'm gonna have to read, and then re-read them over (a few times at least) before I can understand and begin to apply them.

                                  Will post back if I have any further questions/clarifications.

                                  Cheers.

                                  1 Reply Last reply Reply Quote 0
                                  • DerelictD
                                    Derelict LAYER 8 Netgate
                                    last edited by

                                    @kesawi:

                                    This Firewall Reject Rule
                                    This rule isn't really needed as the RFC1918 rule above will catch all of the traffic to the firewall.

                                    Bzzt. Try webgui to your WAN IP from LAN. It is there for a reason. :)

                                    Allow OPT1 Anywhere Rule
                                    While this rule will work I would add  the RFC1918 alias to the destination and make sure the not box is ticked for the destination. If you've done it correctly the destination on the summary page will show as !RFC1918 for this rule. While traffic should get caught by the RFC1918 reject rule, this will act as a catch all if you've messed up something in your reject rules above.

                                    I personally cannot stand "not" pass rules. If you want to pass it, pass it. If you want to block it, block it. Don't pass "all but this." I know I'm in the minority here but I really can't stand them in almost all cases.

                                    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
                                    • kesawiK
                                      kesawi
                                      last edited by

                                      @Derelict:

                                      Bzzt. Try webgui to your WAN IP from LAN. It is there for a reason. :)

                                      Missed that :)

                                      I personally cannot stand "not" pass rules. If you want to pass it, pass it. If you want to block it, block it. Don't pass "all but this." I know I'm in the minority here but I really can't stand them in almost all cases.

                                      Each to their own. I prefer to write the pass rules so they are as standalone as possible in the event that I stuff up something I'm still covered (eg forget a block rule, or accidently put the block rule in the wrong place). So in this case I want to allow access to everywhere but private addresses, so I write the pass rule that way by including "not" so it doesn't need to rely on a block rule. As you say it's a personal preference and both a valid ways of doing things :)

                                      1 Reply Last reply Reply Quote 0
                                      • P
                                        pfsensefanboy
                                        last edited by

                                        @kesawi,

                                        Surprisingly, I was able to understand and apply most of your suggestions quite easily/quickly (I must be finally "getting it")!

                                        Having been a programmer (in my earlier days), I have written quite a few "!NOT" code blocks…so I do understand it, and don't mind using it. But I also get @Derelict's point, the KISS principle....since "!NOTs" can sometimes get quite confusing to debug.

                                        Would you please take a look at the new screenshot and let me know if I've correctly understood (and applied) your suggestions?

                                        Thanks guys!

                                        AmendedFirewallRules.jpg
                                        AmendedFirewallRules.jpg_thumb

                                        1 Reply Last reply Reply Quote 0
                                        • DerelictD
                                          Derelict LAYER 8 Netgate
                                          last edited by

                                          If all your local addresses are covered by the RFC1918 alias or on the firewall itself that looks fine.

                                          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
                                          • johnpozJ
                                            johnpoz LAYER 8 Global Moderator
                                            last edited by

                                            RFC1918 Alias
                                            Add the subnet 127.0.0.0/8 to the RFC1918 firewall alias

                                            What would be the point of this??  What traffic would it block??  I don't see how a interface is going to see inbound traffic to loopback space?  Could someone explain would be the purpose of doing such a thing?

                                            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
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.