@johnpoz Yes, I managed a larger Cisco network many years ago when I worked. I run the same setup basically.
We all called it L3 switching back then. You are moving traffic from port to port in a switch. It just happens to be network to network. Routing does not fit. We used eigrp routing from routers and L3 switches. L3 switching seems to fit vs just routing because it is happening at line speed not like regular slow routing.

What would you call it to signify line speed routing? I think L3 switching works.

Yes, you get a lot of users thinking they are doing L3 but really, they are doing L2 switching. Most people don't understand L3 switching. You need to be more a Cisco person. And now with 10gig and greater NICs needing L3 switching is getting farther out than it was 20 years ago. But when you push the edge a router and a L2 switch will break down compared to using a L3 switch.

Oh, about your drawing mine is a little different my connecting L3 switch network is a VLAN port 192.168.0.2, not real IP address, but close which plugs into a NIC in Pfsense 192.168.0.1, VLAN not defined. So, both ports are defined in the same network 192.168.0.0/24. All network ports are defined as a VLAN but not the NIC which is not defined as a VLAN just regular IP address. Gateway for NIC IP address 192.168.0.1 is WAN. This I think is the default gateway on Pfsense but I am not sure as we are into the GUI and I am no expert on Pfsense.
Gateway for VLAN on switch is the VLAN gateway on the L3 switch. All local traffic is routed by my L3 switch. Unknown traffic is routed to Pfsense NIC 192.168.0.1 my defualt route on my L3 switch. There are Pfsense firewall rules that allow networks on my L3 switch to pass.
I don't use a network to pass traffic on. I did on an older Pfsense setup but I decided it was not need for me and my home. My way is easier to setup. You just add the L3 switch to the network and what ever DHCP IP address is assigned is used. So, when I got a new Cisco L3 switch I went this way. It is easier to change switches for me.

The best DHCP server I have used is Microsoft's DHCP server. We used it at work and I used it at home before I turned off my rack. I tought it worked well.

@Nismos4Life87 I have a very similar setup - my ix1 (10Gb fiber) has all my internal VLANs, and is native VLAN 1 for LAN. This works just fine. The only oddity I've found is mentioned in https://forum.netgate.com/topic/185889/vlan-traffic-showing-up-on-the-wrong-vlan, but is really cosmetic.

Basically, LAN is ix1. All VLANs are defined with ix1 (lan) as the parent interface. No problems at all. My switch has the default (PVID) of 1 for the port attached to ix1, and all other internal VLANs are passed tagged to the same port.

I believe, dup of https://redmine.pfsense.org/issues/12401

@sic0048 Skimmed it out of curiosity. It says "In particular, Unify Phone signaling, and media connections are always established in the outbound direction from the corporate network to the cloud." Don't see anything about a public IP...? The only firewall rules mentioned are outgoing.

I think this is that case of "say thank you, hang up, and call back to get another tech."

FWIW we're 3CX partners. They have a concept of an SBC or router phone that tunnels/proxies connections out to a remote 3CX server.

@Jarhead: See my last post in a thread specifically about the firewall rules from this interface. The problem had been in the DNS rules for this interface’s firewall.

I have figured out the issue. I am going to leave the solution here if someone is facing the similar issue.

You have to change the VLAN id in under the switch ports. The numbers look like they cannot be edited. But if you click on them, they become a text box. I figured it out from this video. https://www.youtube.com/watch?v=NgRy14rYhV8

7b1fe0a2-c2c2-489e-8694-b254fcb16cc5-image.png

@Jarhead
Thank you man!
I wasted a lot of time without trying the most banal thing.

Thank you again!

@BigA said in VLAN/Firewall Access for Admin Only on any of the firewalled Vlans:

to access Pfsense from another area that only has access to the internet (PrivateIP Block rule)

Rules are evaluated top down, first rule wins, no other rules are evaluated. If what your asking is how to allow some device or network that is limited to talking to other rfc1918 address (ie your other networks)..

Just create a rule that allows who (what IP or network) to talk to your pfsense gui.. Be it the pfsense address on this network, or another pfsense IP, the built in alias "this firewall" could be used to be any IP address.

So for example here is example locked down rule that prevents access to pfsense IPs other than specific (dns, icmp, ntp) etc.. And blocks all other access to any other rfc1918 address space.

rules.jpg

So while these rules only allow this network "test subnets" which is 192.168.200/24 in my case.. To access icmp, dns and ntp on pfsense IP address in this network 192.168.200.253 for me.

It blocks access to any other pfsense IP and rfc1918... I could if I wanted create say a rule that allows access to the pfsense IP on this network "test address" on the port my webgui listens on 8443

allowrule.jpg

This rule could be adjusted for your needs, only say a specific IP on this network, say 192.168.200.x for my network. if you want multiple ports say 80,443,22 etc.. you could create an alias that contains these ports. Or just create multiple rules.

As long as the rule(s) are above where you block rfc1918 you would be able to access the web gui.

Rules are evaluated in order, so if you don't hit a rule that matches be it allow or deny then you fall all the way through to the bottom and are denied by the default deny rule (that isn't shown in the gui).

@ChrisJenk What he meant was of course it's tagged. The parent (or trunk port if you're more familiar) will carry the untagged traffic. Any vlan on it will have to be tagged.

@jahnieboi after restart switch, it will work. :)

@viragomann

You are correct, the solution was to create a outbound nat. I had tried this before but I made a mistake for the interface I selected VLAN30, but this was not the correct interface. The interface should have been LAN. Your solution pointed out that mistake.

Thank you.

@Jarhead Color me confused.
Before doing the screen shots, I rebooted the 2100 and plugged a device into Port 2 (which) is where I had set up the VLAN.
Still no DHCP, then, set a Static address on the device in the range and it worked! I could get to the 2100 on the primary IP for that VLAN.
Switched the device BACK to DHCP and, then, DID get an IP.
When in doubt, reboot, eh?
Thanks for your responses, they did help my thinking process and confirmed I was not completely crazy.

Are you switches the same brand/model? Depending on the switch, you might be able to "stack" the switches together which physically connects them and provides a single point of management for both switches. Not all switches offer this functionality however.

@jamcallis well your not going to be able to get to them are you, so guess it could cause some delay in connecting as it tries all the ones that wont work..

@caramel_juni
also noticed that your using a LAGG network make sure your unifi supports it (sure it does) and I think aggregation is the unifi setting-

I also assign all my unifi devices a static IP address- otherwise I have seen my cloudkey list my trunk port gateway address as on of the vlans rather than the parent interface address-

All sorted, can you believe a simple reboot fixed it.
Thanks all for you input

@JonathanLee Ok, Already tried to change the MTU from the single interface.

Thing is: my interfaces, apart from vtnet0 (wan) are all vlans on the same trunk interface (vtnet0).

Now, I only assiged the vlans, not the base interface, so I couldn't go to the interface from the gui.

Solution: I assigned momentarily the base interface (vtnet1), changed the MTU -> automatically changed in all of the vlans, then deleted the assignment (as I only actually need the vlans on that one).

Thank you very much.

@Aved590 What happens if you do a traceoute out from one of the devices on that vlan to a public address. I normally use Hybrid NAT to have more granular control over scenarios like this.