Watchguard Firebox X Peak platform

stephenw10

Yes, you have to bridge the ports together to use them like that.
The procedure changed slightly between 1.2.3 and 2.0 so I'm not entirely sure but from memory:
You create a bridge interface and then add to it all the interfaces to be bridged. Then you use the bridge interface for your firewall rules and DHCP server.

However you need to be aware that when you do this all traffic flowing between ports on the bridge is screened and filtered by pfSense so it puts a high load on the CPU compared to an external switch.

http://doc.pfsense.org/index.php/Interface_Bridges

Steve

power_matz

Thank you for your answer.
Do you know if this will work also with VLANs and the IGMP proxy?

shanon

Thanks for the link Steve, hadn't read it.

I have a bit of experience in debugging x86 code. I'm okay with assembly / dis-assembly, but haven't tackled anything near as complicated as reversing a full BIOS. Time will likely be my biggest enemy, but I'm keen to go at least a little further with this.

stephenw10

@power_matz:

Do you know if this will work also with VLANs and the IGMP proxy?

You can bridge VLAN interfaces but isn't there some other way you could do this? You really should try to avoid using bridged interfaces if you can. I have used them just as an experiment and because I couldn't otherwise use all the ports on the X-peak! ;) My situation is low traffic though.

I'm not sure about IGMP proxy I don't use it. I can't see why you couldn't use the bridge interface though.

Steve

power_matz

@stephenw10:

I have used them just as an experiment and because I couldn't otherwise use all the ports on the X-peak!

You have to select a kind for all of the interfaces in the bridge (static, DHCP, none etc). What is the appropriate kind if the bridge will be a DHCP one?

stephenw10

The IP address of the bridge will be static, e.g. 192.168.10.1/24.
As opposed to the WAN interface which usually gets it's address from your ISP.

Steve

power_matz

@stephenw10:

The IP address of the bridge will be static, e.g. 192.168.10.1/24.
As opposed to the WAN interface which usually gets it's address from your ISP.

Steve

Yes, thats clear. I mean the members of the bridge.

stephenw10

Hmm, I thought I'd run through it myself to be sure and it doesn't work as I remember it. It's not possible to assign an IP to the bridge interface for example. Looking into it….

Ok now I remember the little trick, it's not obvious IMHO.

First assign and enable the interfaces you want in the bridge and set the type to none.
Now go to the bridges tab in Interfaces: Assign:, add a new bridge and add the interfaces to it.
Now (here's the part that I forgot) goto Interfaces: (assign) and add a new interface. It will come up with some interface possibly an unused one. Now change that to bridge0.
Now you can enable that interface set it to static (remember to use subnet /24) and add a DHCP server to it.
Having just done this my experimental LCD driver has locked me out of the box, again, so I can't check it. ::)

Steve

Also you must add firewall rules. By default the filtering is done on the member interfaces but I think you can change that to the bridge interface which would be more useful in my case.

wallabybob

@stephenw10:

It's not possible to assign an IP to the bridge interface for example.

On my pfSense LAN is bridge0, bridge0 has members vr0 and ath0. Bridge0 has an IP address, vr0 and ath0 don't have IP addresses.

stephenw10

Thanks for that.
I see my mistake now. I expected bridge0 to be assigned to an interface after I had created it but that's something you have to do manually.
Seems somehow counter-intuitive to me.

Steve

wallabybob

@stephenw10:

I expected bridge0 to be assigned to an interface after I had created it but that's something you have to do manually.

You might be thinking of pfSense 1.2.x way of bridging: when configuring interfaces they could be "bridged" with another interface. The bridging was not always visible and that could result in misleading reports. In particular, if ath0 was bridged with vr0 (or was it the other way around?) a DHCP request on ath0 was reported as received on vr0. Huh, how did the DHCP request from a wireless client get onto a wired interface? (Or, possibly depending on how I had configured the bridging, how did the DHCP request from a wired client get on the wireless interface?)

The 1.2.x way of configuring bridging had a scaling issue in that it wasn't clear how to bridge more than two interfaces.

I like it that in 2.0 the bridging can be made more visible, you can run DHCP server on a bridge interface and it reports DHCP requests on the bridge interface rather than the wrong physical interface.

I haven't tried it, but I suspect it is possible to (say) create a bridge with members ath0 and vr0, assign vr0 to LAN and enable DHCP server on LAN and get the old behaviour. Experience suggests I would come to regret such a choice.

stephenw10

I completely agree the 2.0 way of doing things makes far more sense conceptually.
After I go to Interfaces: (assign): bridges and add a bridge I expected to see that in interfaces but in fact you have to add another interface and assign the bridge to it. There are no clear instructions that set this out and to me it seems unintuitive. Could be just me. ::)

Steve

power_matz

Thank you for the instructions.
After doing all that I see that if the bridge only works if on the interface (re2 in my case) the bridge is assigned is up. If a device on re3 (also a member of the bridge) is the only one then the bridge is offline.
Is the a mistake on my side?

stephenw10

The bridge should be assigned to a non-physical interface such as OPT2. The members of the bridge are the physical interfaces, re2 re3 etc.
That way bridge itself will always appear as UP.

Steve

power_matz

ok, got that.
Do you think one rule for the bridge in the firewall is enough?
I don't have to define for each interface a rule, or?

stephenw10

Have read through the first few posts here: http://forum.pfsense.org/index.php/topic,20917.0.html

As I said above the default settings mean that the firewalling is done on the member interfaces not the bridge.
There are settings in Advanced: System Tunables: to change that. However I seem to remember reading that they may not work any longer. Try it and see. ;)


net.link.bridge.pfil_member 	Set to 0 to disable filtering on the incoming and outgoing member interfaces. 	default (1) 	

net.link.bridge.pfil_bridge 	Set to 1 to enable filtering on the bridge interface 	default (0)

Steve

power_matz

Yes, I read that before and tried it out. It seems that it don't work.
One device on a port in the bridge wants a IP per DHCP and this is blocked by the firewall. So adding the rule worked.

But I will give it another try after a reboot this evening.

stephenw10

Yes you may well have to reboot or at least reload something before those tunables take effect.

Steve

power_matz

OK! ;D
It is (always) as you said. Setting the tunables is working. I needed only some rules for the bridge interface and voila everything is running as I wanted.
Brilliant!
Thank you for your input.

stephenw10

No problem. :)
Hopefully this may prove useful for anyone else searching for bridging.

Steve