Initial setup with bridges is painful
-
I really like the new bridge configuration in 2.0. The problem is that it is only available in the GUI after the initial setup. My network setup ends up bridging my WAN port with a vlan on another port as well as my LAN port with a vlan on another port. It can be done in the GUI, but it requires lots of odd steps and temporarily makes the GUI inaccessible. Instead, right after vlans are created in the initial text-based setup, a step to create bridges would make this much simpler. Then I could just designate the bridges as my WAN and LAN interfaces which is what I really want. I want the rules on those interfaces to apply to the routing between WAN and LAN, not between the ports on the WAN or LAN bridges.
-
Most people probably wouldn't need that step there, so it might prove to be a hindrance or source of confusion more than a helpful step. The concept of pfSense interfaces in 2.0 is completely different. LAN and WAN are just called that by default, and interface can be anything now. As such, you should really think about how your network is laid out and instead of involving LAN as the bridge, keep LAN as a non-bridged management interface (and you can rename it, too) and only bridge on OPT and WAN instead.
Failing that, if you could describe the procedure you had to use and at what point the GUI access was broken (and then worked again) it might help streamline the process.
-
To be fair, most people probably don't need VLAN setup during initial setup either, but there is a yes/no question to let them decide.
During the text-based portion, I setup all my VLANs and assigned every ethernet port (actual NIC and VLANs) to an interface. At this point I need to choose something for WAN and LAN or else the setup won't continue. Since I can't choose the bridges that they really should be, I assign WAN to the port connected to my cable modem and LAN to the port that my laptop is attached to. It's the closest to the actual setup I can get and will at least let me access the GUI, etc. In the GUI setup wizard, I provide the static IP for my WAN and change the IP block for LAN and don't change much else.
Once in the full GUI, I assign names to each of the interfaces to keep my sanity (I've got WAN, LAN, and OPT1-8 at this point). My first attempt at creating bridges left me really confused. I hadn't originally assigned the underlying ethernet ports to interfaces and thus there wasn't an option for them on the new bridge page. Considering best practice for bridges is to not do anything with the member interfaces (no IP, etc), I didn't expect to need to assign them an optX name. It was easy to fix, but I've subsequently made the same mistake multiple times and had to go back and add the optX interfaces for the bridge members. Anyway, I add three bridges: one for em0 and em3vlan2 (WANs), one for em1 and em2vlan2 (LANs), and one for em2 and em3 (Management). Then I go back to the interface assignments and add OPT9-11 which default to the new bridges.
I should note that the default firewall policy for bridge members looks to be deny all and that rules on the bridge itself (as opposed to on the members) seem to be disabled via sysctl. For every use of bridges I can come up with, this seems wrong. The bridge members should almost always have an allow all rule (the default can still be deny all, but there should be an explicit allow all added on member addition) and the bridge should allow rules. That way traffic between members on the bridge is unrestricted (the normal expectation), but traffic routed from the bridge to other interfaces is subject to the firewall rules (the default being deny all).
Coming from 1.2.X, it wasn't really clear at this stage that the WAN and LAN interfaces don't carry special significance. This is especially true when looking at the console output and seeing them labeled explicitly as WAN and LAN instead of optX. Sure, I can give them any description I want, but they still show something like COMCAST_WAN(wan) 173.xxx.xxx.xxx. In the interface assignments, I change WAN to bridge0 and change opt9 that was bridge0 to em0. Of course, since the bridge is based on the assigned interfaces, this makes bridge0 contain itself as a member. So, in the bridge configuration, I change the member from WAN to opt9. After saving and applying, the default route is missing and has to be re-added under Setup->Routing.
Then, I do much the same for LAN. I change LAN to bridge1 and change opt10 from bridge1 to em2. I get the same problem with having to change the members for bridge1, but now I run into a dilemma. I need to save the interface assignment changes for them to be available in the bridge configuration, but if I save them, the LAN will be bridge1 which does not include em2 as a member. Thus, I lock myself out of the GUI. This can be worked around by manually setting IPs and changing the bridge membership via the console shell. After the bridge membership is changed, this will act quirky until a reboot.
Now, given that you've clarified that WAN and LAN don't carry any real special significance, some of this routine probably isn't necessary. I should be able to designate my cable modem as the WAN and the port with my laptop as the LAN during initial setup. Then, I can add the bridges as optX and then change the IP configuration on WAN and LAN to None and set bridge0 and bridge1 to the appropriate IPs. I believe this will still cause the GUI to be inaccessible since I'd need to set LAN to None and save before I can set bridge1 to the same IP.
The only other option is to intentionally choose a port that I don't plan to bridge as my initial LAN. I could either use one of the VLANs on a port (untagged on a VLAN'd port is part of the Management bridge per design) or the one physical port that isn't going to be bridged, but that feels really ugly. Especially considering that all of those ports are intentionally not supposed to have access to the GUI. I'd be doing the setup that way just to get an ordering enforced via the GuI. It's a workaround and a non-obvious one at that.
I'd rather have the initial setup flow be changed to:
- Setup VLANs (y/n)?
- Choose base interface
- Choose VLAN tag
- Repeat - Setup bridges (y/n)?
- Choose member interfaces (physical or VLAN)
- Repeat - Assign interfaces
- Setup VLANs (y/n)?
-
I agree there needs to be more console setup ability for some of the new functionality - bridges and lagg are the two that come to mind. You can get into some ugly situations with both that are difficult to accomplish.
The reason you have to assign the bridge members is you have to have firewall rules on them or everything in that interface is going to be blocked (by default). Rules are never added to an interface by default, aside from the default LAN rule in a LAN/WAN setup. Filtering on the bridge is disabled because filtering was only possible on member interfaces in the past, it was never possible to assign the bridge previously, and if it's enabled by default, it'll block everything on upgraded bridges. Likewise if you disable filtering on member interfaces. Can't do either, as upgraded systems cannot be broken and cannot have their behavior changed.
Changing bridging to allow unassigned interfaces also opens up numerous other potential issues due to the way interfaces are handled in the back end, and would require revamping the bridge code. Without changing that, you're left with a catch 22 at the console setup, you can't assign interfaces until you create the bridge, but you can't create the bridge until you assign interfaces.
I don't know it'll change for 2.0 unless someone contributes the fully functional code, but it's definitely something that will be handled in the future.
-
There are a couple of ideas I've had related to this. One was to have an area in the bridge configuration page or elsewhere to swap the bridge interface and one of its members in the interface assignments. Another idea was to detect when you have assigned the bridge as a member of itself, and replace it in the bridge configuration with the interface that used to be in the spot. The logic for that could get complicated, though.
-
Please leave it as is for now.
A bridge config page has nothing to do with the flow of how you configure it!
As the one that has written all the interface code in 2.0 i know its problems and have even the fix but it would have to wait after 2.0 is released.For the time being a wizard would be the solution so if anybody wants to write that, please do so.
-
An area specifically for moving around interfaces between bridges while reassigning interfaces would probably be an easy way to handle it. Maybe a link or button on the assign interfaces page to go to a variant page in the same php file with these extra options? It could be something below the regular options on the assign interfaces page that appears when you click the link or button and has lists where you can add or remove interfaces from each of the bridges.
