Question

I cannot configure an IPSec VPN on GUI with a "user fqdn" as local identificator because the GUI is rejecting identifiers as "[email protected]" Anything with a @ is just rejected and the box is marked in red. This is an artificial limitation on GUI as if I edit file /etc/config/strongswan and put "option my_identifier '[email protected]' " it works when connecting on the other side (it has user fqdn restrictions on a Cisco RV325).

So basically it is a GUI artificial restriction and I don't understand why.

Is it possible to have it fixed on any future firmware?

In the Secret's ID selector, it is allowed to have such a selector. But basically it is not working becasue you cannot use the @ in the IPsec section. And if using an identifier with @ I must use the %any label wich prevents me from having more than 1 IPsec tunnels with different pre-shared keys (is that correct ???)

Answer 1

Hi,

I just want to make sure - what is the device and firmware you're using right now?

EB.

Comments

Hello.

Thanks for your response.

It happened using RUT955 with RUT9XX_R_00.06.06.1

Yesterday discovered and updated to RUT9XX_R_00.06.07 and it seems to be fixed. But as far as I know this is not a release firmware.

The "clone" profile is more than welcome in this release. I spent several hours trying to find a way for cloning profiles manually in the previous firmware... Did it, but costed too much time...

I will test the user fqdn in a few moments. Will report back if it is working.

Edit: Both "fqdn" and "user fqdn" are working on RUT9XX_R_00.06.07 on an IKEv1 IPSec VPN to a Cisco RV325. But only if I use "%any" as "Secret's ID selector". If I try to use directly the identifier I get this on logs:

Tue Oct 13 11:46:18 2020 daemon.info syslog: 14[IKE] received Cisco Unity vendor ID

Tue Oct 13 11:46:18 2020 daemon.info syslog: 14[IKE] received DPD vendor ID

Tue Oct 13 11:46:19 2020 daemon.info syslog: 14[IKE] calculated HASH does not match HASH payload

Tue Oct 13 11:46:19 2020 daemon.info syslog: 14[ENC] generating INFORMATIONAL_V1 request 96038265 [ HASH N(AUTH_FAILED) ]

---

Another point here is:

How are the preshared keys assigned to a certain IPSec connection?

Must the "Secret's ID selector" match the connection "My Identifier"? If so, why does it not work when putting [email protected] on both the "Secret's ID selector" and the connection "My Identifier"?

It only works when using "%any" as "Secret's ID selector", when then it restricts me to having only 1 preshared key for all IPSec connections I make. This is not desiderable.

Why can't I select the type of ID inside the editable parameters for the IPSec connection and put the preshared key right there too?

---

Hi,

My identifier is the value that shouldn't be touched, as it will take by default your WAN IP address. In other cases, FQDN or %any is taken. As long as both sides agree on the same value - it will work.

About Secret's ID selector: 

Each secret can be preceded by a list of optional ID selectors. A selector is an IP address, a Fully Qualified Domain Name, [email protected] or %any.
NOTE: IKEv1 only supports IP address ID selector.

So let's say if you want pre-shared key to be used only one IP, there in Secret's ID selector mention that IP. When a connection will be initiated - it will check against these options.

EB.

---

If "My Identifier" can't be touched, then it must be what the other part is expecting. In this case the RV325 expect it to be the user fqdn "[email protected]".

If I configure the "Secret's ID selector" as "[email protected]" with the corresponding preshared key it won't work at all. I have tried with all kind of prefixes as @@ as per the Strongswan documentation for making it not interpret the string as another ID.

If I configure the "Secret's ID selector" as "%any" with the corresponding preshared key it works as expected, but it prevents me to have more than 1 preshared key for any other IPSec connection I may have.

So, that IKEv1 only supports IP address ID selector is not true. It must support any other ID or the connection would not have been made with "%any". (Tested and all traffic is passed OK from both sides of the VPN.)

If it only supports address ID then it is more than inconvenient as this part of the connection has dynamic IP.

This is the log for the connection if used with "%any"

---

Tue Oct 13 15:01:52 2020 daemon.info syslog: 09[IKE] sending retransmit 1 of request message ID 0, seq 1

Tue Oct 13 15:01:52 2020 daemon.info syslog: 09[NET] sending packet: from 178.x.x.x[500] to 84.x.x.x[500] (467 bytes)

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[NET] received packet: from 84.x.x.x[500] to 178.x.x.x[500] (444 bytes)

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[ENC] parsed AGGRESSIVE response 0 [ SA KE No ID V NAT-D NAT-D HASH V V ]

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[IKE] received NAT-T (RFC 3947) vendor ID

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[IKE] received Cisco Unity vendor ID

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[IKE] received DPD vendor ID

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[IKE] remote host is behind NAT

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[IKE] IKE_SA RV320[1] established between 178.x.x.x[[email protected]]...84.x.x.x[192.x.x.x]

Tue Oct 13 15:01:53 2020 authpriv.info syslog: 10[IKE] IKE_SA RV320[1] established between 178.x.x.x[[email protected]]...84.x.x.x[192.x.x.x]

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[IKE] scheduling reauthentication in 28584s

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[IKE] maximum IKE_SA lifetime 28764s

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[ENC] generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[NET] sending packet: from 178.x.x.x[4500] to 84.x.x.x[4500] (108 bytes)

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[ENC] generating QUICK_MODE request 2136998740 [ HASH SA No KE ID ID ]

Tue Oct 13 15:01:53 2020 daemon.info syslog: 10[NET] sending packet: from 178.x.x.x[4500] to 84.x.x.x[4500] (380 bytes)

Tue Oct 13 15:01:53 2020 daemon.info syslog: 11[NET] received packet: from 84.x.x.x[4500] to 178.x.x.x[4500] (364 bytes)

Tue Oct 13 15:01:53 2020 daemon.info syslog: 11[ENC] parsed QUICK_MODE response 2136998740 [ HASH SA No KE ID ID ]

Tue Oct 13 15:01:54 2020 daemon.info syslog: 11[IKE] CHILD_SA RV320{1} established with SPIs cc0c9f85_i c8a4bd3d_o and TS 192.168.2.0/24 === 192.168.16.0/24

Tue Oct 13 15:01:54 2020 authpriv.info syslog: 11[IKE] CHILD_SA RV320{1} established with SPIs cc0c9f85_i c8a4bd3d_o and TS 192.168.2.0/24 === 192.168.16.0/24

Tue Oct 13 15:01:54 2020 local0.notice vpn: + 192.x.x.x 192.168.16.0/24 == 84.x.x.x -- 178.x.x.x == 192.168.2.0/24

Tue Oct 13 15:01:54 2020 daemon.info syslog: 11[ENC] generating QUICK_MODE request 2136998740 [ HASH ]

Tue Oct 13 15:01:54 2020 daemon.info syslog: 11[NET] sending packet: from 178.x.x.x[4500] to 84.x.x.x[4500] (60 bytes)

Answer 2

Found a working configuration !!!

It seems that the part "%any" must be part of ALL "Secret's ID selector" besides the proper user fqdn added to a preshared key, for it to work properly.

So, for "preshared key 1"  the values in "Secret's ID selector" must be "%any" AND "[email protected]".

For "preshared key 2"  the values in "Secret's ID selector" must be "%any" AND "[email protected]".

In the test I have done, both preshared keys can be distinguished from its user fqdn used on two different IPSec connections, and both have connected using user fqdn ID.

Here is an example of my configuration:

In the above example both keys can coexists, be used as user fqdn and be referred from different connections, at least with a Cisco RV.

To use this the firmware must be RUT9XX_R_00.06.07. Previous version did not accept entries with '@' as "My Identifier".

I hope this would be of help to someone.