Watchguard Firebox X Peak platform
-
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
-
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.
-
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.
-
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.
-
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
-
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.
-
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
-
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? -
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
-
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? -
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
-
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.
-
Yes you may well have to reboot or at least reload something before those tunables take effect.
Steve
-
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. -
No problem. :)
Hopefully this may prove useful for anyone else searching for bridging.Steve
-
Minor update regarding my challenges booting images later than version 1.2.3 RC1:
I recently acquired a couple of Portwell NAR5060 boxes which are of a somewhat similar age as the Firebox X Peak and share some similar hardware. The good news is that I've got pfSense 2.0.1 nanobsd running on that hardware without modification and I hope to use this to free up the Firebox for bench testing.
I also recently got a mini-PCI VGA card, but I'm only halfway through figuring out its pinout and wiring a cable.
Hope to get a little further tomorrow… work has been busy, so progress is slow unfortunately.
-
You ever get the safenet card to work?
-
Edit: Anyone reading this: These are instructons are old and overly complex. See this post for a simpler updated solution.
Mostly for my own benefit because I completely hosed my install messing about with ACPI and have to reflash my CF card. ::)
Here's some concise instructions for installing the firebox lcd software.
Download the file with the driver, lcdd3.tar, from here (can't attach it to this post >:()
http://sites.google.com/site/pfsensefirebox/home/lcdd3.tar?attredirects=0
Copy it to the firebox to /var/tmp. This is a folder that only exists in memory and gets wiped at boot. I used WinSCP.
Connect to the box (with putty via ssh or serial or whatever). Then:[root@pfSense.local]/root(2): cd /var/tmp [root@pfSense.local]/var/tmp(5): tar -xvf lcdd3.tar x ./install-embed.lcdd.sh x ./lcdd/ x ./lcdd/drivers/ x ./lcdd/LCDd.conf x ./lcdd/lcdd.sh x ./lcdd/lcdproc x ./lcdd/LCDd x ./lcdd/drivers/curses.so x ./lcdd/drivers/sdeclcd.so x ./lcdd2.tar [root@pfSense.local]/var/tmp(7): ./install-embed.lcdd.sh [root@pfSense.local]/var/tmp(8): cd /lib [root@pfSense.local]/lib(10): /etc/rc.conf_mount_rw [root@pfSense.local]/lib(11): ln -s libc.so.7 libc.so.6 [root@pfSense.local]/lib(12): ln -s libkvm.so.4 libkvm.so.3 [root@pfSense.local]/lib(13): /etc/rc.conf_mount_ro [root@pfSense.local]/lib(14): /usr/local/etc/rc.d/lcdd.sh
And it should all be working! ;)
I have removed a few steps from the other instructions on the forum. I have included the newest driver in the tarball. I found I didn't need to alter the permisions of the install script.
I tested this on a fresh install of the embedded 1.2.3-release.
It will not work on 2.0 beta, I tried! :PSteve
Edit: It does work in 2.0 you have to sym link both libkvm.so.3 and libkvm.so.4 to libkvm.so.5
I have problem with installation. When I write on terminal: "./install-embed.lcdd.sh", I see: "mount: /dev/ad2s1a : Device busy" … Why I can't install ?
-
It's because that script was originally written for an embedded install of pfSense 1.2. The embbeded install (and the Nanobsd install) runs with the file system mounted read-only to minimise writes to flash media. The script remounts it as RW, installs the various files and then remounts it RO again. This won't work on a full install that you are running.
Besides that as I wrote at the top it's now very out of date.
Try this post instead. I can't say if that will work any better since it's still writtenb for Nano but I changed it to use the correct mount script rather than attempting to mount the filesystem directly. I have never tried it on a full install.
If that still doesn't work that you can just edit the install script, install3.sh, and remove the remount calls.Steve