Not sure where the issue is at…
-
i have a basic pfsense install, 3 interfaces, WAN, LAN, OPT1
2.2.4-RELEASE (i386)
built on Sat Jul 25 19:56:41 CDT 2015
FreeBSD 10.1-RELEASE-p15
nanobsd (4g)before attempting this new setup, everything is working as follows:
WAN- vr1
LAN- vr0
OPT1- vr2OPT1 has a wireless AP connected to it to provide guest wifi to the network, LAN has its own AP to provide wifi to the LAN users. the reason for my upgrade was to add a ubiquiti AP to provide wifi to LAN and OPT1 networks with a single unit and would allow for future expansion easier than my current setup. everything is working fine in this scenario.
my plan was to add a vlan switch, add some virtual interfaces for guest wifi, management wifi and IP cameras.
i added a switch and created some vlans, i feel confident that i tagged/untagged everything properly, but i could have made a mistake. prior to setting up any vlans, i was getting the 169 address on my two wireless networks, once i began tagging/untagging, i was able to get the correct IP address when connected to the respective wireless network. this tells me that the wireless device is connecting through the wireless AP which is talking to pfsense and pfsense was able to assign it an IP address. btw, the OPT1 interface is no longer connected to the old wireless AP unit and i am only running 3 vlans on that interface.
the issue i am having is that the wireless clients are not able to get to the internet. i verified that it wasn't a DNS issue by pinging 8.8.8.8 (no replies) and i did create a rule on both wlan subnets to allow all traffic to any.
i am not sure if i should check my vlan tags or if i am missing something in pfsense.
my lan network, which goes through un-tagged ports on the switch and then through pfsense, still works (internet and local lan), but i don't think my tagging is off. i am not on site, now, and it could be that i just forgot something minor. i will check and post back, but i wanted to start the thread in case someone notices something that i might have missed.
-
what rule did you create on opt1 vlans? Creating a rule for tcp only doesn't work as you need access to dns and that would explain why you can not ping. And explains why you get IP from dhcp.
Common mistake when users creating rules on new interface.. I copied the rule from lan but doesn't work ;) Well default rule on lan is any any, and they create a any rule but only tcp.
-
what rule did you create on opt1 vlans? Creating a rule for tcp only doesn't work as you need access to dns and that would explain why you can not ping. And explains why you get IP from dhcp.
Common mistake when users creating rules on new interface.. I copied the rule from lan but doesn't work ;) Well default rule on lan is any any, and they create a any rule but only tcp.
i will admit, i did miss the drop down on the TCP section and forgot to select any…. let me make that change and see if it works.
-
Uhm… I guess I'll file a bug about the default protocol. It's the same over and over and over again.
-
For sure dok ;) just like the default mask is 32 vs 24.. these are clearly bugs… WTF are these developers thinking?? ;)
-
Maybe defaulting to nothing in both of those places and failing validation until something is selected.
Seems better than defaulting to any.
-
-
@tdhuck:
what rule did you create on opt1 vlans? Creating a rule for tcp only doesn't work as you need access to dns and that would explain why you can not ping. And explains why you get IP from dhcp.
Common mistake when users creating rules on new interface.. I copied the rule from lan but doesn't work ;) Well default rule on lan is any any, and they create a any rule but only tcp.
i will admit, i did miss the drop down on the TCP section and forgot to select any…. let me make that change and see if it works.
this was the issue, when i changed it from TCP to any everything worked. the first rule i create is any to any just to make sure everything works, then i start fine tuning.
i need to pay attention to the details after comparing the site that was working and this new site, when selecting TCP (default option) the main rules page shows ipv4 and when you change TCP to any the rules page shows ipv4 * and it appears that i quickly looked at the two sites to make sure i had them right and i glanced right over the *.
thanks.
-
when you create a new opt interface and go to put an IP on it, it defaults to /32 vs /24
Have seen multiple threads where the IP is set to /32 vs whatever mask they want because it default to this in the dropdown list.
-
when you create a new opt interface and go to put an IP on it, it defaults to /32 vs /24
Have seen multiple threads where the IP is set to /32 vs whatever mask they want because it default to this in the dropdown list.Hmmm… it's doing some stupid countdown. Not really sure how to change it. If there's nothing configured, the first option value (32) will be selected.
<select name="subnet" class="formselect" id="subnet">for ($i = 32; $i > 0; $i--) { echo " <option value="\"{$i}\"" ";<br="">if ($i == $pconfig['subnet']) { echo "selected=\"selected\""; } echo ">" . $i . "</option>"; } ?></select> -
when you create a new opt interface and go to put an IP on it, it defaults to /32 vs /24
Have seen multiple threads where the IP is set to /32 vs whatever mask they want because it default to this in the dropdown list.
the /32 i catch and change to /24, usually i catch the TCP and change it to any, for my initial test, but this time i was comparing another side and just skipped over ipv4 * and ipv4 and assumed they matched.
i do think that it is best to have the TCP section set to none/empty and force an error on the page when you try to save the settings, that would force you to select the value and make sure it is set to what the user wants.
-
Doesn't really matter dok, I just lump it with the same thing with the tcp. Needs to default to something - guess you could have it default to non value like select or something. this would force the user to actively look and set it to what they want vs just skimming over it and leaving default.
I like the idea of error on page if you didn't change it from default which should be a non value.
-
Doesn't really matter dok, I just lump it with the same thing with the tcp. Needs to default to something - guess you could have it default to non value like select or something. this would force the user to actively look and set it to what they want vs just skimming over it and leaving default.
I like the idea of error on page if you didn't change it from default which should be a non value.
yup, i agree.
-
Hmmm… it's doing some stupid countdown. Not really sure how to change it. If there's nothing configured, the first option value (32) will be selected.
<select name="subnet" class="formselect" id="subnet">when you create a new opt interface and go to put an IP on it, it defaults to /32 vs /24Have seen multiple threads where the IP is set to /32 vs whatever mask they want because it default to this in the dropdown list.[/quote] for ($i = 32; $i > 0; $i--) { echo " <option value="\"{$i}\"" ";<br="">if ($i == $pconfig['subnet']) { echo "selected=\"selected\""; } echo ">" . $i . "</option>"; } ?></select>The countdown is just filling the SELECT drop-down control with a list of values from 32 down to 1. The way SELECT controls work in HTML is that the first value in the list is "default selected" when the control is displayed unless a specific entry is marked with the "selected" tag when it is added to the list. One way to fix this is to add a string like "Select a netmask" or something as the first entry added to the combo-control, and then adding the countdown values after it. If you did this, then some extra validation code would need to be added to the PHP code processing the SAVE button command.
Bill
