@johnpoz I'm not in this forum to argue choices. My opinion why I started my question: home labs and networking should be fun and exiting. Not hindered by opinions but learned through experimenting based on knowledge and curiosity. IT constantly changes, what was impossible yesterday is the standard of today. And I understand that one can get tired of all those fools that are trying to find solutions to experiment with. But I didn't ask for my use case to be solved, just to explore ways that would work and could create more fun. So yes, I would like to experiment with my idea and find out where I'm wrong. I would like to play around. And I would like to do that with curious people who also love making fun with networking. Why would I otherwise get pfsense, could have gone for refurbished cisco as well (but that is less fun). And a good starting point to me is: join the community and build a group of people that share the curiosity and perhaps are steps ahead. Does that make sense or should I explain myself better?

I figured it out. My any any * * ipv4 rule did not include icmp so my pings (which I was using to determine if traffic was flowing) were being blocked. Now I know IPv4 * does not include IPV4 ICMP

@rcoleman-netgate Finally got a chance to play around a little more and its working as it should so all I can assume is that Im an idiot and after looking at the screen so long the other day I was misstyping and couldnt see it. 4 devices all set with their static IP's on the Home VLAN. They can ping between each other, can ping 8.8.8.8 and can ping www.google.com Next time I get a chance to play around, I'll start trying t set up some better (more secure) firewall rules and other general security tweaks.

Edit3: Finally the things have worked. What I did based on @jasonlitka post on another thread. I open up the cli to check the running config file on the ports 3 and 36. I have cleaned all the configurations on each port. So the configurations are below: Switch01 Core(config)#do show running-config interface GigabitEthernet1/0/03 interface gigabitethernet1/0/3 description "Live Esquerda" switchport access vlan 10 ! Switch01 Core(config)#do show running-config interface GigabitEthernet1/0/36 interface gigabitethernet1/0/36 switchport mode general switchport general allowed vlan add 10 tagged switchport general allowed vlan add 1 untagged ! And bang! Machine is addressed and working.

@vlandrummer said in How Netgate 6100s handle VLANs & "Default VLAN": Do the discrete LAN ports on the 6100 act as a trunk port would on a switch? The ports on the 6100 are no different than any other ethernet device -- they work on the vlan you assign to it. Not having a VLAN tagged on the interface means it's "native". [image: 1691447318047-368af759-9814-4fdf-a196-1a328dd275c1-image.png] CORE is native. The others are tagged on LAGG1. Substitute igc0-3 for your interface ports on the 6100.

@halter_joel Once you are connected physically, assign a /30 network to the link. So for example you will be 10.1.1.1/30 and they will be 10.1.1.2/30 Once you got that transit in place, create your static route. They will need one for you as well. After that apply firewall rules on that new interface/transit link and thats it.

It works just fine. I spent 4 hours scratching my head and troubleshooting almost everything technical about this and not seeing the VLAN tagging packets coming from What I thought was the otehr end of a cable on the LAN interface. This because I was trusting which very obvious and only cable of its color was feeding the uplink port on the main switch. I even drove a couple hours and back to go grab another server (different hardware) that I knew was working. Just as I went to rack and connect the different server, I could see that we had been on the wrong cable all along SMH. Heat and dehydration were factors and just trying stuff trying to figure it out totally trusting the information I was given about the cable feeding the switch. Which is usually a solid accurate and trusted source on a normal day :) Sorry for the false alarm. I really need to kick myself harder this time. No excuse for this crap. I'm usually better than that.

@tigerT well I checked what happens when you don't have a specific host override set for one pfsense vlan interfaces.. > server 192.168.3.253 Default Server: [192.168.3.253] Address: 192.168.3.253 Which makes sense when you think about it. I prob going to start changing my stuff to reflect new home.arpa domain. > server 192.168.3.253 Default Server: sg4860.dmz.home.arpa Address: 192.168.3.253

Hi, I have had another look at this but am getting nowhere, probably my lack of knowledge. Did find this post which seems similar and have tried to follow the suggested resolution but dont think I have got that right: https://forum.netgate.com/topic/152523/pfsense-and-ubiquiti-usg-working-together The suggested resolution was: ***stephenw10 Netgate Administrator Aug 11, 2020, 1:13 AM You don't. You need a route from pfSense to the USG LAN. Otherwise pfSense has no idea how to reach it and traffic that it gets for a client in the USG LAN will not be routed correctly. If you don't have a statuc route back to the USG LAN the NAT allows it work by translating all the traffic to the USG WAN address which pfSense does know how to reach. 1x NAT is better so add the static route to pfSense. Disable NAT on the USG. Steve stephenw10 Netgate Administrator Aug 11, 2020, 1:41 AM The static route has to be on pfSense itself. You have to add a static route via a gateway so first go to System > Routing > Gateways and add a new gateway. Set the USG WAN IP as a gateway and on the pfSense LAN interface which will be in the same subnet. Now go to the static routes tab. Add a new static route to the USG LAN subnet via the new gateway you just added. With that in place pfSense can reach the clients without the USG having to NAT. Steve*** So the IP's I have are: pfSense 192.168.2.1 USG WAN from pfSense 192.168.2.10 USG LAN 192.168.1.1 Providing DHCP to LAN Clients This is what I have tried: [image: 1691075905619-screenshot-2023-08-03-161807.png] [image: 1691075969015-screenshot-2023-08-03-161933.png] [image: 1691076022052-screenshot-2023-08-03-162031.png] Any help wpuld be really appreciated.

@orangehand Without more info the best I can do is suggest that you watch this video. https://youtu.be/WMyz7SVlrgc I followed this to setup VLANs on my pfsense and unifi equipment. Note that is you have a SG-1100 or SG-2100 there are extra steps.

After some research, I found out about arpwatch. Sorry.

@Austin-0 Ah ok. My first time playing with vlans so I thought that as long as a vlan capable switch was in the middle I could still feed multiple vlans down one cable. I’m currently setting up another client with windows. Once done I’ll change a port to each individual vlan only, assign it an IP from the respective pool and test then feed back. Would be great if this is working and it was just my understanding of it being lacking as I can then start asking my next questions in the appropriate threads.

Looks like its more complicated, something in my configuration is causing other issues. I have another unit to test with but if I change the lan interface to get its address from dhcp then it exhibits the same issue, interface goes off and online over and over and never stops unless I reboot. Reboot and all id fine unless I unplug and then the issue repeats. So something is going on with that interface, if I change it back to static then all is well, so I know track interface causes issues even with a static IP, never comes back unless I reboot and if you unplug it never comes back online. I get the same results when I remove the track interface and select DHCP to configure the interface. I do know that in a default configuration I do not see the issue so it's something else going on with my configuration but not sure where or how to look, anyone have any suggestions let me know, thanks.

Thats a web browser issue. I had the same problem with "Apply Changes" button missing. Resolved with cache cleaning.

@johnpoz Thanks for that info! I'll put in a managed switch in between the 4100 and the 2 other managed switches, then.

@CyberTend Looks like you hit a bug or have a partially installed driver. If you're running ZFS I'd roll back to 23.05 or 23.01, if you're not go to https://go.netgate.com to open a ticket to get the 23.05.1 release image and reinstall.

@Bruce74 My pleasure!

Looks like I was missing something: no client on these VLANs were getting DHCP (IPv4) assignments. They did, however, have active IPv6 addresses. Apparently, DHCP snooping was enabled on all the switches, and disabling it solved the problem. I noticed this shortly after posting.