@Bob-Dig Thanks Bob. The extra rules explained in the video did the trick.

@Gazza77 said in VLAN not able to get address from Windows DHCP server:

So it looks like the DHCP request is getting to the server but the reply is not getting back for some reason.

The packet capture shows a lot of initial FHCP Discovers coming from a device naming itself "DESKTOPPC" using MAC "54:bf:64:5f:78:73".

Dono what you mean by "server". The packet capture was running on pfSEnse, and thus the acktes captured reached pfSense. pfSense isn't a server.
I presume no DHCP server service was running on pfSense, so it didn't (couldn't) answer.
If there was a DHCP server on the LAN, answers from it would be send directly from it to the requesting "DESKTOPPC" and as these are not broadcast packets, pfSEnse wouldn't "see" them, so can't capture them.
But, after a discover the server shoudl answer right away - it didn't, so that explains the multiple DHCP DISCOVERS from "DESKTOPPC".

@dominikmorawietz Sounds like you want SDA or something with similar functionality. I don't think the functionality you're looking for is done at the firewall level. You'll likely need to implement something internally before it hits the firewall.

@Sergei_Shablovsky said in Mixed MTUs on different NIC's interfaces on same pfSense bare metal:

How different MTUs on physically different interfaces (if NIC are 2- or 4- head model) impact on NIC's overall performance (overall throughput, numbers of IRQs, etc...) ?

As mentioned before, there is no effect between different NICs. The only issue is there will be more work with smaller packets on the computer/switch/router. This is because those devices handle Ethernet frames as a whole. So, the smaller the MTU, the more frames that have to be handled and the more work for the CPU in those devices.

@algo7 said in Another vlan w/o network access issue:

It's always Netgear. Their VLAN configuration is always a PITA. Ran into almost the exact issue today.

What issue? There was nothing wrong with Netgear, just the port assignments...

@patient0 said in Beginner - N2000 how to set port 4 to it's own network?:

That's very odd, it's a valid range and does have to work. If both the LAN1 and OPT1 are set to /24 they are not overlapping. And if neither the WAN nor the network being your parents AP are using the same IP range, then it should work.

I agree that it's odd and now that it's working I'm hesitant to mess with it again. I guess I could always backup my configuration, break it and then put it back to what I know works.

@cesarin En esta parte del foro el idioma es el inglés. Hay una parte en español de este foro: https://forum.netgate.com/category/11/espa%C3%B1ol.

O puedes escribir en inglés si eres capaz.

If you like to go on in English: What is the pfSense version that is in use and what is the device you run pfSense on? Is the pfSense device connected to a network switch?

From your description: there is a network named "LAN" on network interface igb1 (192.168.150.10/24) and a network named VOIP on VLAN 155 with parent interface igb1 (192.168.155.1/24).
And you have to restart the VOIP interface to make it work again? How long does it work before you have to restart the interface?

I'm not sure where to post this, as there are dozens of threads out there on this subject. They all involve some combination of Avahi, IGMP Proxy, Firewall rule changing, jumping jacks, yak shaving, and singing ring-around-the-rosie. And they all seemed to work for whoever posted them, at the time they posted them.

But they never work for me and I really have no idea how they actually worked for anyone else either. Maybe other factors were involved at the time, but I have no idea.

This is probably because Sonos discovery works by making an SSDP broadcast to the local subnet, and doesn't really use any of that other stuff. (Its been a long time since I looked at Sonos behavior in a packet sniffer, so I'll admit its possible it may have involved packets for those other protocols too at various points.) But really, the only solution is to relay those broadcast packets.

In any case, I finally found a solution last night that actually worked. It basically involved installing the "UDP Broadcast Relay" pfSense package, then configuring the two rules mentioned in this Reddit post:

https://www.reddit.com/r/PFSENSE/comments/rfs99r/setting_up_sonos_speakers_with_vlans_how_i_got/

(At the time I had Avahi enabled, but didn't have IGMP Proxy enabled, and my firewall was already configured to allow packets to pass between the VLANs. So I make no promises as to whether other stuff is also necessary.)

So I just want to drop this comment here, on the off chance it helps someone else in the future.

@NGUSER6947

TL DR - Don't use VLANs when a firewall alias is the more appropriate solution.

You don't want to get too granular with your VLANs IMHO. I think most home networks only need 3 VLANs.

1 - a "Secure" VLAN for the router/firewall device itself and other network equipment, as well as all of your personal data. This likely includes most of your personal computers/laptops, network storage devices, etc, but it does NOT include personal mobile devices like phones and tablets. Devices on this VLAN should be able to access any other VLAN.

2 - a "No Internet" VLAN for any device that doesn't need internet access. This might include a lot of the automation devices in your network, CCTV cameras, any network printers, etc etc. Of course the VLAN not having internet doesn't mean you won't be able to access these devices either locally or remotely (over a VPN connection), because you will still be able to do that if setup that way. Devices on this VLAN shouldn't have access to any other VLAN.

3 - an "Everything else" VLAN for........ you guessed it......... everything else (ie your media servers, smart TVs, mobile devices, etc.) Basically anything that needs an internet connection but isn't "secure" enough, or has no reason to be accessing your personal data (which resides on the "Secure" VLAN) needs to go on this VLAN. Not only do your personal mobile devices need to be on this VLAN for security reasons, it's also easier to cast/stream to the media servers when everything is on the same VLAN. Honestly the vast majority of your devices will likely fall onto this VLAN. Devices on this VLAN would have access to the "No Internet" VLAN only.

When you have just a small number of devices that you want to handle differently, this is when you can/should create firewall "aliases" and control groups of devices this way. Most of the time an alias is a better way to manage the devices than a full blown VLAN IMHO. So no, I would not create an "Entertainment VLAN" because that is getting too granular with your VLANs, but I probably would create an "entertainment" firewall alias if I wanted to handle those devices differently when it comes to ad blocking, rules, or other typical firewall activities.

PS - I know a lot of people want to have a "Guest" wireless network/vlan but that isn't actually needed most of the time now that your guests are generally going to have a mobile phone and mobile internet service that works well. Perhaps if your home is located in a cellular "dead spot" this would be helpful to your guests, otherwise it really isn't needed. I know that I initially created a guest network and it was only used perhaps twice over about a 5 year period, so I eventually did away with it. Having a guest network that isn't actually used/needed is nothing but a security risk that should be eliminated.

@patient0 said in Creating VLANs with 802.1q VLAN Mode and Network Port Lagg0:

https://docs.netgate.com/pfsense/en/latest/solutions/xg-7100-1u/configuring-the-switch-ports.html

Awesome. I did not pick this up. Total legend !!

I added ports 9 and 10 which has resolved the issue.

b745177b-2681-4ef0-b993-48f4e7ebe815-image.png

@nmpuk where are the corrections - that diagram makes no sense..

DMZFW—intLan2 / 10.0.13.1/24 (Vlan3) — AppServ intLan3 / 10.0.12.1/24 (Vlan4) | IntLan4 / 10.0.12.2/24 (Vlan5) InnerFW

And here you have the same network in 2 different vlans? and then also '

Assigning vlans works just fine during first setup.. But it's never going to work like you have it drawn.

If you can't take the time to actually draw up correctly what you want - how is anyone going to help you.

So your going to have 3 firewalls running on a VM.. Why would you need to setup vlans in the first place in pfsense? Vlans are when traffic is tagged.. Just put your different interfaces in different port groups.. No real reason to tag anything on pfsense. Only place you would might need to tag is when leaving the vm host, and again no reason to tag that in pfsense. You could but then the port group on your vm host would need to be set to pass the tags.

@johnpoz Yes, I noticed that as well, so clearly things are working fine with NC and port forwards.

You prob want to look into using acme (lets encrypt) to get a valid cert for whatever the fqdn that points to your public IP via your ddns entries.

@dkthedriftking
So take a look at HAProxy and try to set it up so that you secure your setup with a real signed certificate. Alternatively, perhaps depending on how you installed NextCloud on that machine... is it virtualized? You could install Nginx Proxy Manager which it likely even simpler to set up for this purpose, and other future servers.

I lost my mind with this vlan and made it simple. Removed vlan70 from pfsense and assigned for that parent interface ip in subnet 10.10.70.
Interface is uplink for DMZ vswitch and port group in exs. So I will put all DMZ vm's in that port group.

@jinxed50 without you actually showing us what you did - impossible to know what part you missed or did wrong..

Users all the time say they did X - and what they actually did was X-2(y^7)+Z-(4Q)

@marvosa Hello!

I got it working a few days after initially posting here and asked the mods to delete the entire thread so people dont reply to a topic already resolved. I think they misunderstood and instead deleted my second reply to this topic. Doesnt matter now, if this thread can help people in the future or if someone replies with questions I will be glad to share/help as much as I can!

While you replied I can tell you how I got it working.

As of now, ports 23-24 are members of VLAN 210. Port config is set to accept "All" traffic (so untagged) and set to assign PVID (VLAN) 210 (since the ports are member of that VLAN).

It is pretty much the same as I initially had except that between then and now, I had to reinstall pfsense completely (due to hardware failure, probably irrelevant to my VLAN issue anyways) and reset the procurve switch to defaults.

The only thing that changed is that port 1 on the switch is set to ALL and PVID1 where as before I had it "TAGGED" with PVID "None". Mind you, the screenshots in my original post were based on old VLAN tests I did few years back when I was even more clueless than I am today ;)

Right now switch is configured with 5 VLANs, each ports Set to "ALL" traffic and the proper PVID's set for each port. Machines connected to the ports are now getting IP's from pfsense under the proper subnet and all seems to be working just fine.

f726d091-ee19-4833-8e07-838fd1480f26-image.png

@johnpoz aha! The rollback was just what I needed. Thank you!