• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

€500: Redundant site-to-site links + firewalling

Scheduled Pinned Locked Moved Expired/Withdrawn Bounties
6 Posts 3 Posters 4.8k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L
    ltning
    last edited by Mar 11, 2007, 9:55 AM

    Hi all,

    we have two sites both running twin pfSense firewalls with CARP. We use OpenVPN to link the sites - to clients/servers on either network the link allows seamless access to the other network.

    Two problems:
    #1 If a firewall on either side goes down, the OpenVPN link goes down and needs to be re-established. Clients are running applications connecting to servers on the other side using, among other things, ODBC, and the applications are not written in such a way that they handle such connection drops gracefully.

    #2 I have not been able to find any way of filtering traffic going in either direction through the link. Once the link is established, traffic between the sites appear to bypass firewall rules.

    Note: I don't care which mechanism is use to link the sites. OpenVPN, fancy routing, IPSec - whatever works. Encryption is a must, though.

    If the bounty is not high enough to make this happen soonish, let me know and I'll see what I can do.

    Thanks!
    /Eirik

    1 Reply Last reply Reply Quote 0
    • B
      billm
      last edited by Mar 11, 2007, 10:45 PM

      @ltning:

      Hi all,

      we have two sites both running twin pfSense firewalls with CARP. We use OpenVPN to link the sites - to clients/servers on either network the link allows seamless access to the other network.

      Two problems:
      #1 If a firewall on either side goes down, the OpenVPN link goes down and needs to be re-established. Clients are running applications connecting to servers on the other side using, among other things, ODBC, and the applications are not written in such a way that they handle such connection drops gracefully.

      #1 might be solvable with IPSec, I think you need to point your tunnel endpoints at the CARP addresses though.  There may or may not be a "failover ipsec" tab under the vpn->ipsec menu - I keep my local machines sync'd to our head branch, so it's sometimes difficult to remember what's been backported to the releng_1 branch.

      @ltning:

      #2 I have not been able to find any way of filtering traffic going in either direction through the link. Once the link is established, traffic between the sites appear to bypass firewall rules.

      Note: I don't care which mechanism is use to link the sites. OpenVPN, fancy routing, IPSec - whatever works. Encryption is a must, though.

      #2 is solved using a recent snapshot and IPSec.  You can filter inbound on the ipsec interface.

      –Bill

      pfSense core developer
      blog - http://www.ucsecurity.com/
      twitter - billmarquette

      1 Reply Last reply Reply Quote 0
      • L
        ltning
        last edited by Mar 13, 2007, 5:42 PM

        Hi there,

        @billm:

        #1 might be solvable with IPSec, I think you need to point your tunnel endpoints at the CARP addresses though.  There may or may not be a "failover ipsec" tab under the vpn->ipsec menu - I keep my local machines sync'd to our head branch, so it's sometimes difficult to remember what's been backported to the releng_1 branch.

        Indeed, I found that part. I have now established a working IPSec tunnel between the two primary firewalls, and added the public CARP IPs to the IPSec failover page in PFSense. However, I'm uncertain how to configure this on the secondary firewalls. Should I define tunnels there in exactly the same way? I would have expected there to be a way to have it sync that across automatically using XMLRPC …

        @billm:

        #2 is solved using a recent snapshot and IPSec.  You can filter inbound on the ipsec interface.

        Yes, as I now have it working with IPSec (I didn't get IPSec working last time), I also see that I can do this - brilliant.

        Thanks!
        /Eirik

        1 Reply Last reply Reply Quote 0
        • H
          hoba
          last edited by Mar 13, 2007, 8:49 PM

          @ltning:

          Indeed, I found that part. I have now established a working IPSec tunnel between the two primary firewalls, and added the public CARP IPs to the IPSec failover page in PFSense. However, I'm uncertain how to configure this on the secondary firewalls. Should I define tunnels there in exactly the same way? I would have expected there to be a way to have it sync that across automatically using XMLRPC …

          Yes, just add them in exactly the same way. Make sure to have the same failover settings there too (using the CARP IP). As the slave is not active and doesn't "own" the IP while in slave state it won't establish a tunnel unless it becomes master. Usually there will be a "blackout" for the tunnelconnections on failover of a few seconds only (3-5 seconds on my nexcom 1041 CARP cluster).

          1 Reply Last reply Reply Quote 0
          • H
            hoba
            last edited by Mar 14, 2007, 5:34 PM

            I'm closing this bounty as the original poster got it working and the feature already was there.

            1 Reply Last reply Reply Quote 0
            • B
              billm
              last edited by Mar 27, 2007, 2:09 AM

              @hoba:

              I'm closing this bounty as the original poster got it working and the feature already was there.

              Hoba and I will still split the bounty however ;-P  Glad it worked for ya, have fun!

              –Bill

              pfSense core developer
              blog - http://www.ucsecurity.com/
              twitter - billmarquette

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                This community forum collects and processes your personal information.
                consent.not_received