OPNsense Forum
English Forums => Virtual private networks => Topic started by: Wyzard on March 21, 2021, 04:29:56 pm
-
I recently replaced a pfSense router with OPNsense, and had some difficulty setting up an IPsec tunnel that had worked in the past. The reason turned out to be a difference in how the phase-1 KeyID tags are handled. I'm posting this in case anyone else has the same problem.
The remote router runs pfSense 2.4.5. My local router was running pfSense 2.5 until recently, and I had a working IPsec tunnel between the two. The tunnel's phase 1 was configured to use KeyID tags for both ends: for the sake of example, let's say my local KeyID is "earth" and the remote one is "moon". (I actually use different tags, but the specific strings aren't what's important.)
I replaced my local pfSense router with one running OPNsense 21.1, and configured the IPsec tunnel with the same settings I'd been using in pfSense, but the tunnel failed to connect. Looking in the logs, the IPsec log on my end ended with:
09[ENC] <con1|17> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
09[IKE] <con1|17> received AUTHENTICATION_FAILED notify error
And on the remote pfSense router (I have admin access via SSH tunnel), the log said:
09[CFG] looking for peer configs matching 192.168.1.127[moon]...203.0.113.1[earth]
09[CFG] no matching peer config found
09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
09[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
In the above, I've replaced my actual WAN IP with 203.0.113.1 (an RFC 5737 example address). The remote router is behind a NAT, which is why its log shows 192.168.1.127 instead of its WAN IP.
Initiating the connection from the remote end had the same result, just in reverse: it was my local router that said "no matching peer config found" instead of the remote one.
Searching the web, I found that when other people have this problem, it's usually because they're using "my IP address" as the identifier, but the router is behind a NAT so the IP it sends doesn't match what the other side sees. In my case, that's a red herring: the remote router is indeed behind a NAT, but I'm using KeyID strings instead of IPs, specifically to avoid that problem. The configuration had worked when both sides were running pfSense.
After a lot of searching and trying various things that didn't help, I looked at the underlying config files on both routers and found the problem. On my local OPNsense router, the IPsec configuration (in /usr/local/etc/ipsec.conf) had the lines:
leftid = earth
rightid = moon
But on the remote pfSense router, the configuration (in /var/etc/ipsec/ipsec.conf) said:
leftid = "keyid:moon"
rightid = "keyid:earth"
The "keyid:" prefix is not something I'd ever typed. On both ends, in the web GUI I'd chosen "KeyID tag" from the dropdowns, and typed "earth" and "moon" in the text boxes. But pfSense prepends "keyid:" to the strings in the ipsec.conf file, and OPNsense doesn't.
Based on that, I went to the tunnel settings in the OPNsense web GUI and added the "keyid:" prefix to the values there. That doesn't seem like it ought to be necessary — I've already chosen "KeyID tag" from the dropdown, so it's redundant to have to write "keyid:" in the box below it — but it made ipsec.conf values match what pfSense uses. And with that change, the tunnel worked.
It looks like this behavior is something that's recently changed in pfSense: see https://redmine.pfsense.org/issues/9243 (https://redmine.pfsense.org/issues/9243) and https://forum.netgate.com/topic/153068/keyid-tag-issue-since-2-4-5 (https://forum.netgate.com/topic/153068/keyid-tag-issue-since-2-4-5). It sounds like there can be problems in some cases with not having the "keyid:" prefix, but I don't have experience with other IPsec implementations so I don't know whether the prefix is commonly used.
(Footnote #1: Actually, the log messages on the pfSense side originally showed something called "bypasslan" being selected, instead of saying "no matching peer config found", followed by some messages about bypasslan being rejected as unacceptable before sending the AUTH_FAILED response. I turned off "auto-exclude LAN address" under the IPsec advanced settings to make it stop using bypasslan, to rule that out as a potential cause of the problem.)
(Footnote #2: The IPsec log on the remote pfSense side also includes a line that says "received 1 cert requests for an unknown ca", because OPNsense apparently sends a certificate even when using PSK authentication for the tunnel. For awhile I'd thought that might be the cause of the problem, since it was the only obvious discrepancy from when my local router used to run pfSense, but it turns out to be harmless.)
-
Thanks for the detailed report. It looks like this should do the trick:
https://github.com/opnsense/core/commit/81fa4ec53d
You can apply this using the following command from the console:
# opnsense-patch 81fa4ec53d
All feedback welcome. We are unsure about backport to 21.1.x at this point as it could break interoperability between our minor releases.
Cheers,
Franco
-
This is a timely post as I think it matches the issue I'm running into as well.
Does this patch solve the issue if we are using other ID types as well?
In my use case I'm migrating my pfSense firewalls to OPNSense and I've been running into issues getting the site to site tunnel established between my new OPNSense firewall and the old pfSense firewall at the remote location. It'll be a few months before I can get out to the other site to exchange firewalls so I was hoping to keep my IPSec tunnel alive in the mean time.
Instead of KeyID's I'm using dynamic and distinguished names.
In the pfsense config I see leftid = dns:vpn2.domain.com
rightid = fqdn:vpn1.domain.com
OPNSense shows leftid = <ipaddress of vpn1>
rightid = vpn2.domain.com
For both firewalls I'm using Dynamic DNS for "My Identifier" on the respective box and Distinguished Name for the "peer identifier"
So it seems like OPNSense configuration, "Dynamic DNS" resolves the IP address and inserts it into leftid, while pfsense marks it with the dns: prefix and the fqdn that will be resolved.
Meanwhile Distinguished name in pfSense gets the prefix fqdn followed by the fqdn.
-
Yes, looks like the same mapping issue. Can you create a ticket so we can look into it?
https://github.com/opnsense/core/issues/new?assignees=&labels=&template=feature_request.md&title=
PRs also welcome... https://github.com/opnsense/core/commit/81fa4ec53d is a good starting point for similar changes.
Thanks,
Franco