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

    WatchGuard BOVPN and pfSense IPSec?

    Scheduled Pinned Locked Moved IPsec
    16 Posts 3 Posters 20.1k 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.
    • G
      gbrown100
      last edited by

      Thanks for posting this guide. I tried this but don't seem to get any kind of communication right now. I think the Watchguard is on a different firmware though and I'm not sure whether it's being done at the other end correctly…

      1 Reply Last reply Reply Quote 0
      • L
        Lonney
        last edited by

        Once I had it figured out it just worked. I spent maybe half a day ironing out a few issues, what I posted is the final configuration I came up with.

        I have been running a test tunnel between since I posted the info, and it's been 100% reliable between my cable provider at home, and the SDSL connection at work from another ISP.

        First place to look will be at the ipsec log file, and go from there.

        Also, not all ISPs configure their networks to pass IPSec traffic. If there is any NAT involved that could also be something to look in-to.

        The config as such that I posted is mostly derived from the WatchGuard documentation, so there isn't anything special about it  :)

        1 Reply Last reply Reply Quote 0
        • L
          Lonney
          last edited by

          I discovered that upon trying to add a second tunnel I would get an error when saving the Gateway settings in the WatchGuard.

          This is assuming that the remote endpoint(s) are floating around on a dynamic DHCP address. If your remote endpoints are on static addresses, you wont have this problem.

          The error was:

          Code : 109
          Error : 109
          This gateway is configured as 'Main Mode'. The settings are already used by gateway 'Test'. Local Interface: 'ACS-BXB', Remote gateway IP Address: 'Any'

          After digging around the WatchGuard documentation again, and searching the WatchGuard forums, I discovered you need to do a couple of things differently.

          Configuration changes and a Dynamic DNS service are needed:

          Dynamic DNS:

          This is the fun part. Find a free/paid Dynmaic DNS provider that is supported by pfSense.
          After some Googling around I found http://freedns.afraid.org/ It's free, looks fairly decent and is powered by FreeBSD!

          WatchGuard:

          Remote Gateway
             Specify the remote gateway IP address for a tunnel > Dynamic IP Address
             Specify the gateway ID for tunnel authentication > Domain Name > Enter your dynamic dns name here
             Tick "Attempt to resolve domain"

          Phase 1 Settings
            Mode: Agressive

          pfSense > VPN > IPSec > Phase 1:

          Negotiation mode: Aggressive
          My identifier: Distinguished Name: Enter the Dynamic DNS name.

          pfSense  > Services > Dynamic DNS:

          Service type: freeDns
          Interface to monitor: WAN
          Hostname: Enter your dynamic dns name here
          Password: Enter your "Authentication Token" provided by FreeDNS. To find out what the token is (this had me puzzled for a few minutes) go-to the dynamic dns page, and click on Direct URL. The token is the bit in the URL between the ? and the ==

          If pfSense is sitting behind another NAT device, at a guess you will need to use the wget script avaliable on the free dns dynamic dns page, and schedule it in cron to run every few minutes, or find some other way to trigger it.

          1 Reply Last reply Reply Quote 0
          • L
            Lonney
            last edited by

            @Lonney:

            If pfSense is sitting behind another NAT device, at a guess you will need to use the wget script avaliable on the free dns dynamic dns page, and schedule it in cron to run every few minutes, or find some other way to trigger it.

            I discovered that pfSense uses checkip.dyndns.org to identify the public IP address and reports this to FreeDNS, and not the actual WAN interface address. So the above comment about the wget script is redundant.

            1 Reply Last reply Reply Quote 0
            • L
              Lonney
              last edited by

              I found a gotcha with this setting:

              
              Add phase2 entry
                    Mode: Tunnel
                    Local Network
                       Type: LAN Subnet
              
              

              If there is no network link (cable disconnected) on the LAN interface it will cause a parse failure of /var/etc/racoon.conf when the service starts:

              
              racoon: ERROR: /var/etc/racoon.conf:43: "any" syntax error
              racoon: ERROR: fatal parse failure (1 errors)
              
              

              Line 43 will be missing the LAN address and will look something like this:

              
              sainfo subnet any subnet 10.1.21.0/24 any
              
              

              When it should look something like this:

              
              sainfo subnet 10.1.30.0/24 any subnet 10.1.21.0/24 any
              
              

              It seems if the LAN interface(s) have no link / are disconnected, the LAN address doesn't get put into the config file.
              A work around is to specify the local network address with the option Type set to Network and manually enter the address.

              1 Reply Last reply Reply Quote 0
              • L
                Lonney
                last edited by

                Also I have discovered that if aggressive mode is used - with the WatchGuard this becomes a necessity when using more than one tunnel with end points on dynamic addresses - Dead Peer Detection stops working. Example - reboot the endpoint (pfSense) , the tunnel stays active on the WatchGuard, once pfSense restarts the tunnel wont come back up until it expires.

                Disabling DPD in the WatchGuard appears to solve this problem, and soon as the endpoint closes the tunnel, the WatchGuard deactivates it almost immediately (as you might expect?). Pulling the WAN connection to pfSense and then reconnecting it, tunnel comes back up quickly.

                1 Reply Last reply Reply Quote 0
                • L
                  Lonney
                  last edited by

                  As seen in the pfSense IPSec log quite often:

                  
                  racoon: INFO: received RESPONDER-LIFETIME: 28800 seconds
                  racoon: INFO: received RESPONDER-LIFETIME: 128000 kbytes
                  racoon: WARNING: RESPONDER-LIFETIME: lifetime mismatch
                  
                  

                  Someone else noticed this and asked about it http://forum.pfsense.org/index.php?topic=39998.0.

                  Digging around in the WatchGuard config you can disable the 128000 kbytes lifetime.

                  Using the WatchGuard Policy Manager (it doesn't appear you can do this with the WebUI):

                  VPN Menu > Branch Office Tunnels > Select the tunnel > Edit > Phase 2 Settings > Add > Create a new Phase 2 proposal:

                  Make all the settings match the exiting one you are using - the default is ESP-AES-SHA1. Give it a useful name, and uncheck Force Key Expiration: Traffic.

                  Then remove the preexisting (default) proposal, save your settings, the tunnel will drop for a moment and come backup.

                  1 Reply Last reply Reply Quote 0
                  • L
                    Lonney
                    last edited by

                    Not sure what is going on this with issue, I have just completely removed the BOVPN config from the WatchGuard, saved, added it back again using the WatchGuard Policy Manger (not the WebUI) and this issue with DPD and Aggressive mode no longer exists.. When pfSense is rebooted or the WAN connection is pulled, the tunnel is closed on the WatchGuard, once pfSense restarts or the WAN connection is reconnected the tunnel comes up very quickly.

                    @Lonney:

                    Also I have discovered that if aggressive mode is used - with the WatchGuard this becomes a necessity when using more than one tunnel with end points on dynamic addresses - Dead Peer Detection stops working. Example - reboot the endpoint (pfSense) , the tunnel stays active on the WatchGuard, once pfSense restarts the tunnel wont come back up until it expires.

                    Disabling DPD in the WatchGuard appears to solve this problem, and soon as the endpoint closes the tunnel, the WatchGuard deactivates it almost immediately (as you might expect?). Pulling the WAN connection to pfSense and then reconnecting it, tunnel comes back up quickly.

                    1 Reply Last reply Reply Quote 0
                    • L
                      Lonney
                      last edited by

                      After months of testing - stable tunnel, and finally deploying pfSense running on an ALIX.2D13 kit running behind NAT on a privately managed network, the tunnel started dropping after the 8 hour lifetime expired and there was no traffic generated on the pfSense end for our network, the tunnel would re-establish it self as soon as there was some traffic - e.g. end user powers up laptop.

                      After some research I changed these two options:

                      Proposal Checking: Obey

                      Automatically ping host: Enter an address (apparently it doesn't need to be ping-able - just so long as it's on the remote end of the tunnel) - used the internal / LAN address of our router on the head office end where the tunnel terminates. From what I can find this helps keep the tunnel alive by having packets destined for the other end of the tunnel.

                      In the logs:

                      Apr 29 02:41:21	racoon: ERROR: unknown Informational exchange received.
                      Apr 29 02:41:23	racoon: ERROR: can't start the quick mode, there is no ISAKMP-SA,
                      Apr 29 02:41:27	racoon: ERROR: can't start the quick mode, there is no ISAKMP-SA,
                      Apr 29 02:41:31	racoon: ERROR: unknown Informational exchange received.
                      Apr 29 02:44:19	racoon: INFO: IPsec-SA request for  queued due to no phase1 found.
                      Apr 29 02:44:19	racoon: INFO: initiate new phase 1 negotiation: 192.168.3.7[500]<=>[500]
                      

                      The tunnel goes down, and then with-in a few minutes 'Automatically ping host' causes some packets to queue up for the remote network, and the tunnel comes back up - previously the tunnel would stay down for hours until the end users laptop would generate some packets for the remote network when turned on.

                      1 Reply Last reply Reply Quote 0
                      • W
                        wisowebs
                        last edited by

                        Lonney are you still using the mentioned configuration?  I am attempting to establish an IPSEC connection from PFsense to one of 2 Watchguard x10's and for the life of me cannot get it to work.  The logs yield nothing.  I can add the gateway with success.  When I add and apply my phase two settings I can get them to take only if the check box "add this tunnel to the BOVPN-Allow Policies" is unchecked

                        No dynamic DNS, static IP in each location for the WAN.  Any help anyone could toss my way I would greatly appreciate.  I have scrapped this forum and google with not much help outside of this post.

                        1 Reply Last reply Reply Quote 0
                        • W
                          wisowebs
                          last edited by

                          Here are a rough outline of my config.

                          Phase 1 - PF SENSE
                          WAN - Remote Gateway Static x.x.x.x
                          Mutual PSK
                          Mode MAIN
                          Proposal Checking - Obey
                          3DES
                          SHA1
                          DH = 1
                          Lifetime 28800
                          Nat Traversal Enable
                          DPD Enabled 20 seconds/5 Retries

                          Phase 2 - PF SENSE
                          Tunnel
                          Network
                          LOCAL - 172.10.0.0 /16
                          REMOTE - 172.13.0.0 /16
                          ESP
                          3DES
                          SHA1
                          PFS OFF
                          Lifetime 28800

                          Phase 1 - Watchguard
                          Local Gateway - Static
                          Remote Gateway - Static
                          Mode Main
                          Nat Traversal Enabled - 20 SEconds
                          DED Enabled - 20 seconds /5 Retires
                          IKE Keep Alive - Not Checked
                          SHA1
                          3 DES
                          DH = 1

                          Phase 2 - Watchguard
                          LOCAL IP Network IP - 172.13.0.0 /16
                          REMOTE IP Network IP - 172.10.0.0 /16
                          BI-Directional
                          "Add this tuneel to the BOVPN allow policies" is not checked it errors out, error = Code:13 Error:13 Unable to update configuration.
                          ESP-3DES-SHA1
                          PFS OFF
                          Multicast Nothing, blank

                          1 Reply Last reply Reply Quote 0
                          • L
                            Lonney
                            last edited by

                            @wisowebs:

                            LOCAL - 172.10.0.0 /16
                            REMOTE - 172.13.0.0 /16

                            FYI 172.0.0.0 - 172.15.255.255 is allocated to AT&T Internet Services.

                            Also I no longer work for the company that I set this up for, so I wont be 'developing' this any further :)

                            Hopefully it might help out others looking to marry pfSense and a WatchGuard together - when I first looked into setting this up there was not a lot of information around or any complete examples.

                            1 Reply Last reply Reply Quote 0
                            • W
                              wisowebs
                              last edited by

                              Yeah, sorry that was a rough metric

                              It actually is 172.16.0.0

                              and 172.19.0.0

                              Thanks for your reply, going to keep grinding on it, not sure what I am missing on the watchguard or in the pfsense interface.

                              1 Reply Last reply Reply Quote 0
                              • L
                                Lonney
                                last edited by

                                @wisowebs:

                                Lonney are you still using the mentioned configuration?  I am attempting to establish an IPSEC connection from PFsense to one of 2 Watchguard x10's and for the life of me cannot get it to work.  The logs yield nothing.  I can add the gateway with success.  When I add and apply my phase two settings I can get them to take only if the check box "add this tunnel to the BOVPN-Allow Policies" is unchecked

                                No dynamic DNS, static IP in each location for the WAN.  Any help anyone could toss my way I would greatly appreciate.  I have scrapped this forum and google with not much help outside of this post.

                                I didn't notice you had posted twice, I only saw the second one.

                                I'm really not too sure, before I got my config working I had no previous experience with IPSec in general. Most of the information I gleaned from the WatchGuard documentation which is not written in such a way as to help you configure it for non WatchGuard devices, and few bits and pieces from searching forums etc.

                                If you're having problems getting the WatchGuard configured you could try contacting WG for support. I had dealt with them a few times for other things, and they were very helpful.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.