Question regards setup of a Guest WiFi
-
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.
-
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.
-
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. -
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 :-[
-
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.
-
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?
-
A couple of additional suggestions:
RFC1918 Alias
Add the subnet 127.0.0.0/8 to the RFC1918 firewall aliasDNS 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.
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.
-
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.
-
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.
-
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 :)
-
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!
-
If all your local addresses are covered by the RFC1918 alias or on the firewall itself that looks fine.
-
RFC1918 Alias
Add the subnet 127.0.0.0/8 to the RFC1918 firewall aliasWhat 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?
-
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.
-
-
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.1Linksys = 192.168.1.2
WRT54G = 192.168.2.2
