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. [image: 1736255227244-f726d091-ee19-4833-8e07-838fd1480f26-image.png]

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

@CatSpecial202 That looks correct to me.

@sic0048 well articulated and great points..

@FWright Your option b wouldn't work. If your untagged network on pfsense is 192.168.10/24 then why would you think you could create a vlan with that same network.. You have few ways to go about this, either change your pfsense untagged network to something other than 192.168.10 or change your vlan 10 IP range.. I too like using an vlan ID that matches up with the 3rd octet.. its an easy way to remember what the vlan ID and network is.. Why not use say 192.168.30/24 vs 10, and use the vlan ID 30. You could change your untagged network to say 10.10.10 or 172.16.10/24 and then you could use 192.168.10 on your vlan 10. Or use one of those other network on your vlan 10.. As mentioned its not actually the vlan 10 that is the problem, its that you have overlapping networks.

@JKnott said in /30 network - This IPv4 address is the network address: Linux & Cisco do. I had no luck with that on Debian but maybe I did something wrong. And I did not try elsewhere so you are most probably right.

@NGUSER6947 Yes but things seem to pop up, at least in discussions. I had it crash a few months back and it didn't want to restart due to a lock file lingering, so changed back. But I also have it running on another instance on CE where it's been working fine...

@keyser Put it in a new file /boot/loader.conf.local That way it will survive pfSense upgrades. I personally install nano to make small file edits via SSH CLI pkg install nano

Hmm. I was under the impression that WiFi 6 was 802.11ac. Apparently, it's 802.11ax. My bad!

I just wanted to follow up after having had some time to test and tinker. @johnpoz : Thanks for your help and patience! Your insight was invaluable. RECAP : Issue My original issue was identified by the supposed failure of pings to traverse through pfSense between two devices on different networks (ex. 192.168.11.xx and 192.168.12.xx). RECAP : Issue No.1 : Windows Firewall Behavior Important issue no.1 didn't have anything to do with pfSense or, for that matter, with the network in general. Windows firewall blocks ICMP Echo requests and this behavior seems to continue even with the firewall turned off in the Control Panel. The weird part with this issue is that both pfSense AND the managed switch could ping both computers. The issue was revealed when the computers could not ping each other (pings timed out). The simplest way to fix this behavior is to add an Allow Rule to Windows Firewall for ICMP behavior. Just... make sure to turn it off before using those test machines elsewhere. RECAP : Issue No.2 : pfSense DHCP Important issue no.2 had to do with weird behavior from the DHCP service on my pfSense machine. I cannot say if this is the result of a bug. I would have to do further testing (which I may follow up on later). This was described by johnpoz as : "if your device... doesn't have a gateway, then you would never be able to talk to it from some other network." Or even simpler : No door (gateway), no exit. This issue was revealed by the ping attempt on one of the computers throwing a "General Failure" error when trying to ping the other computer. Investigation of ipconfig results confirmed the issue (missing network gateway). The proposed solution that fixed the issue was simply to enter a value in the DHCP configuration screen : Other DHCP Options/Gateway. Adding a value here propagated to the two testing machines. The value I used was the IP address of the associated firewall interface (... the default value...). Fin That's it. Pings between the two computers works as expected, even when they are in different networks. The ping works in both directions. Thanks again!

@MoonLight-0 only if your switches supports stacking and can be stacked to one logical switch where you create an identical lagg of 4 ports (one from each switch). If they do not stack you cannot use LAGG as an interface aggregation method accross switches.

@Gblenn said in Switching from igc1 -> ic0 as physical interface starts well and then collapses: Use the topology mapping in Unifi Controller as support as well. It might give you some ideas of where things may be messed up.. issue when the wheels come off my Unifi manager is not reachable... Only switch this is internal static assigned is the ProMax... will remove that and do a static assign on the pfSense... was actually thinking the current config, by the switch is told you are 172.16.10.2, irrespective which port is used for uplink... if anything... i would have expected more problems when the Cat6/2.5 GbE and fiber was patch / active into the pfSense... as it would not have known who is the uplink... Will give all of this a try. G

@mlradioguy firewall rules have nothing to do with, once you enable the dhcp server hidden rules are created that will allow dhcp. Are you seeing dhcp discovery/requests on pfsense? What does the dhcp log say, sniff on pfsense different interfaces are you seeing the dhcp? if you set static, can you ping pfsense IP, do you even see arp entry in your clients for pfsense IP..

Man that does sound like a pain. It also doesn't sound possible to really do per app tunneling like a dedicated VPN app can do particularly for things like web browsers whereas with something like Sweech that uses a narrow host address range plus a specific port number, it would be a piece of cake. I suppose I'd have to keep the desktop app for the PC, but the phone should be ok with it since it's just one app that needs to be configured.