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

@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

@imv8n said in Assit with tagged vs untagged VLAN TPlink switch:

TPLINK TL-SG108E

Be careful. Some TP-Link switches don't handle VLANs properly. I believe this is one, though it may have been fixed by now.

@johnpoz
Probably, but only that seemed to work though....no other changes made and nothing worked until the restart. Probably a restart of a specific service could do it as well. Bug or not , my pfsense doesn t seem to work not only for vlans but for Firewall rules as well. I created a rule in order for the vlan not to be able to access the lan and didn t work. I restarted the laptop, still nothing , restarted the router still nothing, restarted pfsense and guess what,....

It is not like spreading false/wrong info but if anyone else is having similar kind of problems it would be nice to know one extra thing to try out.

It was an IPsec VPN!
If the near and far networks overlap then traffic heading for the firewall IP needs to bypass the VPN.
That's normally sorted out by the 'Enable bypass for LAN interface IP' setting with is on by default.
However, that only handles the lan interface and not any other lan-type interfaces which get created.
The fix was to add an 'Additional IPsec bypass' rule.
I'm not sure if this is a bug or not.
Should there be a list of interfaces to bypass rather than just the lan interface being special?

Cheers,
Scott

Will attempt to revive this old thread by giving it a different direction if ok with moderators. Has any of you been able to get the Signal mapper to work on the iOS app? Did you have to open any ports in pfSense? It looks like Wifiman uses port 8900.

I have read through Unifi forums as well and it appears that it is a majority of iPhone users struggling with this feature and also the recommendation is that this shouldn’t be an issue for those who have an UDM/UDMSE as their gateway/firewall. I am using a cloud key 2+ connected in pfSense LAN. I posted this question in Reddit as well.

Appreciate any assistance with this! Thank you!

@highc
We need to see screenshots to see how your VPN is set up. I know with OpenVPN, you must specify each network segment that the VPN will have access to - so 192.168.1.0/24, 192.168.3.0/24, 192.168.5.0/24, 192.158.7.0/24, etc. It sounds like this isn't set correctly.