Project

General

Profile

Actions

Feature #4591

open

IPSec Failover Support for IP Addresses instead of Dynamic DNS / Failover Group

Added by Eric Hullibarger almost 11 years ago. Updated about 13 hours ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
04/07/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:

Description

Allow for IPSec failover IP instead of using a dynamic dns name. Most routers allow for this and it is an easier setup then doing dynamic dns and you are not relaying on a 3rd party service to make you failover to work plus if the remote side doesn't update the DNS quickly you could still end up with downtime.


Related issues

Has duplicate Feature #12856: New Feature RequestDuplicate

Actions
Actions #1

Updated by Chris Buechler about 10 years ago

  • Category set to IPsec
Actions #2

Updated by Jim Pingle over 6 years ago

See also: #6384

Actions #3

Updated by Viktor Gurov over 5 years ago

Actions #4

Updated by Jim Pingle about 4 years ago

Actions #5

Updated by Stephen Simon about 16 hours ago

Adding comment per request of NetGate TAC support after working with them via ticket "43897451036".

It would be nice to be able to specify an additional WAN IP in a tunnel on the pfSense side so that if the primary WAN IP becomes inaccessible pfSense will attempt to establish an IPsec tunnel over the defined secondary WAN IP address.

In this particular scenario, for context:
  • There is a peer firewall with two ISPs.
  • We have a single pfSense with a single WAN IP address.
  • DDNS, with Palo Alto, is too slow to updates, its minimal update window is 1 hour.
  • pfSense is currently in responder only mode with policy based tunnels on both sides but leveraging WAN monitoring on the Palo Alto side to send traffic across a different WAN interface if the primary WAN goes down, which works.
    • It would be nice to be able to define a backup WAN IP in a single pfSense tunnel to an endpoint (firewall) with two WAN IPs.*
The currently workaround I arrived that, in this particular scenario between a Palo Alto with two WAN IPs and a pfSense with a Single WAN IP is:
  • Retain two tunnels on pfSense.
  • On the pfSense side: * Change the P1 on both WAN1 and WAN2 tunnels on pfSense and the following settings under "Advanced Options". * Change "Child SA Start Action" from "Default" to "None (Responder Only)." * Change "Child SA Close Action" from "Default" to "Close connection and clear SA".
  • On the Palo Alto side: * Confirm primary tunnel route metric is 10 and "Admin Distance" is "default". * Change secondary tunnel route metric to 100 and "Admin Distance" is default." * In "Network -> Network Profiles -> Monitor" ensure "FailoverWANProfile" is created with an "Action" of "Fail Over" and an interval of "3" (seconds) and a Threshold of "5". * Edit the Primary IPsec tunnel so ONLY IT HAS THE FAILOVER MONITOR! The secondary IPsec tunnel does NOT HAVE/GET THE FAILOVER MONITOR!
  • I THINK what was tripping up the tunnel monitoring portion and failing back to WAN 1 is that since both tunnels are in a single VRF (Virtual Routing and Forwarding) interface, it will actively try to establish VPNs over both ISPs.
  • If both tunnels are configured with a failover technically they'd both fail to each other if the other is down, now logically, this makes sense, if WAN 2 goes down fail to WAN 1, but we already have that configured in the WAN 1 tunnel monitor.
  • So, WAN 1 goes down, tunnel monitor triggers, route gets updated that says use the tunnel on WAN 2 (Palo Alto), then traffic flows over WAN 2 to pfSense. (Keep in mind, pfSense still has two tunnels up to each WAN interface - so two tunnels per site in pfSense) BUT it's the Palo Alto making the route/tunnel priority decision based on the tunnel failover and route metric. (Now, this does go against policy based routing because pfSense isn't aware of what it should send traffic over however the Palo Alto says "well, my WAN 1 tunnel has a metric of 10, so this route will win which means I'm sending IPsec traffic over my WAN1 tunnel." Now, I am presuming, pfSense, on its side, will see traffic coming in that tunnel and is smart enough to send it out the same tunnel even though it has two tunnels with different WANs but with the same P2s." Like, there is some smart routing that takes place.
  • What I did NOT do that pfSense recommended yesterday to prevent duplicates of IPsec tunnels but because Palo Alto support has been absolutely miserable to work with it, is, I did NOT change the "Remote Gateway" value to "0.0.0.0" and keep only a single tunnel since, due the way Palo Alto is configured and without having to re-setup/change the VRF (this will break communication everywhere on the Palo Alto), I left two tunnels to each WAN IP on the Palo Alto present on the pfSense so pfSense has two tunnels per location, one per WAN.
Actions #6

Updated by Marcos M about 13 hours ago

I recommend taking a look at this forum thread and discussing further on the forum if needed.

Actions

Also available in: Atom PDF