Project

General

Profile

Actions

Bug #4147

closed

IPsec - IPv4 Phase 1 using FQDN resolves to IPv6 IP

Added by Kill Bill over 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
IPsec
Target version:
Start date:
12/26/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
Affected Architecture:
All

Description

When you define an IPv4 tunnel using FQDN as Remote gateway, this resolves to AAAA record (if any) and subsequently of course fails.

Actions #1

Updated by Chris Buechler about 9 years ago

  • Status changed from New to Feedback
  • Target version deleted (2.2)

where? Not seeing that. I have the same circumstance setup and everything in /var/etc/ipsec/ has the v4 IP, everything in setkey has the v4 IP. All correct.

Actions #2

Updated by Kill Bill about 9 years ago

Did not even look at the configs... Go to Phase 1 - put a dual-stack FQDN there. Go to Status - IPsec, select the entry and press the Connect button. The page freezes and never goes anywhere. Reload the page and watch this:

Never works. Gets working as soon as you replace the FQDN with IPv4.

Actions #3

Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to Confirmed
  • Target version set to 2.2.1

yeah seeing that now, the proper v4 IP is put into the config for ID, but the "right" ipsec.conf entry has the hostname, which is resolved as v6 if the FQDN has an AAAA and your system is configured to prefer v6. Rare circumstance, pushing to future.

Actions #4

Updated by Ermal Luçi about 9 years ago

Normally this should be fixed as part of latest 2.2 and switch to strongswan 5.2.2.

Now the resolve to address is done by strongswan and not by php as it is in 2.1.5.
This means it will try all the addresses in the response rather than only one put in config.

Actions #5

Updated by Ermal Luçi about 9 years ago

  • Status changed from Confirmed to Feedback
  • Target version changed from 2.2.1 to 2.2
Actions #6

Updated by Jim Thompson about 9 years ago

  • Assignee set to Chris Buechler

Even though this is in feedback, I'm assigning it. (To Chris.)

Actions #7

Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to Confirmed
  • Assignee deleted (Chris Buechler)
  • Target version changed from 2.2 to 2.2.1

the changes in strongswan 5.2.2 that help some FQDN circumstances don't change anything in this case. Where "right" is a FQDN, the host is dual stack, prefers IPv6, and the FQDN has an AAAA, it'll connect via v6 where the P1 is configured for v4. The P1 IP protocol has no impact on strongswan's config and it's just behaving as any dual stack application does, we'll need some means of overriding that behavior at some point though.

Actions #8

Updated by Kill Bill about 9 years ago

Yeah, strongswan 5.2.2 does not fix anything here indeed.

Actions #9

Updated by Jim Thompson about 9 years ago

  • Assignee set to Ermal Luçi
Actions #10

Updated by Chris Buechler about 9 years ago

  • Target version changed from 2.2.1 to 2.2.2
Actions #11

Updated by Chris Buechler almost 9 years ago

  • Target version changed from 2.2.2 to 2.2.3
Actions #12

Updated by Chris Buechler almost 9 years ago

  • Target version changed from 2.2.3 to 2.3
Actions #14

Updated by Jim Thompson over 8 years ago

  • Assignee changed from Ermal Luçi to Renato Botelho
Actions #15

Updated by Chris Buechler over 8 years ago

  • Affected Version changed from 2.2 to 2.2.x

that change will make strongswan 5.3.3 which should be coming soonish. Should be fine to wait until its release.

Actions #16

Updated by Chris Buechler over 8 years ago

  • Status changed from Confirmed to Resolved
  • Target version changed from 2.3 to 2.2.5

fixed by upgrade to strongswan 5.3.3

Actions

Also available in: Atom PDF