4. Question regards setup of a Guest WiFi

Question regards setup of a Guest WiFi

  • P

    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.

    0

  • 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.

    0
  • Netgate

    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)

    0
  • P

    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.

    0
  • P

    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.

    0
  • Netgate

    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.


    0
  • P

    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.


    0
  • Netgate

    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.

    0
  • P

    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.


    0
  • Netgate

    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.

    0
  • P

    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  :-[

    0
  • Netgate

    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.

    0
  • P

    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?

    0
  • K

    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.

    0
  • P

    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.

    0
  • Netgate

    @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.

    0
  • K

    @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 :)

    0
  • P

    @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!


    0
  • Netgate

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

    0
  • Rebel Alliance Global Moderator

    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?

    0
  • P

    It's interesting, and quite timely (I must admit) that this question/doubt about subnet 127.0.0.0/8 (in relation to RFC1918) has reared its ugly head…..since I was anyways about to post a question asking if other subnets should also be blocked.

    I ask this because I came across an excerpt (from a book on VOIP Security - see attached image) that mentions a whole bunch of subnets which must be blocked....and 127.0.0.0/8 is certainly one of them.  I do plan on having a RasPi running RasPBX behind my firewall.

    My RFC1918 alias currently has the following subnets included (the last one was added just last night):

    • 192.168.0.0/16

    • 172.16.0.0

    • 10.0.0.0

    • 127.0.0.0

    The book mentions that the following subnets must also be included (refer to attached image for description of each subnet):

    • 0.0.0.018

    • 169.254.0.0/16

    • 192.0.2.0/24

    • 224.0.0.0/4

    • 240.0.0.0/5

    • 248.0.0.0/5

    • 255.255.255.255/32

    Makes sense, or hogwash?

    Thanks.


    0
  • S

    Also one thing you do wrong is the router IPs.
    If the pfsense firewall itself do have 192.168.1.1 and 192.168.2.1, you CANNOT have the routers/AP's have the same IP. Then you will get a randomly unstable connection since roughtly half of the time, the router will reply on something the firewall should reply on.

    The routers/AP's should preferable use 192.168.1.2 and 192.168.2.2.

    So if the WRT54G really has the IP 192.168.2.1, you are getting a IP collision in your network, and thats why you get "Unstable connection" inside Android.

    So what you should do:
    LAN = 192.168.1.1
    OPT1 = 192.168.2.1

    Linksys = 192.168.1.2
    WRT54G = 192.168.2.2

    0
 

Products

Applications

Support

Services

News

Resources

Company

Our Mission

As host of the pfSense open source firewall project, Netgate believes in enhancing network connectivity that maintains both security and privacy. We also believe everyone should be able to afford it.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy