Bug #4147
closed
IPsec - IPv4 Phase 1 using FQDN resolves to IPv6 IP
0%
Description
When you define an IPv4 tunnel using FQDN as Remote gateway, this resolves to AAAA record (if any) and subsequently of course fails.
Updated by Chris Buechler almost 10 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.
Updated by Kill Bill almost 10 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.
Updated by Chris Buechler almost 10 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.
Updated by Ermal Luçi almost 10 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.
Updated by Ermal Luçi almost 10 years ago
- Status changed from Confirmed to Feedback
- Target version changed from 2.2.1 to 2.2
Updated by Jim Thompson almost 10 years ago
- Assignee set to Chris Buechler
Even though this is in feedback, I'm assigning it. (To Chris.)
Updated by Chris Buechler almost 10 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.
Updated by Kill Bill almost 10 years ago
Yeah, strongswan 5.2.2 does not fix anything here indeed.
Updated by Chris Buechler almost 10 years ago
- Target version changed from 2.2.1 to 2.2.2
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.2 to 2.2.3
Updated by Chris Buechler over 9 years ago
- Target version changed from 2.2.3 to 2.3
Updated by Jim Thompson about 9 years ago
- Assignee changed from Ermal Luçi to Renato Botelho
Time to bring in at least
https://wiki.strongswan.org/projects/strongswan/repository/revisions/f22c655b1102631f81de54ba43f12eefde93c883
remember to upstream it.
Updated by Chris Buechler about 9 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.
Updated by Chris Buechler about 9 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