Bug #12645
closed
``filterdns`` does not monitor remote IPsec gateways for IPv6 address changes
Added by Viktor Gurov almost 3 years ago. Updated almost 2 years ago.
100%
Description
if Internet Protocol = IPv6 and Remote Gateway is FQDN, IPv6 address changes are not trackedadd_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
Updated by Viktor Gurov almost 3 years ago
Updated by Jim Pingle almost 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
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
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.
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
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
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
Updated by Jim Pingle over 2 years ago
- Status changed from Resolved to New
- Plus Target Version changed from 22.05 to 22.09
Updated by Jim Pingle over 2 years ago
- Plus Target Version changed from 22.09 to 22.11
Updated by Jim Pingle about 2 years ago
- Plus Target Version changed from 22.11 to 23.01
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.
Updated by Danilo Zrenjanin almost 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.
Updated by Jim Pingle almost 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.