@Derelict - It worked as expected on the Macbook (must be config issue on my Linux laptop). Thanks.

our lead mentioned that it's a layer 2 switch and that vlan doesn't reside on that layer 2 network

This means the switch is implemented at layer 2 only... i.e. either routing is disabled or the functionality doesn't exist on that particular switch. Without knowing more about the design, we can only offer generalities, but most likely your layer 2 switch has an uplink that is trunked to either a distribution stack or a router. There are various solutions, but what your lead most likely meant was since the VLAN doesn't exist on the switch, it will need to be built out from the distribution out to the access layer.

In other words, the VLAN needed to be added to the layer 2 switch and then allowed over the trunk (on both sides).

edit:
on the SG-3100 I have determined that I did not have the switch ports assigned/enabled to any vlans and after that it gave me DHCP on the lan ports and vlans. however I am still with the issue of some devices getting IP's and some not, on the same laptop over Wi-Fi nothing wired something. My travel AP does not support vlans so it has to be on the base level. and none of my non-Mac computers seem to be getting DHCP. And I don't know what caused it but I managed to crash my old router and ALL INTERNETs last night plugging in the new one to do a test. I went out and bought 4 manageed switches so I could break out all of my VLANs to test, and it was the only ez way to solve ingesting my multiple travel WAN VLANS ( local lan, Wi-Fi, Wi-Fi hotspot, wired LTE modem).

I found a workaround and I don't need to do this anymore, I'm still doing a link/trunkofsorts between two devices but now it's a transit network, not a dozen bridged broadcast domains..in software! Can you imagine the CPU from that--gawdd.

Still, if you're feeling charitable and could confirm if a parent can be bridged without filtering its children just for my curiosity, that'd be awesome.

No keyboard necessary, I'll help you help me, copy/paste checkmark [ ✔︎ ] for "yes they can be bridged alright, shut up already." Cross. ..mark? [ ✘ ] for no, it's per 1 bridge per VLAN (or mixed VLANs in 1 collision domain)

🤓 🔪 The Emoji panel should have network equipment like Visio. Maybe if I say it enough it happens--anybody know blackmagic, not the brand. 😂

Some extra info:
I am running 2.4.5-RELEASE-p1 (amd64)

If I move the vlan interfaces away from the 10G copper (ix0) onto the built-in 1G lagg0 (the internal switch), then connectivity is stable
I followed advises here https://docs.netgate.com/pfsense/en/latest/hardware/tune.html#intel-ix-4-cards so my /boot/loader.conf.local currently looks like:

hw.intr_storm_threshold=10000 hw.ix.flow_control=0

The below is advised in the doc but was already in /boot/loader.conf:

kern.ipc.nmbclusters="1000000" kern.ipc.nmbjumbop="524288"

TSO/LRO and hardware checksum are all disabled from the GUI.

On latency: even though my WAN connection (pppoe) is on another NIC (ix5), it has increased latency beyond the avg for this link (rtt around 40ms, rttsd about 80ms).
The latency goes away if I stop using the 10G port and move my server on a 1G port of the built-in switch of the XG-7100 (connected via LAGG0).

When the physical interface ix0 is going down, other physical interfaces are still online and the pfsense box is still reachable via other logical interface (ie via some vlan interface over the lagg0 built-in switch).

@johnpoz said in DNS Resolution/Routing Issue on VLAN:

Oh good catch ;)

Yeah client will say that is BAD.. Are you doing some sort of source nat?

I suspected the reply from the resolver's other IP was problematic and thought I had indicated that in my original post. My apologies for wasting cycles having been unclear on that. Additionally, I am not doing any source or outbound NAT anywhere.

@viragomann said in DNS Resolution/Routing Issue on VLAN:

So the client is requesting the LAN IP, but pfSense is sending responses from the VLAN IP. Hence the client won't accept the response and the DNS request is failing.

That's not the default behavior, even in a setup like yours. But I have no idea, what could be the reason for this.
Possibly you have something miss-configurated with the VLAN or do a kind of outbound NAT?

However, as I suggested above, simply use the VLAN IP as DNS on the clients and your headache will be gone.

The VLAN is pretty simply configured on pfSense and both downstream switches. I've pored over each config for hours now. I can't find anything in them that leads me back to this issue. Why is pfSense/unbound coming back to that network through the other interface? Ugh.

I suppose I'll acquiesce to changing the DNS configs on that VLAN to query unbound on the VLAN200 interface rather than LAN. That won't bode well for my curiosity, but sometimes you have to admit defeat.

It started working even though I haven't changed anything in my config.

🤷

@imark77 going by the hardware in the handle. I'm assuming the SuperMicro has for dedicated ports. If that's the case you'll need to create your desired VLANs on each hardware Port ID and then bridge those VLANs acrossed back together. And then a firewall rule to allow them to intercommunicate. ( Theoretically switching to rules on bridge would make the rules easier but I don't recommend that until I can confirm that it works on my end.... As that seems to be the problem I'm having ).

@bingo600 said in Making Best Use of Physical NICs & VLANs:

You should only have ONE dhcp server (per vlan) active at any time.
Else you risk getting overlapping leases.

Actually, multiple DHCP servers are permitted. While you can configure them with non-overlapping pools, Duplicate Address Detection is supposed to be used to avoid problems.

Or even no switch at all. Like daisy chain the AP's with their internal multipleLAN ports. Which, ok, are actually switches.

Be definition, a switch that does not have an IP for itself, no GUI or console access, is a 'dumb' switch, like a smart hub. You can not interact with it. It will operate on MAC level at max, not IP.

Btw : I don't get it.
It took you a minute to create a (example) VLAN ID 100 on pfSense.
It takes a minute to set up a device (= AP, or whatever) with a static IP setup for this VLAN100 (which means the IP should be in the VLAN100 network, the gateway should point to the VLAN100 pfSense IP - same thing for its DNS).
Set up also the VLAN ID for your 'LAN' on the AP - if the AP supports VLAN.

Hook up the AP, and analyse the traffic with firewall rules that log, or the packet sniffer or whatever, to assure yourself that LAN and VLAN traffic is separated.

Or .... apply the keep-it-simple rule : take a 5 $ third NIC, create your physical separated wired LAN, hook up your switch and on the switch the 5 AP's and you can pas on to other things ;)

No again you don't have to set routes for anything connected to pfsense directly.

If you want to send a client out a vpn connection (vpn setup on pfsense to point to some service)

Then you would just policy route that via a firewall rule. Just making sure that you put any rules above that to allow local access (if you want)..

If you want to send clients trying to talk to 1.2.3.4 (publicIP) then sure you could create a route on pfsense for that dest network to use vpn connection. But that would really send any and all clients from behind pfsense out that vpn.

Better option is to just policy route what you want to use the vpn. Be it via either their IP/Net, dest IP/net or dest port, etc.

https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html

Setting up a vpn client on pfsense creates a multiwan setup.. Since you have either your normal wan as gateway, or this vpn connection as a gateway.

indeed, it's an internal switch after all, you must use vlans

emp0s3 is using vlanid30 but i'm not so sure about igb0.30
sorry it's only what is coming on my mind could be stupid, as I'm not in front of your stuff and i don't own a microtick i can't tell you exactly where to look but if i was me i will trace back until i see where the vlan30 stop working, tcpdump also can help

@rjamesm Do you have the VLANs selected in pfBlocker? By default it only selects the LAN. If you also want it to do the VLANs you'll need to add it under the IP tab.

@johnpoz thanks. I added any any for opt1.

@johnpoz

Luckily i'm in a controlled environment where only PC's and Desktop Phones approved by (me) are allowed to have access via WiFi.

No phones or personal devices are allowed on that segment.

/Bingo

@pfsenseuser2020 Looks like ports 137 and 138 are Netbios and/or Windows File Sharing CIFS ports. Do you maybe have a NAS or file server that's misbehaving, or infected?

https://library.netapp.com/ecmdocs/ECMP1155586/html/GUID-4645E16A-6CB1-4A71-8420-05749894E857.html

https://forum.netgate.com/topic/83433/log-flooded-with-port-137-138-udp

But, I agree with @kiokoman, if possible, turn it off at the host's network card.

Jeff

@marvosa Yeah, it's a typo 192.168.x.0, the "x" is the VLAN #. For some reason I can't reliably edit my post, nor can I post comments it keeps telling me "Post content was flagged as spam by Akismet.com"... This forum really needs to address that...

I have solved this problem. I had a floating rule that blocked private ranges, which of course was blocking subnet -> subnet routing.