WatchGuard BOVPN and pfSense IPSec?

Lonney

I wonder if anyone can post a guide of sorts on how to correctly configure WatchGuard and pfSense, site to site tunnel for a remote office.

WatchGuard is an XTM23 on current OS 11.6.1 - this supports Branch Office VPN IPSec, and mobile VPN with IPSec, PPTP, SSL.

The "head office" is on a static IP. The "remote office" is on your usual ISP provided dynamic IP.

I have looked over every post on this forum related to IPSec and WatchGuard's but unable to glean enough information on how to do this. Several have commented that it works, one even promised they would post the information on how to do it, but never did. The WatchGuard documentation is a little too vague for me to piece it together.

Thanks!

Lonney
Fairbanks Alaska.

Lonney

I have managed to get this working.

This is my configuration:

Head Office uses a WatchGuard XTM 23 running firmware/OS 11.6.1. Internet IP address is static.
Remote Office uses pfSense 2.0.1. Internet IP address is dynamic.

For the sake of simplicity:
Example Local Network Address of Head Office: 10.50.1.0 /24
Example Remote Network Address: 10.50.2.0 /24

The Settings on the WatchGuard end were left to the defaults as much as possible, and pfSense was configured to match.

Configuring WatchGuard using the web interface:

VPN > Branch Office VPN
Gateways > Add
Gateway Name > Give it a meaningful name
General Settings Tab
Credential Method
Use Pre-Shared Key > Enter your key.
Gateway Endpoints > Add
Local Gateway
By IP Address > Enter the head office static internet IP address
Remote Gateway
Specify the remote gateway IP address for a tunnel > Dynamic IP Address
Specify the gateway ID for tunnel authentication > By User ID on Domain > Enter something meaningful this setting is purely cosmetic
Phase 1 Settings
Mode: Main
NAT Traversal: Enabled
IKE Keep-alive: Disabled
Dead Peer Detection: Enabled, Traffic idle timeout 20 seconds, max retries 5
Transform Settings > Add
Authentication: SHA1
Encryption: 3DES
SA Life: 8 hours
Key Group: Diffie-Hellman Group 2
Tunnels > Add
Tunnel Name > Give it a meaningful name
Gateway > Name specified for Gateway name above
Addresses Tab > Add
Addresses Tab
Local IP > Choose Type: Network IP > 10.50.1.0 /24
Remote IP > Choose Type: Network IP > 10.50.2.0 /24
Direction: bi-directional
Enable broadcast routing over the tunnel: Disabled
NAT Tab
NAT Settings > 1-to-1 NAT: Disabled
Phase 2 Settings Tab
Perfect Forward Secrecy
Enable Perfect Forward Secrecy: Enabled, Diffie-Hellman Group 2
IPSec Proposals
Phase 2 Proposals: ESP-AES-SHA1

Configuring pfSense using the web interface:

VPN > IPSec
Tunnels
Enable IPSec
Add phase1 entry
General information
Interface: WAN
Remote gateway: Enter the head office static internet IP address
Description: Something meaningful
Phase 1 proposal (Authentication)
Authentication method: Mutual PSK
Negotiation mode: main
My identifier: User distinguished name > Must match "By User ID on Domain" setting in WatchGuard
Peer identifier: Peer IP Address
Pre-Shared Key: Must match "Use Pre-Shared Key" in WatchGuard
Policy Generation: Default
Proposal Checking: Default
Encryption algorithm: 3DES
Hash algorithm: SHA1
DH key group: 2
Advanced Options
NAT Traversal: Enable
Dead Peer Detection: Enabled, 20 seconds, 5 retries
Add phase2 entry
Mode: Tunnel
Local Network
Type: LAN Subnet
Remote Network
Type: Network
Address: 10.50.1.0 /24
Description: Something meaningful

Phase 2 proposal (SA/Key Exchange)
Protocol: ESP
Encryption algorithms: AES (256 bits) (nothing else selected)
Hash algorithms: SHA1 (nothing else selected)
PFS key group: 2
Lifetime: 28800 seconds

Status > IPSec
The tunnel should so green, if not try connecting it.
If it doesn’t connect, check the log - Status > System logs > IPSec

It's really up-to you how open you make things, this will simply pass anything and everything.
Firewall > Rules
IPSec Tab
Add new rule
Action: Pass
Interface: IPSec
Protocol: Any
Source: Any
Destination: Any
Log: Unchecked

Traffic should now flow over the tunnel to any host.

This setup may not be 100% perfect ::)

gbrown100

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…

Lonney

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 :)

Lonney

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.

Lonney

@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.

Lonney

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.

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.

Lonney

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.

Lonney

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.

Lonney

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.

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.

wisowebs

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

Lonney

@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.

wisowebs

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.

Lonney

@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.