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.
Let's see the switch config first.
You need to figure out where you want the layer 3 to be, either pfSense or the switch, can't have them both.
But there's still no confirmation of how you have anything config'd in the switch.
Post those images first.
@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..
@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.
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.
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
@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.
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.
If another device comes along and plugs into one of my dumb switches or connects to my guest WiFi, how can automatically put that device into a Guest VLAN, subject to the pfsense firewall rules designed for Guest VLAN?
By having all VLANs as tagged and leaving the guest VLAN untagged on all the ports that might be exposed, additionally putting a lock on the door where the data cabinet is located.
If you want something like AAAA or Cisco ISE you need different hardware. pfSense doesn't do AAAA on its own and most systems like that (x501) need a third system to do management anyway and those are done on the switch level. I did a little of that with Aruba in the last gig but not too much - we would find it easier to spin up an SSID in a part of a building for a single user most of the time.
@creationguy I normally use reject for local stuff like this.. If your not going to allow it, might as well tell the client - hey your not getting there, vs having it try with retrans and just bang its head against a wall.
I wouldn't suggest you ever use reject externally, unless for a specific purpose - I reject on traceroute ports so that traceroute works.
This shows you exactly what the ports on pfsense or switch connected should be set for.
Pfsense lan is native untagged.. this would be vlan 1 on your switch... So the port connected pfsense, port 4 on your netgear should be vlan 1U, 20T and pvid should be 1 as well.
POrt on your netgear that will end up on your cisco same way 1U, 20 tagged..
Port that connects to your dumb switch on cisco, in cisco world this would be a trunk, and you would allow the vlans you want 20..l pvid still 1.. nothing to change there.
Port that connects to your AP on your cisco, again same thing vlan 1 Untagged, vlan 20 tagged this is a trunk on cisco..
What are you not understanding - so I can come at it a different way.. This is pretty basic stuff here.. If there is no tag, this is a native vlan on a switch.. Normally 1 for example is the default for switches. You can only have 1 untagged vlan on a port. If you carry another network it has to be tagged.
For vlan 20 traffic to get from pfsense to your cisco you have to have all the physical ports that connect the switches set to understand that 20 is tagged, not tagged is vlan 1, etc.
@dabdad Funny, I got you as being the negative one.
Every reply I made never contradicted a thing.
And if you had listened to my very first post, none of the others would have been needed.
But glad you got it working.
@j24 A bit late to this party, can are you able to share a screenshot of the Switching > VLAN > Advanced > VLAN Membership, for one of your static VLAN groups? I'm trying to see where I'm going wrong with the tagged/untagged options.
@jarhead Hi, thanks for following up. I appreciate it. I contacted the switch manufacturer for a 3rd time and finally figured it out. lol. there was a few things i was doing wrong, plus the support tech kind of led me in the wrong direction.
@creationguy If your running tagged only on the port.. Then yeah it would be best to set the pvid to the vlan you want any for whatever reason untagged traffic that might hit that interface to be in.
Might be best to use some black hole vlan ID there, other than the default vlan 1. For example you create a vlan 666 for example. Add ports that are disabled, or ports that should never see untagged traffic set the pvid to that.. This goes nowhere only to other disabled ports, etc.
if your not using vlan 1 actually for anything, that could be your "blackhole" or disabled vlan ID sure..
If you are actually using vlan 1 for other untagged traffic, ie an interface on pfsense has an IP directly on its interface, then your other interfaces that only have tagged traffic should not be in that same vlan for any untagged traffic, whatever the ID is your using on the switch.
@northernsky the specs on the page clearly call out discrete ports, states unswitched..
You can use them for whatever sort of connection you want lan or wan, but they are not switch ports.
While you can somewhat simulate what a switch does with a bridge, its still not switching and horrible solution and really should only be used while you wait for a switch ;)
If your switch supports vlans, then sure you could use the different interfaces on pfsense as uplinks from the different vlans, so your not hairpinning intervlan traffic over the same physical interface, etc.
Did you just get the 6100? Maybe you can return it and get a 7100 or a 2100 which do include switch ports.. But they are not 2.5ge ports like on the 6100..