Project

General

Profile

Actions
Copy link

Bug #12645

closed

``filterdns`` does not monitor remote IPsec gateways for IPv6 address changes

Added by Viktor Gurov about 3 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
2.7.0
Start date:
Due date:
% Done:

100%

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

Description

if Internet Protocol = IPv6 and Remote Gateway is FQDN, IPv6 address changes are not tracked
add_hostname_to_watch() doesn't support IPv6:

https://github.com/pfsense/pfsense/blob/master/src/etc/inc/ipsec.inc#L1557

https://github.com/pfsense/pfsense/blob/master/src/etc/inc/pfsense-utils.inc#L1874

Actions
Copy link
 #2

Updated by Jim Pingle about 3 years ago

  • Status changed from New to Pull Request Review
  • Assignee set to Viktor Gurov
  • Target version set to CE-Next
  • Plus Target Version set to 22.05
Actions
Copy link
 #3

Updated by Viktor Gurov over 2 years ago

  • Status changed from Pull Request Review to Feedback
  • Target version changed from CE-Next to 2.7.0
Actions
Copy link
 #4

Updated by Jim Pingle over 2 years ago

  • Subject changed from filterdns does not monitor IPv6 address change of the remote IPsec gateway to ``filterdns`` does not monitor remote IPsec gateways for IPv6 address changes

Updating subject for release notes.

Actions
Copy link
 #5

Updated by Azamat Khakimyanov over 2 years ago

  • Status changed from Feedback to Resolved

Tested on 22.05-RC (built on Sat Jun 04 14:22:59 UTC 2022)

I'm not sure what to test here but there is no add_hostname_to_watch($rg); in code of ipsec_setup_gwifs function in /etc/inc/ipsec.inc

I marked this Bug as resolved

Actions
Copy link
 #6

Updated by Alex Zaykov over 2 years ago

It's under IKE Endpoint Configuration ----> Remote Gateway (IPV6), to check if FQDN for AAAA record can be used to establish the tunnel

Actions
Copy link
 #7

Updated by Alex Zaykov over 2 years ago

tested on the latest built 22.05-RC (amd64) built on Fri Jun 17 06:34:36 UTC 2022
the bug is not fixed, Ipsec tunnel cannot be established with when FQDN is used to determine the endpoint

Actions
Copy link
 #8

Updated by Jim Pingle over 2 years ago

  • Status changed from Resolved to New
  • Plus Target Version changed from 22.05 to 22.09
Actions
Copy link
 #9

Updated by Jim Pingle over 2 years ago

  • Plus Target Version changed from 22.09 to 22.11
Actions
Copy link
 #10

Updated by Jim Pingle about 2 years ago

  • Plus Target Version changed from 22.11 to 23.01
Actions
Copy link
 #11

Updated by Jim Pingle about 2 years ago

  • Assignee deleted (Viktor Gurov)
Actions
Copy link
 #12

Updated by Jim Pingle about 2 years ago

  • Status changed from New to Feedback

This should be re-tested/re-confirmed. There have been several potentially relevant changes since the last report, including an overhaul of filterdns.

Actions
Copy link
 #13

Updated by Danilo Zrenjanin about 2 years ago

Tested against:

23.01-DEVELOPMENT (amd64)
built on Sat Dec 10 03:22:16 UTC 2022
FreeBSD 14.0-CURRENT

I successfully established IPsec using hostnames that resolve to IPv6. After changing the IPv6 address on the WAN interface and updating the upstream DNS accordingly with the new A record, the charon didn't immediately start using the newly assigned address.

It tried to use the old address, which was no longer assigned to the interface.

Dec 10 15:15:39    charon    10799    06[IKE] <con1|4> retransmit 3 of request with message ID 2
Dec 10 15:15:39    charon    10799    06[NET] <con1|4> sending packet: from fc01::4[500] to fc01::2[500] (80 bytes)
Dec 10 15:15:39    charon    10799    04[NET] error writing to socket: Can't assign requested address
Dec 10 15:16:02    charon    10799    06[IKE] <con1|4> retransmit 4 of request with message ID 2
Dec 10 15:16:02    charon    10799    06[NET] <con1|4> sending packet: from fc01::4[500] to fc01::2[500] (80 bytes)
Dec 10 15:16:02    charon    10799    04[NET] error writing to socket: Can't assign requested address
Dec 10 15:16:44    charon    10799    15[IKE] <con1|4> retransmit 5 of request with message ID 2
Dec 10 15:16:44    charon    10799    15[NET] <con1|4> sending packet: from fc01::4[500] to fc01::2[500] (80 bytes)
Dec 10 15:16:44    charon    10799    04[NET] error writing to socket: Can't assign requested address
Dec 10 15:18:00    charon    10799    08[IKE] <con1|4> IKE_SA con1[4] state change: ESTABLISHED => DESTROYING

After the IKE_SE got disconnected, it didn't try to establish the connection anymore. I noticed the same behavior with IPv4. After manually initiating the tunnel, it gets established normally using the new IP address resolved from the defined hostname under the Remote Gateway field.

I don't think there is an issue with filterdns deamon.

Actions
Copy link
 #14

Updated by Jim Pingle about 2 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

The filterdns part is likely OK then. IIRC there may be an open issue for that other quirk already, it seems familiar. If not we can open a new issue for it and look into it for 23.05 or after.

Actions
Copy link

Also available in: Atom PDF