Installing Pfsense in Transperant Bridge mode
-
Trying for a friendly bump. Any thought on what I may be doing wrong here?
-
Sure - apologies for the lack of detail. I'll include as much as I can here. A line drawing can be found here: https://dl.dropboxusercontent.com/u/16179320/Pfsense%20confi.jpeg
My attempts to access this resulted in the report:
Error (404)
We can't find the page you're looking for. Check out our Help Center and forums for help, or head back to home.I would find it more convenient if the diagram was attached to a reply in this topic.
Next, I disabled DHCP server on the LAN interface and then in Interfaces –> LAN, I set the type to "None" from "Static".
Did you also specify an IP address?
Why make the change? Members of a bridge don't need an IP address.
Sorry, I misread to "None" from "Static" as from "None" to "Static"I've tried this several different way, including adding another interface to the VM (OPT1), assigning it a static and doing all the configuration via OPT1. I then create the bridge between WAN and LAN and I get the same result - i'm locked out.
What IP address did you give OPT1? I don't know why you would have been locked out of OPT1. Assuming you gave sensible IP address assignments I would then attempt the access again while running a packet capture on interface OPT1 to verify the access attempt is actually getting to OPT1.
-
Apologies with regard to the diagram, I didn't realize you could attach to posts. The diagram is now attached to this post.
OPT1 was given an IP address in VLAN 154 - 10.11.54.50, but resulted in the same issue. As soon as the bridge was configured, I could no longer ping anything and had to reset the interfaces.
Thanks for your help wallabybob, it sounds like I've come up with a pretty unique application given that no one else has responded.
 -
OPT1 was given an IP address in VLAN 154 - 10.11.54.50, but resulted in the same issue.
That would result in an invalide configuration. Interfaces need to be in distinct subnets.
There are a couple of system tunables (see System -> Advanced, click on System Tunables tab) which control application of firewall rules (filtering) to bridges and their member interfaces:
net.link.bridge.pfil_member Set to 0 to disable filtering on the incoming and outgoing member interfaces.
net.link.bridge.pfil_bridge Set to 1 to enable filtering on the bridge interface
What are their values? Perhaps you are filtering on the bridge itself (fine if that is what you want) and consequently the firewall is block incoming traffic because the newly created bridge will be an OPTx interface with default firewall rules to block everything.
What do you want the values of those two tunables to be? I think I can devise a procedure to accommodate whatever you want.
-
Ideally, I wouldn't need a third interface on another VLAN just to access Pfsense - i would like to be able to access it via em1 (WAN - 10.11.54.2). OPT1 would be created as the bridge interface, but I don't think it would have a network address, right?
Currently net.link.bridge.pfil_member = 1 and net.link.bridge.pfil_bridge = 0
I have previously tried to enable filtering on the bridge interface (setting to 1), with the same negative results. I have not previously tried to disable filtering on the incoming and outgoing member interfaces, but I just tried it with the same result - once I enabled the bridge, I was no longer able to ping 10.11.54.2 and the web interface became inaccessible (note that pfil_bridge still set to 0).
The ultimate functionality I'm looking to gain from this configuration is to be able to simulate slow and lossy WAN environments on my LAN. To accomplish this, what should I set the system tunables for?
-
The ultimate functionality I'm looking to gain from this configuration is to be able to simulate slow and lossy WAN environments on my LAN.
How are you expecting to do that in pfSense? I am not aware of any pfSense mechanism that would help you configure that so maybe you would be better off using a different tool than pfSense.
But back to your issue with the transparent bridge you attempted to configure in pfSense.
1. After rebooting because you lost GUI access did you test the rebooted system or did you immediately reconfigure pfSense?
2. It is not clear to me what is wrong with your configuration. I notice you have two pfSense interfaces on VLANs apparently both bridged to VMWARE VLAN interfaces. I have no experience with VMWARE so if you still care enough about this particular configuration I suggest you do a packet capture on the pfSense WAN interface using tcpdump running on the pfSense console and with the -e command line option to display MAC addresses, start a ping to the pfSense WAN interface, verify the incoming ping and response are seen in the packet capture, then configure your pfSense bridge and see what happens in the packet capture. Lets reduce the complexity by attempting to verify the pings still get delivered to pfSense after the bridge is configured. -
You can do this using limiters. In fact that's what limiter pipes were originally designed for:
@http://www.cs.unc.edu/~jeffay/dirt/FAQ/dummynet.backup.html:It works by intercepting packets in their way through the protocol stack, and passing them through one or more pipes which simulate the effects of bandwidth limitations, propagation delays, bounded-size queues, packet losses, etc.
Steve
-
You can do this using limiters.
Thanks for the reminder. The "advanced" options to limiters allow setting of delay, queue size, packet loss rate etc. I'll start another topic on the confusing layout.
-
Anyone had an update on this issue? Though my problem is on the LAN side accessing the WEBGUI only. I set LAN and OPT1 to "none" and my WAN is set with a private ip address. I cannot access the WEBGUI using LAN connection but I can access it through WAN. Is this normal? The server was setup as a transparent bridge mode proxy server and it works. I just want to clarify if it is normal that I cannot access it thru LAN because it doesn't have an IP address.
-
You should start a new thread for this unless your setup is exactly the same as the OP.
Steve
