@johanl79 Ok, you have a UniFi set-up issue and we probably should have had this conversation on their forum. UniFi has no issues running with pfSense and some make this their default business model (see Tom Lawrence as an example). What you originally enquired about was your VLANs, something easily managed with pfSense and your UniFi equipment.

It's taken a while to even understand your equipment and network topology but I think we all understand that now. You have set your mind on purchasing different equipment rather than adjusting your current settings on your new VM-based controller in order to fix your original stated issue.

☕️

@johnpoz Yes. it's in AP mode. That option shuts off a lot of the typical router functions and requires the pfsense DHCP server to give it an IP.

I think the device has some kind of hardcoded security "feature" or the web server code is just buggy. Knowing Netgear, it's probably the latter, but it could be some kind of ham-handed way to add some friction to hackers or nosy users. I have no idea.

It's not a routing issue since the problem is only with the web-based administrator interface. I can telnet and ping the device without the NAT translation.

@sysadminfromhell yeah - the only time pfsense needs to know about a "vlan" if it needs to understand tagging.

if you just setup native networks on your interfaces.. You can isolate them on your switch by just putting them in different vlans on the switch.

To pfsense its no different than if the ports were connected to 2 different physical switches. Your just creating 2 "virtual" switches by putting specific ports into different vlans on the switch.

This is the whole point of vlan capable switch.. Traffic being tagged is only used when you need to carry more than 1 vlan over the same physical wire. The tag allows either the router or AP or other switch to know this traffic is network X, this other traffic is network Y.. If you don't plan on running more than one "vlan" over the same physical wire you can still put different ports on your switch into different "vlans" and isolate them from other vlans on the switch, etc.

If it'll help, some further details about my setup, everything is connected by Unifi switches that are vlan capable, but not all of the ports are specifically configured to be on a vlan.

I've been doing fping tests just to see what can be seen through a few different systems, and below is my findings.

From a system that is connected to a port designated with vlan 3220 [10.32.2.0 network]:

uquevedo@ubence-air-wired ~ % fping -ga 10.32.40.1 10.32.40.254 10.32.40.1 10.32.40.10

From the VM itself that is configured with the bridge interface to vlan 3240:

uquevedo@kea-testing:~$ fping -qga 10.32.40.1 10.32.40.254 10.32.40.1 10.32.40.10

From a system that is connected to a port designated with vlan 3230 [10.32.3.0 network]:

[uquevedo@fedora-system ~]$ fping -ga 10.32.40.1 10.32.40.254 10.32.40.1 10.32.40.10

From the actual RHEL9.2 host system, which of course can ping the IP address:

[uquevedo@rh-vm01 ~]$ fping -ga 10.32.40.1 10.32.40.254 10.32.40.1 10.32.40.9 10.32.40.10

There are many bridged interfaces on the host system connecting to various vlan tagged interfaces:
Screenshot 2023-05-17 at 7.13.36 AM.png

The bridge0 interface is a non-vlan tagged interface [vlan1?] and is accessible to all systems on the network.

I was under the assumption that if a network interface was tagged with vlan information that it would be accessible to other systems that are part of that same vlan?

Another thing about my setup is that these vlans are configured on a pfSense box for lab purposes, they are not configured on my main pfSense box [which I don't think matters]. So even though the opt ports of this system are technically on their own network, they are connecting to my main network.

@senseivita

You're not supposed to use 4095. It's reserved.

@jknott i don't need to replace the tplinks. i can simply put an ipv6 ACL on the ports of the netgear that connect to it and my purpose is solved. My trouble is, i don't know what i need to put in the config screen i posted

@tonydutt you're welcome!

+++

missing details:

laggash on lacp vs tp link swicht (errored interface) is l2
laggash on lacp vs edgerouter is l3+l4

@kanuns
With the example configuration I gave above, pfSense can only get an IP in one of the VLANs.

However, as of your description of the purpose it I'm wondering if you really need the VLANs to terminate on the Mikrotik.
If not you can remove them from there and configure a simply transit network between the Mikrotik and pfSense. This could be tagged or not. Then route the VLANs to the pfSense IP.
On pfSense you can configure the VLANs on the NIC for the AP.

I think, this setup is easier and more reliable.

Are you positive the modules you're using in the X520 are coded for Intel part numbers? Most X520 cards will not pass traffic unless your optics are Intel coded. You might get link lights, but the driver won't bring the port online.

Did a bit more testing. Setup facing switch (qfx5100) to push/pop the stag so I could setup only one tag since it' worked on another interface. Unfortunately it doesn't work in this scenario either. The difference here is I see arp requests from pfsense on a tcpdump of the interface, nothing comes back from the far end. Primary interface ip works fine and BGP is up.

Unsure of what to test next.

@dobby_ I already have invested and put in SPF+ fiber cards and for blade servers - I can't switch out a card. Also 8 ports are about 8 ports to little :) Also, I would prefer a modern equipment, it is an important reason also. My current D-Link stackable is just a bit newer than these and firmware updates are ended long time ago.

@uplink PVST+ and RPVST+ which are cisco and can be tagged..

A native vlan is any untagged vlan, not just vlan 1.

From one of the cert exam books for cisco

"Although maintenance protocols such as Cisco Discovery Protocol (CDP), Port Aggregation Protocol (PAgP), and Dynamic Trunking Protocol (DTP) normally are carried over the native VLAN of a trunk, they will not be affected if the native VLAN is removed or manually pruned from the trunk. They still will be sent and received on the native VLAN as a special case even if the native VLAN ID is not in the list of allowed VLANs."

Any untagged frame is native.. If you want to take something away from that it should be this.

" It is generally the best practice to keep that internal traffic isolated from data traffic."

So put your switches and AP management on a vlan not used for normal user traffic.. This is sometimes called an infrastructure vlan. But then again you have to work with the functionality of your infrastructure devices.. But even if your devices have to be managed with untagged - you don't have to use that vlan for user traffic.. So yes it best to isolate management of your network from user traffic ;)

But here is the thing - you can not really disable untagged traffic like that from being sent, you can keep it from being passed on, etc.. Here I have a dummy vlan 10, the vlan is disabled - it doesn't go anywhere.. I set the native vlan, because you can not really remove it from a port, cisco doesn't let you.. If you remove native vlan from a trunk in cisco it will just send it out what default vlan you have set on the switch.. which will be "untagged"

sniff.jpg

that is sniff on pfsense on a port connected to switch interface that is in trunk, where native is set to a disabled vlan, notice still see stp and cdp traffic on this port..

If your worried about someone plugging into a port, again the best thing to do is disable and put into a vlan not using, like my vlan 10, But if the port is active and you have cdp or stp enabled - there will be that traffic on that port untagged..

Your causing yourself added config and and work for no real good reason.. And again any port connected to a device is going to be native, ie untagged in some vlan be it the default vlan 1, or some other vlan you put that port in. Even if you told all your devices to do tags, iot devices, printers etc are unlikely to be able to do that, etc. And even if you setup a port to only be tagged, info like stp and cdp is still going to go out that port..

depending on your switch, you may be able to disable stp on specific ports, or stuff like cdp or lldp (non cisco kind of cdp).. But most lower end smart switches are not going to be able to do that, etc.

@marvosa Thanks again for your help. It is now working. It was at least the firewall rules issue ("LAN net" didn't cut it), and adding rules for each subnet was the final piece. I also went through and added the individual subnets in the outbound NAT rules. Between those two changes - we have access on all subnets.

@noechoreply said in New setup with 2100: Can't ping connected Cisco switch or any of it's devices:

I do not have the definite explanation to why it's like that.

Stated in many threads on the forum and in the documentation:

port 5 is the IC in the 2100 and it has to be tagged for the VLANs to be seen in the pfSense side of the hardware. The switch is not directly tied to pfSense and has to be linked through, using port 5.

Step 19 here:
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/configuring-the-switch-ports.html

87171335-f2cb-45a2-85d9-a79f632aa626-image.png

@idlekite If you have a backup, restoring would work. Or restoring from the config history.

https://docs.netgate.com/pfsense/en/latest/backup/restore.html