VPN: IPsec gateway will not connect when using Dynamic DNS
-
I have a working configuration that I make one change to (moving from fixed IP to dyndns), and it stops working.
This is either a bug, or admittedly I might be doing something wrong.Currently testing with:
2.2.5-DEVELOPMENT (amd64)
built on Sat Jul 25 19:57:37 CDT 2015
FreeBSD 10.1-RELEASE-p15Note, I originally tested with 2.2.4 with the same results, then applied the gitsync update to move from 2.2.4 to 2.2.5
This pfsense router sits behind another WAN router with tcp ports open that allows the VNP to function. I have a working configuration that has My Identifier configured as the IP address with the public IP address of the WAN router (see config images below).
The configuration used is a working ipsec IKE V2 with P2 ESP.
The second image shows a configuration one with a single change to the working configuration, setting My Identifier to Dynamic DNS, which does not work. Some of the confidential configuration settings have been changed to generic values, but you will get the idea looking at the images.The first configuration works.
This second configuration using Dynamic DNS does NOT work.
-
Here are some of the errors shown in the IPsec logs:
Oct 16 08:46:23 charon: 09[CFG] <bypasslan|554>constraint requires public key authentication, but pre-shared key was used
Oct 16 08:46:23 charon: 09[CFG] <bypasslan|554>selected peer config 'bypasslan' inacceptable: non-matching authentication done
Oct 16 08:46:23 charon: 09[CFG] <bypasslan|554>no alternative config found
Oct 16 08:46:23 charon: 09[IKE] <bypasslan|554>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Oct 16 08:46:23 charon: 09[IKE] <bypasslan|554>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Oct 16 08:46:23 charon: 09[ENC] <bypasslan|554>generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]</bypasslan|554></bypasslan|554></bypasslan|554></bypasslan|554></bypasslan|554></bypasslan|554> -
So far it is all quiet on this one.
Did I put this in the right topic?
If not, could a moderator move it to the correct topic? to see if anyone has any idea? -
It seems that once you change your identifier to Dynamic DNS, you have to use PKI, not a pre-shared key.
I would set up a CA in the Certificate Manager, issue the appropriate server and client certificates, then reconfigure accordingly.
-
It seems that once you change your identifier to Dynamic DNS, you have to use PKI, not a pre-shared key.
I would set up a CA in the Certificate Manager, issue the appropriate server and client certificates, then reconfigure accordingly.
That would be a workaround. There's no reason why using Dynamic DNS as your identifier still shouldn't work.
-
Using main mode I presume?
"When using IKEv1 an additional complexity arises in the case of authentication by preshared secret: the responder will need to look up the secret before the Peer's ID payload has been decoded, so the ID used will be the IP address."
https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecretsThat's only true of main mode though, aggressive sends the ID in the clear. Though I wouldn't recommend switching to aggressive mode to use non-IP identifiers in that case. Use IKEv2, RSA rather than PSK if IKEv1 is a must, or "any" as the peer identifier if you have to stick with IKEv1 PSK.
We should add input validation to prevent such invalid configs.
-
An update on this.
I was concerned about the one pfsense device being located behind a router as causing these issues. One of the pfsense devices has a public IP address on it's WAN port and no interposing router. So I tried the same test, as shown above, but using the pfsense device not behind a router with a dynamic dns setup. The result was exactly the same. I did read some much older forum discussions where apparently this dynamic dns setup used to work and was expected to work, and then stopped working with some version number. I remember one of people saying that the dynamic dns entry should resolve to an IP address.
In the past I have configured Cisco business routers in a very similar way and they supported a dynamic dns entry in this equivalent location.
I did make a quick unsuccessful attempt at using the Mutual RSA key using this quick start guide as a starting point. https://doc.pfsense.org/index.php/IPsec_RSA_Authentication_Quick_Start
In the guide it wasn't clear to me as to exactly which type of keys to generate, i.e. server key, user key, etc …
I noticed they were recommending using IP addresses in the alternatives name, which defeats the whole point of dynamic dns.
i.e. they had ==> add an Alternative Names entry with a Type of IP and the Value set to the IP address of the WAN interface on Firewall A.There are many other tests that I ran trying different combinations unsuccessfully, and a few more I intend to try.
-
The issue with main mode is it has to have the PSK available by IP.
For instance, with Cisco IOS:
When using IKE main mode, preshared keys are indexed by IP address only because the identity payload has not yet been received. This means that the hostname keyword in the identity statement is not used to look up a preshared key and will be used only when sending and processing the identity payloads later in the main mode exchange. The identity keyword can be used when preshared keys are used with IKE aggressive mode, and keys may be indexed by identity types other than IP address as the identity payload is received in the first IKE aggressive mode packet.
If crypto isakmp identity hostname is configured as identity, the preshared key must be configured with the peer’s IP address for the process to work when using IKE in main mode.The "must be configured with the peer's IP address" is the part you're missing.
Or a Cisco ASA:
LAN-to-LAN tunnel groups that have names that are not an IP address can be used only if the tunnel authentication method is Digital Certificates and/or the peer is configured to use Aggressive Mode.
They make it sound like it's completely non-workable there, but there are workarounds like the above mentioned for IOS on the ASA too.
It's best to stick with IP identifiers with main mode PSK, but it is possible to have functional configs with non-IP IDs if you also have a means of matching on the IP too.
If you go to VPN>IPsec, Pre-Shared Keys tab, and add an identifier with your FQDN and PSK there, that should work. FQDNs used there are put into ipsec.secrets as the FQDN without the leading @ forcing it to a FQDN type, which means strongswan will resolve it to an IP and use the IP. That'll leave you with both the DN and IP identifiers, which will meet the requirement for main mode PSK.
I did read some much older forum discussions where apparently this dynamic dns setup used to work and was expected to work, and then stopped working with some version number.
What I'm talking about here is a fact of life with IKEv1 main mode using PSK. It's the nature of IPsec. It's easy to get wrong given people don't understand the ID requirements. Where it worked, people were probably using aggressive mode. A few may have been using main mode and added an additional PSK so they could match properly on both the IP and FQDN IDs. Where a workable config, this has always worked.
Though I'm not planning on adding the input validation to prevent this, because it is potentially valid, if sub-optimal since you must have two PSK config entries. Just did a setup with a support customer today where the remote end had its ID to DN with main mode even though everything involved was static IP, and couldn't be changed easily (third party device), so had to add an entry on the PSK tab for the IP so it could match both the DN and IP.
-
I noticed they were recommending using IP addresses in the alternatives name, which defeats the whole point of dynamic dns.
i.e. they had ==> add an Alternative Names entry with a Type of IP and the Value set to the IP address of the WAN interface on Firewall A.That's for a typical static IP to static IP setup. You can use type DNS with FQDN instead.
-
I have a working version now. (see image below)
When I set up the Peer Identifier to Distinguished as a FQDN on both sides, it started working.
I was also using this recommendation from cmb:@cmb:
If you go to VPN>IPsec, Pre-Shared Keys tab, and add an identifier with your FQDN and PSK there, that should work. FQDNs used there are put into ipsec.secrets as the FQDN without the leading @ forcing it to a FQDN type, which means strongswan will resolve it to an IP and use the IP. That'll leave you with both the DN and IP identifiers, which will meet the requirement for main mode PSK.
0
Once the IPsec tunnel was working again I started backing out changes, and was able to remove the VPN>IPsec, Pre-Shared Keys tab, with identifiers as shown above and it still worked.One note on this, my remote side was setup like the main site in that I was using dynamic DNS entries and distinguished names in the My identifier and Peer identifier because if I left them as shown in the first post with IP addresses it didn't work.
Thanks for the help. Hope this helps someone else down the road …
-
Once the IPsec tunnel was working again I started backing out changes, and was able to remove the VPN>IPsec, Pre-Shared Keys tab, with identifiers as shown above and it still worked.
Only because they were already there before. Reboot, or stop then start strongswan, and it'll stop working again (or possibly later during rekey without stop/start).
-
I didn't mention it in the last post, but after the changes, rebooted both sides, and the tunnel came up. But just went ahead and added this VPN>IPsec, Pre-Shared Keys tab, with identifiers back in, rebooted, and the tunnel came up again. Will leave this as the new running config and will watch it for stability to make sure it survives rekey and all.
@cmb:
Only because they were already there before. Reboot, or stop then start strongswan, and it'll stop working again (or possibly later during rekey without stop/start).