Project

General

Profile

Actions

Bug #9821

closed

pfSense IPsec not reload configs on connectivity issues with DDNS

Added by DRago_Angel [InV@DER] over 4 years ago. Updated almost 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
10/11/2019
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

If you configure IPsec to use static IP or or static DNS - all fine.
But when you have multiWAN environment with DDNS - it is an issue.
So possible solution add checkbox that thais host is DDNS or reload configs for any DNS hosts if IPsec loss connectivity. Or write external logic that handle domain changes used by IPsec.

Actions #1

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Rejected

IPsec with DDNS works fine for many users (myself included) -- you haven't presented any evidence that there is an actionable bug here.

Please post on the Netgate Forum or the pfSense Subreddit and describe your problem scenarios in more detail. If a specific problem can be identified there, a more accurate issue can be opened.

See Reporting Issues with pfSense Software for more information.

Actions #2

Updated by DRago_Angel [InV@DER] over 4 years ago

When My Tier1 goes offline on one end: IPsec begin to use Tier2 connection. But when Tier1 come back - second end still try to communicate over Tier2 IP. So ... what evidence can I provide?

Actions #3

Updated by DRago_Angel [InV@DER] over 4 years ago

At same time first end try communicate only over Tier1 IP and they can't do connection. Restart of strongswan fix this. And again: why I not get any notifications from SMTP if IPsec is Down? If you have working solution: help me pls on forum. https://forum.netgate.com/topic/147176/ikev2-site-to-site-and-multiwan-on-one-side/

Actions #4

Updated by DRago_Angel [InV@DER] over 4 years ago

Jim Pingle wrote:

IPsec with DDNS works fine for many users (myself included) -- you haven't presented any evidence that there is an actionable bug here.

Please post on the Netgate Forum or the pfSense Subreddit and describe your problem scenarios in more detail. If a specific problem can be identified there, a more accurate issue can be opened.

See Reporting Issues with pfSense Software for more information.

I created post on forum before create a bug, and no answer given. https://forum.netgate.com/topic/147176/ikev2-site-to-site-and-multiwan-on-one-side please help.
When I have missing main (tier1) WAN on second pfSense IPsec it reconnect to tier2 IP, but it not reconnect back when tier1 begin to be available. pfSense on Second pfSense try speak by WAN1, when First one still try use WAN2 IP for communication even when DDNS was changed back. DDNS record has cache time to 300s (minimum that HE.net is support). And manually stop of ipsec fully as a service and start again fix issue immediately, but any other manipulations - not.

Actions #5

Updated by Viktor Gurov almost 3 years ago

DRago_Angel [InV@DER] wrote:

Jim Pingle wrote:

IPsec with DDNS works fine for many users (myself included) -- you haven't presented any evidence that there is an actionable bug here.

Please post on the Netgate Forum or the pfSense Subreddit and describe your problem scenarios in more detail. If a specific problem can be identified there, a more accurate issue can be opened.

See Reporting Issues with pfSense Software for more information.

I created post on forum before create a bug, and no answer given. https://forum.netgate.com/topic/147176/ikev2-site-to-site-and-multiwan-on-one-side please help.
When I have missing main (tier1) WAN on second pfSense IPsec it reconnect to tier2 IP, but it not reconnect back when tier1 begin to be available. pfSense on Second pfSense try speak by WAN1, when First one still try use WAN2 IP for communication even when DDNS was changed back. DDNS record has cache time to 300s (minimum that HE.net is support). And manually stop of ipsec fully as a service and start again fix issue immediately, but any other manipulations - not.

looks like #6370

Actions

Also available in: Atom PDF