Once again: no internet access for VLAN
-
I am confused now. I tried to follow the steps given in the link posted above. Why do I have to allow DNS to the OPT1 address in the OPT1 firewall rules? I thought the firewall would only block traffic between subnets, but OPT1 is the VLAN of the guest network. I changed this and included TCP. But please explain why this is necessary as a firewall rule.
Also, it seems that I misread the instructions in the link above. The allow ping rule was supposed to be to the OPT1 address as well. But then I have the same question, why do I have to allow traffic within OPT1 in the firewall rules. Sorry if these are dumb questions, I am just getting started with my network.
-
new screenshot of OPT1 firewall rules attached.
-
@art-mooney said in Once again: no internet access for VLAN:
I thought the firewall would only block traffic between subnets
Where did you get that misinformation from? And if you thought you can talk to opt1, why would you need to allow dns to lan address.. Just ask opt1 address, which is what gets handed out by default by dhcp
Without rules the firewall blocks EVERYTHING... The only thing that gets allowed when you create a new interface is if you enable dhcp.. That gets allowed via hidden rules - because if it didn't users wouldn't have a cow, etc. ;)
edit: those rules look sane. But your icmp rule desc is wrong.. That rule doesn't allow ping to lan
-
Thanks for your help. Don't know where the information came from. I think I read that one benefit of having VLANs with different subnets is that you can have a firewall in between to block traffic from guest to regular LAN.
If I understood you correctly, it is possible to block traffic between hosts of the same subnet with a firewall. But it is probably easier to configure, if guest and regular LAN are on different VLANs/subnets?
-
No you can not block traffic between clients on the same network..
Yes a benefit of firewall is firewall between vlans, but the firewall CAN block all traffic that goes to its interface... Even if going to its own address, any traffic that hits or goes through the interface can blocked or allowed.
-
got it. Thank you!
-
I just checked the guest network again and realized that internet access does not work properly. At first I was able to open some websites, but now my PC tells me that there is no internet on the respective wifi. I cannot ping the interface address, but I do get an IP from DHCP.
I use the same access point for my private network which works fine. Connection to pfsense seems to work (DHCP).
Any ideas?
-
@art-mooney said in Once again: no internet access for VLAN:
I use the same access point for my private network which works fine.
Well can your wireless client ping the opt1 IP? Can did do dns? it is using pfsense opt1 IP for dns?
Your not using a proxy are you? Because your blocking opt1 from talking to pfsense for everything other than dns, so proxy would not work with your current rules.
-
I just looked at my rules again and realized that ping and dns were allowed only from OPT1 address to OPT1 address. Changed it to source OPT1 network. Now it works. Does that make sense?
-
@art-mooney said in Once again: no internet access for VLAN:
Does that make sense?
Yep.
Have a look at this : Docs » pfSense » Firewall » Firewall Rule Basics
Read the definition of "LAN address".
I'll make you a special version :The IP address configured on the OPT1 interface under Interfaces > OPT1
Ok, so now you know what "OPT1 Address" means.
Did you get that strange feeling ?Now, let throttle up that feeling : have a look at this :
W'll be looking else where while you slap yourself in the face.
Btw : the counter in front of the rule, the green 0/0 indicate that the rule never applies. That is a big hint !!! 0/0 means : this rule does nothing. Use this info to test ! (always test !) : it should go up when you ping from the OPT1 LAN to somewhere outside OPT1 -> the rule was hit and/or 'used' (and passed the ICMP paquet).
-
Your right about the source being only opt1 good catch, I didn't catch that - sorry.
