Bridge 3 OPT Interfaces to do this or is pfSense not capable? [SOLVED]



  • I bought the pfsense book and it doesn't quite cover this subject in detail..

    I'm trying to figure out if this is actually doable on pfSense.

    I have a main /30 that 3 other networks are routed to on  a single ethernet. I'm currently using a Cisco ASA that has the 3 other networks assigned to individual interfaces, all routed to the main interface which is routed to the /30.

    All hosts behind the firewall have and need public IP addresses (NAT is out of the question and beyond the scope of this post).

    The thing that I'm trying to figure out is can pfSense work in a mode (like bridged) to replace this ASA, allowing for the hosts behind the firewall to retain their public IP addresses AND have the ability to communicate with each other?

    ASCii Diagram (first public IP octets changed for obvious reasons)

    Networks                                    Interfaces
                          |                                                    |
    –-WAN-> 10.92.75.110/30 (Main IP) ----------> pfSense (fw1) ----- igb0 --> Static 10.92.75.110/30  WAN
                  10.69.93.190/26 --|                                |                      
                  10.69.93.222/27 --|-- All of these are       |                      
                  10.69.87.0/24    --|   routed to main IP    |                        
                                                                               |------------ igb1 --> OPT1
                                                                               |                                                                                                                
                                                                               |------------ igb2 --> OPT2
                                                                               |                                                                                      
                                                                               |------------ igb3 --> OPT3
                                                                               |
                                                                               |------------ bce0 --> LAN
                                                                               |
                                                                               |------------ bce1 --> Free



  • @kc8apf:

    What you want in this case is a transparent firewall.  You bridge the internal and external interfaces and then set rules on the bridge itself to control what can pass through.  You can do this with pf if you are willing to use 2.0 and play games with the setup (see a post by me related to setting up WAN as a bridge elsewhere on the forum).

    So you mean that 1.2.3 isn't able to do this? and that I have to use 2.0?

    @kc8apf:

    For what you are trying to do, it's probably more appropriate to use something like Vyatta or setup FreeBSD or Linux to do this directly.  pfSense is trying to handle a bunch of other things for home use that don't apply to your situation.

    I don't quite understand what you mean by the last sentence, can you elaborate?

    Thanks



  • What if I were to keep the ASA behind a pfsense machine, and bridge a single OPT interface with WAN, and have that OPT interface run to my current WAN (outside) interface on the ASA?

    Would that work or is it still a no go?



  • @jackhandy007:

    What if I were to keep the ASA behind a pfsense machine, and bridge a single OPT interface with WAN, and have that OPT interface run to my current WAN (outside) interface on the ASA?

    Would that work or is it still a no go?

    That doesn't really change the scenario much.  You'd still want pfSense to act as a transparent firewall by bridging some interfaces.  That isn't something pfSense is designed to do and thus doesn't support it well.  Other solutions like Vyatta handle it much better.



  • Uhm… what?
    Since when is pfSense unsuitable to firewall a bridged scenario?

    http://pfsense.trendchiller.com/transparent_firewall.pdf
    Is a howto, how to setup the pfSense as a transparent firewall.

    As for services that are running and not needed: you can always disable them.



  • Right, so 5 pages of instructions on how to set it up.  Most of which is bypassing the normal setup routine and turning off features and services.  Also, that is for 1.2.x which will put the rules on the wrong interfaces.  So, yes, pfSense isn't designed for this scenario and requires lots more work to make it happen than other solutions.  2.0 actually makes the setup worse due to the new handling of bridges.


  • Rebel Alliance Developer Netgate

    @kc8apf:

    Right, so 5 pages of instructions on how to set it up.  Most of which is bypassing the normal setup routine and turning off features and services.  Also, that is for 1.2.x which will put the rules on the wrong interfaces.  So, yes, pfSense isn't designed for this scenario and requires lots more work to make it happen than other solutions.  2.0 actually makes the setup worse due to the new handling of bridges.

    Just because bridging is not the default behavior does not mean it isn't suitable. That document is 5 pages long because (a) it's for an older version so some of those steps are unnecessary, and (b) there are lots of screenshots.

    In 1.2.3 all you need to do is bridge LAN (or any OPT interface) to WAN and add firewall rules. Hardly a complex task. Filtering bridge happens automatically, and IIRC automatic NAT won't apply to a bridged interface (though you could still turn it off it you want).

    In 2.0 it is a little more complex, since you have to create the bridge and add interfaces to it, but it's still not that complex of a task and you have even more options available to you.

    Someone needs to come up with an updated howto to replace that outdated PDF, or if someone could come up with a bridging wizard that could also help out.



  • To follow up, Chris B was gracious enough to answer this for me on the mailing list.

    The solution was to just route the public IP's to the interfaces (as described in section 8.2 of the book).


Log in to reply