This setup doesn't make sense to me.

VLAN 30:

Assuming the pfSense sends tagged frames into port 1 of the switch, those frames are forwarded by the switch to port 3 and the tag will be removed on egress. On ingress of port 3, a tag with VID 30 is added to the frames, which will be forwarded to port 1 tagged and arrive at the pfSense port. So far, so good.

But for VLAN 1 aka "default VLAN":

Untagged frames from the pfSense 192.168.2.0 subnet are forwarded to port 3, too, since port 3 is a member of VLAN 1 (why?). Traffic coming from port 3 now will get tagged with VID 30 due to its PVID and being output on port 1 tagged, thus arriving in subnet 192.168.30.0.

Solution: Port 3 needs to be removed from VLAN 1.

Best practice: If port 1 is a trunk (= member of more than one VLAN), mark it tagged in all VLANs and ensure the pfSense handles tagged traffic onlyo both subnets. Forget about the "default VLAN", it's needed only for special purposes not applying to cases where both ends of a link are VLAN-aware.

Add port 1 as a tagged member to VLAN 1 and 30, remove port 3 from VLAN 1. Let ports 2, 4 and 5 untagged members in VLAN 1, port 3 an untagged member in VLAN 30. Assign subnet 192.168.2.0 to VLAN 1 in pfSense and subnet 192.168.30.0 to VLAN 30. Set up two DHCP pools, one for each network.

But I'm still not sure what you mean with »WLAN« on the pfSense <-> switch link and what exactly you want to achieve with moving the NAS away from the rest of the network. Are there more devices in the network than shown in the picture? If so, which one should be able to communicate with the NAS?

kiekar wrote

With your suggestion I removed from VLAN 1 port 3 which resulted with the NAS device getting a dhcp ip address from pfsense of 192.168.30.65 but unfortuneately I'm unable to connect to the device or ping it from the pfSense box.

 

I currently have only one VLAN interface, tag 30 setup in pfSense. If I understand you correctly I should setup another VLAN interface on pfSense (tag 1) for the wireless network subnet 192.168.2.0)?

Yes. Strictly speaking, you did set up this other VLAN already: it is VLAN 1, but you don't use tagged frames on both trunk ports (the pfSense port and the switch port 1).

Dealing with tagged and untagged frames on a trunk at the same time can become a nightmare if devices from different vendors are used since semantics between those devices often differ (thus, some devices have even three types of ports: "general", "trunk" and "access" ports, all of them not explicitly defined in the standard).

On Linux routers and servers, handling of untagged frames arriving on a trunk port is different compared to a trunk port of a switch: if eth0 is your physical interface and eth0.30 is your VLAN 30, you will see network traffic on VLAN 30 also on the raw physical interface eth0 together with untagged frames (this is a feature, not a bug). Therefore, to truly isolate VLAN 30 from VLAN 1 you need to create an eth0.1 interface on a Linux box, too.

General rule: It's best to always use tagging on a port which is member of more than one VLAN (so-called "trunk" ports) and to use untagged traffic on all other ports belonging to one VLAN only (so-called "access" ports), even on a switch.

Just imagine two pfSense boxes #1 and #2, two switches #1 and #2 and two separate networks #1 #2. To save costs for two routers, two switches and two cables in between you use VLANs. The router assigns two networks two VLANs, the cable carries this two VLANs and the switch separates the two VLANs while forwarding traffic to the devices connected to either VLAN. In the other direction the switch assigns two networks the two VLANs (using their PVIDs), sends traffic to the router, which then separates the two networks again. It's that simple, except that on Linux systems there is no PVID in kernel-based software VLANs.

If I would set up such a scheme, I would use VLAN 2 for network 192.168.2.0 and VLAN 30 for network 192.168.30.0 just for consistency. VLAN ID 1 can then be used as the PVID for the trunk port and for unused ports, effectively preventing untagged frames from being delivered to access ports, which are either in VLAN 2 (PVID: 2) or VLAN 30 (PVID: 30), but not on in the default VLAN.