@wifi-will

I'm not certain how your hotels would be much different than that seniors residence I mentioned. It had a router and 4 24 port switches, with the switches spread among 3 towers and the office. It also had a lot of WiFi and ADSL to the rooms. Each room also had it's own router.

That's the thing. I've had suricata running on the system with just the three physical interfaces for a while now with no problems, but once I got around to moving the tunnel so I could make use of suricata, things started getting weird.

Right now, I'm suspecting that it's going to come down more to a combo of pfsense/suricata not liking the use of tagged vlans with my particular configuration (I did see netmap_ring_reinit igb3, which happens to be the parent for the vlan at one point, causing traffic to stop flowing until the system was restarted, with a full reset to POST at the worst case).

This was partially me derping any not expecting inline mode to inspect the tagged packets, which I should have, and partially it apparently blocking the neighbor solicitation packets, which was totally unexpected, and resolved by disabling it on the parent interface.

I'm not totally adverse to moving the parent interfaces around, or moving the tagged vlan to something port based on the switch, which may also lead to cleaning up some, ahem, 'technical debt' in the layout of the local network space.

Regardless, I reserve the right to change my opinion as I look into this more. 🙂 At this time, things are stable and the public facing server IP's are receiving traffic as expected.

@ydyw8rdm8i7dfd

Just note that when you set switchport mode trunk , it will "default" allow all Vlans on the trunk.

If you feel for it you could do a further restriction :

switchport trunk allowed vlan 868-870,872-876,897,898

Remember the "add" on allow , else you will be sorry 😊

/Bingo

@dominikhoffmann There is a lot of nonsense on the internet - that video seems like one of those.. No you would not bridge 2 interfaces on the router and plug them into the same switch.. You just created a LOOP..

You can somewhat try to simulate a switch port with 2 interfaces and creating a bridge that you would connect devices into, or 2 dfifferent switches..

But a bridge is not the same as a switch port - if you want/need more ports than use a switch..

@treefrog

Assign the vlan to an interface, create your firewall rules. Then you can move lan to the interface.

But yeah @viragomann is correct if you plugged the pc directly into the pfsense interface you would had to set the PC to do tagging?

Out of curiosity why do you want your lan tagged?

@natethegreat21 you can for sure block specific as you have done. But as mentioned its easier to just create an alias that either contains your specific networks, or just all the rfc1918 networks.

You could create an alias with your full prefix for your IPv6 space. Problem with dynamic ipv6 is that could change - which is one of the reasons I prefer tunnel from HE, I get a /48 to do with what I will and it doesn't change.

@dominikhoffmann You can skip the port assignment (that only shows you up/down status in the GUI) and do the PVID assignments -- which was likely all you were really missing.

@chris1284 said in How to start with VLANs:

where i also connect the modem link on a port with VLAN 7 (needed for T-Com)

Yes, it's nothing more than a tagged VLAN port, no PVID needed on this port.

@rcoleman-netgate said in Moving LAN port icg0 to another physical interface:

@kiwinia I make a new interface that allows you to access the GUI.

Then I change the interface.

Always have a backup port.

@rcoleman-netgate, Thanks, yes I just did that and confirmed I could get to the GUI from there, that makes me feel more comfortable.

I need to get familiar with the console also, in case I need it in the future.

Thanks to everyone who responded

@gjaltemba said in Help with routing problem on L3 switch:

It was a static route that I needed

Yeah you have to tell pfsense how to get to the downstream networks for sure ;)

@hudri said in Assigning Clients to VLANs:

where they just manually switched back and forth between the VLANs,

You can - where you set the pc to understand the tag, but again that is not a vlan... That is some user without a clue to networking thinking they have setup a vlan and all they did is run multiple IP schemes on the same network. There is no actual security there, anything can talk to anything, be it you setup a firewall rule or not - broadcast and multicast traffic is going to be seen by every device.

That is not a vlan. A vlan actually isolates traffic at layer 2..

You could move your pc into another vlan that is on that port, by changing the pvid on trunk port so the untagged traffic is now in X vs Y, etc. But just changing on the IP on the pc isn't going to work if you actually have vlans setup.

@19taurus79 Typically the answer is no... but the 1100 is a switch already with the same MAC address on all three ports so it doesn't matter here.

@awebster

Thanks very much for the explanation. I think the situation is as follows:

in the original layer-2 ether-net specification there is no priority field however there is a need for priority packets in a later version of the layer-2 spec there is the 802.1Q tag which add
-3bit Priority code point (PCP) / COS
-1bit Drop eligible indicator (DEI) / CFI
-12bit VLAN identifier (VID) / vlan number

To transport un-tagged frames with a priority mechanism they defined a trick "vlan0". That trick adding an 802.1Q tag to the original layer-2 frame, allows the add of the PCP/COS and the DEI/CFI.

A managed (😊 ) switch receiving such an ^updated level2 frame^, can then process the frame with the correct priority.

Of cause the switch administrator can tell the swith that it should add "whatever vlantag / number" to that in coming untagged frame, where I assume that the DEI and PCP will be set accordingly in that vlan 802.1Q field.

And after transporting the frame to the other end of the network, another managed switch can output that frame to an untagged port. Doing the inverse trick changing the VID from whatever VID-value ("50") to 0.

One potential problem, assume we hand over that ^modern semi-un -tagged^ frame to an unmanged switch or an end device like a PC what will happen !?

Does the managed switch at the end have three options forwarding the package as:

vlan package with a real vlan number as a vlan0 package perhaps not understandable for the attached equipment or forwarding the package as a classical untagged package

Below a picture I took from https://en.wikipedia.org/wiki/IEEE_802.1Q

726cd7fa-108b-42c3-860d-a397f8f082a0-image.png

I hope I described it correct this way.

Louis

@broonu Hello, sorry if I'm replying to this old topic, but I'm experiencing the same problem trying to bridge the WAN interface with a VLAN created on a LAN interface.

The behavior is almost the same: no reply to ARP requests from pfsense + I cant ping the pfsense upstream gateway.

Before giving up, I noticed that the WAN and LAN interfaces are E1000 (not VMXNET3).
I would like to change the nic type as last attempt.
Anyway, before doing that, I would like to know if there is a particolar relation between bridge and vmxnet3.

Could you please help me?
Thanks
Mauro

@321liftoff Access switch 1 & 2 should be in a stack with a LACP link to each individual stack member and the same for the pfSense connection to the access-switch stack.

@laplacian said in Trouble with VLAN:

Also, is there a better way to specify the internet other than !RFC1918?

Yeah Any.. While ! (bang) rules can and do work, I would stay away from them.. You should be explicit in your rules. Less likely for errors and way easier to read at a glance.

If you don't want stuff to go to rfc1918, then be explicit with that either block or locally reject is sometimes better, because it will tell the client hey your not getting there. No reason to bang your head sending retrans, and waiting for them to time out.

There have been issues in the past when vips are used that can mess up ! rules, if your going to use a ! rule then make sure you fully and comprehensively test that it is in fact working exactly how you want.

You understand 1 rule vs 2 is not going to provide any less overhead or performance.. And is more likely to be written wrong or not work as intended, etc.

@jarhead So, I didn't get to that issue the next morning... life gets in the way sometimes. But I did finally get on it and once I realized what you were saying, I felt like an idiot. Easy to do at the switch using the untag and PVID. Just wanted to say thanks for the help... albeit a bit late.

@jclausendk Follow these steps:

Create a new interface VLAN Create VLAN in the switch Tag ports 1 and 0 for VLAN Assign WAN to the new interface VLAN you set up in step 1