@bfostyvr
Did you place the block rule above of the allow any rule?

If so, I'd suspect that your VLANs are not segmented properly on your switch.
What exactly does your infrastructure and VLAN configuration looks like?

@kowi said in Multiple virtual interfaces on physical port:

Is it somehow possible to create multiple virtual interfaces on a physical port with its own mac addresses?

No. The MAC address is determined by the hardware. Also, how are you setting up those interfaces? VLANs? Virtual IP?

Sorry, this was a mispost. I was replying https://forum.netgate.com/topic/180691/at-t-gateway-bypass-true-bridge-using-new-authbridge?_=1694719968811

@viragomann

Thanks.. I followed the following and it made sense to me.
Other than what's in the link I also allowed ANY/ANY access on private network interface
https://yhf8377.medium.com/replace-aws-nat-gateway-with-pfsense-vm-5454066585c2

all works

@Dave07186 if you want to use vlans in your VM setup, you wouldn't actually set the tag on the virtual interface - you would set it up in the virtual switch or port group on the vswitch etc. I have not played with virtualbox in a really long time, but end devices almost never have need for actually doing the tag themselves.

I have to assume virtual box has a way to allow VMs to be on a vlan..

Any idea?

@cnanoharman
I can't tell what you did and what you pasted from some random wiki.
Here's a rough workflow of adding a couple of new networks for wireless and guest on Unifi/pfSense.
I used vlan 100 for the wireless network, and vlan 200 for the guest in this example. The LAN is assumed to be native. I used foo0 for the network adapter, which isn't a real thing. Substitute igb0, or your lagg, or whatever. I didn't go into details on configuring the interfaces, rules and such. I'm assuming you know how to do that.

Unifi controller-
settings, networks
create new (type vlan only/third party gateway)
name wireless
vlan id 100

create new
name guest
vlan id 200

settings, wifi
name corpssid, password, etc
network- wireless (old version vlan 100)

name guestssid, password, etc
network- guest (old version vlan 200)

You can leave the switchports the APs are in set to 'All'
The port connecting to pfSense should be set to 'All'

pfSense-
interfaces, assignments, vlans, add
select parent interface (usually LAN)
vlan tag 100
description wireless
save
add
select parent interface (usually LAN)
vlan tag 200
description guest
save

back to interface assignments-
Available network ports: vlan 100 on foo0 (wireless) [add]
do the same for vlan 200 (guest)

Now, interfaces, OPTx (foo0.100)
configure interface with unique subnet, etc

Now, interfaces, OPTy (foo0.200)
configure interface with unique subnet, etc

services, dhcp, enable and configure on OPTx and OPTy

firewall, rules, configure rules for the two new interfaces

firewall, nat, outbound. If you're not using automatic outbound nat, add rules for the new subnets

@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".

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.