New book: VLANS in pfSense for absolute non-technical noobs
-
You can't plug the Ubiquity into an unmanaged switch and expect VLAN tags from the access point to be maintained.
It's quite possible that the one VLAN that's working is actually functioning as untagged on the default VLAN after going through the unmanaged switch (and possibly the powerline adapters, as I mentioned earlier.)
Thank you for your reply ;D
Yes, I found it very plausible that it isn't possible, I agree with you.
Is there a way for me to find out if it is currently doing what you say it is doing? What should I look for in the HP Switch configuration screens? (I know it sounds dumb, but I am rather very dumb when it comes to this subject :-[).
Thank you ;D
EDIT: forgot: I have no problem buying a new managed switch for downstairs, but that will still not solve the fact that the switch then travels via powerline.
-
The powerline is nothing else but a network cable in another form… It shouldnt alter the traffic unless routing or otherwise is a part of the equation.
To get VLAN's working you need to set the same VLAN's on the switch with the same tags as the ones on your Pfsense. Simples.
Then it transfers the tagging and traffic across with no issues. I have about 600 VLAN's running here on 2 physical HP switches configured for failover.
-
The powerline is nothing else but a network cable in another form… It shouldnt alter the traffic unless routing or otherwise is a part of the equation.
To get VLAN's working you need to set the same VLAN's on the switch with the same tags as the ones on your Pfsense. Simples.
Then it transfers the tagging and traffic across with no issues. I have about 600 VLAN's running here on 2 physical HP switches configured for failover.
Thank you for your reply Supermule ;D
Just to be make sure I completely understand you: you are saying that only a managed switch downstairs is sufficient? So powerline is not a problem (as that was written before)?
EDIT: But still I should need to find out why it appears to working right now then, even 'though the laws of dictate it shouldn't.
Thank you ;D
-
You can't plug the Ubiquity into an unmanaged switch and expect VLAN tags from the access point to be maintained.
[snip]
It's quite possible that the one VLAN that's working is actually functioning as untagged on the default VLAN after going through the unmanaged switch (and possibly the powerline adapters, as I mentioned earlier.)
I discussed with WIFE, who is sysadmin of BRAINS, and she posed an interesting question. If what you say is true (which we interpret as 'the VLAN-tag data is 'stripped' from the packets by the unmanaged switch, so before it arrives at pfSense), then how come that they get an IP-address in the VLAN-range from pfSense, and not an IP-address in the LAN-range?
Like said:
Laptop, wireless via WAP -> 192.168.7.10
Laptop, wired via HP-switch -> 192.168.2.10 -
@Hollander:
I discussed with WIFE, who is sysadmin of BRAINS, and she posed an interesting question. If what you say is true (which we interpret as 'the VLAN-tag data is 'stripped' from the packets by the unmanaged switch, so before it arrives at pfSense), then how come that they get an IP-address in the VLAN-range from pfSense, and not an IP-address in the LAN-range?
Like said:
Laptop, wireless via WAP -> 192.168.7.10
Laptop, wired via HP-switch -> 192.168.2.10Update, just to be absolutely sure I wasn't misunderstanding what I was seeing, I tested one final thing:
- My hardware setup was this:
–- Upstairs: pfSense -> HP switch -> LAN, all wired
-------Upstairs, one Ubiquity WAP, wired to the HP switch, VLAN70.
--- Downstairs: the other Ubiquity WAP -> unmanaged cheap switch -> powerline -> to upstairs -> HP switch
-------Downstairs WAP = also VLAN70 (you tag this in the WAP).
Now, both Ubiquities do something together called 'seamless roaming', whereas when you move around between the two WAPs they will transfer you between them.
So what I could think of was that because WAP upstairs is VLAN70 and hardwired to the HP Switch (which had that port tagged as VLAN70), the 'seamless roaming' for some magically reason also made it possible that the WAP downstairs for some reason to be on VLAN70.
So I shut down WAP upstairs, and enabled only WAP downstairs. So there is no, by no means, connection from WAP downstairs to the HP switch other than where the powerline connection from downstairs enters the HP switch.
Still, WAP downstairs remains VLAN70, and so do the smartphone and the laptop, with their corresponding VLAN70 IP's (192.168.7.x, and not the LAN IP's of 192.168.2.x).
So, for whatever reason, WAP downstairs, via unmanaged switch and powerline, is capable of being in VLAN70.
I don't know why, and you all do know 1000 times more about this than I do, I am just telling you what is happening here ;D
- My hardware setup was this:
-
Lets be sure we're talking about the same thing…
(Edit: I just dug up those powerline adapters and put them on the bench. They pass VLAN tags just fine and pass unfragmented ICMP at a full 1472 so I don't know what I was seeing before. Unmanaged switch is still not what you want.)
-
That is the diagram I imagined also. If the dumb switch and powerline devices are really good and dumb, then they can just pass ethernet frames blindly between source and destination MAC addresses and the smart AP with multi-SSID and VLAN knowledge should effectively have a pipe to the HP smart switch with the corresponding VLANs trunked. (and untagged frames from other devices downstairs would also happily arrive untagged at the HP switch and the HP switch can be configured to put them in a selected VLAN.)
But, if they are not dumb enough then they might mess with the VLAN packets.
Given all of that, if the VLAN70 configuration works, then so should VLAN60. -
But they might pass frames at 1518 (MTU 1500) and discard at 1522 (MTU 1500 + dot1q). "it depends."
Get a dot1q switch.
They're US$60.
-
Thanks Phil ;D
And thanks Derelict ;D And you I would like to ask: but what is the problem with my current setup then? I mean: it appears to be working(?)
-
Glad it's working. Sounded like you were still having issues.
-
I finally got the second VLAN to work also. The workaround I had to apply was to tell WIFE I wouldn't be eating her food anymore if she didn't fix the tagging of the port in the HP switch ;D ;D ;D
Looking at the firewall log I just noticed something I don't understand (as with many things in life :P). Per the attached screenshot: why, if it the default deny rule, does the log say src = VLAN? I would have expected this rule to block anything coming from WAN as a 'default deny', so src = WAN, dst = VLAN, not the other way around as it shows now ???
That VLAN-IP by the way is an Asus Android tablet, and looking at the dst-ip it was busy phoning home to Google that I was doing something that absolutely needs to be stored in Google's big nsa-database for future usage ;D
-
:( :o ??? :-[ :-\ :'(
( ;D).
I am lost. Having finally gotten the VLANs to work, it appears I can not go from VLAN to LAN. I have the pfSense book but it also doesn't tell me :'(
What I am trying to accomplish:
1. I have a HTPC (XBMC) in LAN (192.168.2.x)
2. I have a tablet in VLAN50 and a HTC phone in VLAN40, both running android 4.2.
3. I want to use the app 'Yatse' (very nice app by the way) to use my tablet/smartphone to start/stop music (so I don't need to turn on the TV to play music).For the life of it, I can not get it to work. It appears Squidguard is messing around, and so is Snort. Disabling them gives me a 504 error in Android (kind of cryptic, but [s]NSA Google told me this is a 'gateway time out'.
Both the tablet and the smartphone can happily go on the internet, by the way.
I think I have the VLAN, the DHCP-server on each VLAN, and the firewall rules setup correctly. I attached screenshots.
Something weird did happen before: while setting up VLAN50, for some reason in the status dashboard another gateway turned up for VLAN50 (in the dashboard widget for the gateway). However, that did not turn up when I configured VLAN40.
To be honest, I have no clue about gateways, other that, per the wiki, 'they are used to transfer traffic from one network to the other'.
At the same time, while searching for a solution, I found this comment of Jimp:
Is pfSense actually the current default gateway for all of the devices in those networks?
If you interfaces are set right (correct IP, correct subnet mask), the rules are right, and the firewall is actually the default gateway for everything, then traffic will flow through.
I am not completely sure that I understand what Jimps writes, but in System/Routing my WAN is the default gateway, so I assume that is not pfSense in the way Jimp is talking about this. This also is how the installer did it, I didn't change it (I don't dare to ;D).
Also, in here:
http://forum.pfsense.org/index.php?topic=68043.0
Podilarius writes:
Few things just to check:
Is firewalling turned off (as in it is working in routing mode)? This option is in the advanced section.
Did you create a new allow all rule on the VLAN tab?
Did you switch to manual outbound nat BEFORE setting up the VLAN? (in which case you would need to add the NAT).
If in router mode, did you allow traffic from that VLAN in on the LAN on the WRAP?Which makes me wonder if I need to add 'something' in System/routing for each VLAN, and if so: what?
(Sorry, I know I ask stupid questions, but I am not an IT-specialist but only a rather stupid accountant, and I do try very hard to find my own answers on the internet and in books :'().
Would anybody be willing to help me out of my suffering?
Thank you very much in advance for help ;D
Bye,
http://forum.pfsense.org/index.php?topic=63397.0
-
More pictures:
-
More pictures:
-
More pictures:
-
More pictures:
-
More pictures:
-
More pictures:
-
And to think that the day after tomorrow my second ISP-line (cable) will arrive which I will have to configure for dual WAN with failover. I am sure that means new stress ;D
-
192.168.5.0 as your address? .0 is the wire not really a valid address.
Also your rules only allow specific host to specific host - but not able to talk to the pfsense interface on that vlan. So there is no way for dns queries for one.