IPsec IKE secrets not written properly
-
that does not help...
here, it seems the swanctl.conf file is somewhat wrong generated...
First, I deleted nearly all my site2site connections and despite every site2site connection had an IP as identifiert, the now generated swanctl.conf does NOT mach the webinterface config at all...
1.) Currently I deleted ALL Ipsec Tunnels Phase1+Phase2
2.) I generated a new tunnel IPsec with IKEv2The resulting swanctl.cfg seems fine in the config section, but in the secret section everything is pretty weired.... and yes, I already stoppend the ipsec stuff and rebootet a couple of times, but the result is like this...:
secrets { ike-0 { secret = foooooo id-0 = %any id-1 = @fqdn:home } ike-1 { secret = bar id-0 = %any id-1 = minititanic } ike-2 { secret = whatever id-0 = %any id-1 = outpost } ike-3 {...
I go 9 (!) IKE secrets despite the fact in the webinterface there is only one defined....
Sorry for the fuss but @netgate this is not good at all...
Some key feature which is essential like IPSec should be tested more thouroughly....
I am happy that I checked this upgrade first on my personal device, if one of our customer would have received this mess.... I don't wanna think about that :-(Cheers
4920441
-
I just tried another thing, which made me suspicous...
In the webinterface and an the other Site in my strongswan secrets there is the correct PSK listed.
When I look in the secrets section on the pfsense site I see a different key in the resulting swanctl.conf file /var/etc/ipsec/swanctl.conf which is completely different like so...
secret = 0sVGF.......................dg==
(the '.' are a several dozend of random characters)
Not all, but many start with '0sVGF' and end wih '=='
But the really strange thing is when I copy that key and configure it on the other site the connection is initiated immediatly
So may the be a bug in the webinterface or in the key generation from the webinterface to the config file as well?
I use this pfsense installation since about 2013 and upgraded it since then regularly. There were many many configs tested on this machine, so it is not freshly set up at all....
Cheers
4920441
-
@4920441-0 said in IPsec IKE secrets not written properly:
I go 9 (!) IKE secrets despite the fact in the webinterface there is only one defined....
Secrets entries are also defined by user keys under user accounts and on the PSK tab, not just from tunnel.
Sorry for the fuss but @netgate this is not good at all...
Some key feature which is essential like IPSec should be tested more thouroughly....We did test it thoroughly but there are only so many configuration variations we can test. We all use IPsec on 2.5.0/21.02 on our edges and have for many months during development. We use it for remote access IPsec. We use it in our labs. I personally have about 20 lab systems and most of them have interconnected IPsec tunnels with a variety of configurations.
@4920441-0 said in IPsec IKE secrets not written properly:
When I look in the secrets section on the pfsense site I see a different key in the resulting swanctl.conf file /var/etc/ipsec/swanctl.conf which is completely different like so...
secret = 0sVGF.......................dg==(the '.' are a several dozend of random characters)
Not all, but many start with '0sVGF' and end wih '=='I haven't seen other reports of anything like that. The secrets are base64 encoded and prefixed with
0s
so in your case, the part starting withVGF
all the way to the end (including the==
) is the encoded form of the string. If it didn't match, then the config didn't match in some way. Without seeing the whole keys it's hard to say what might have been the case there, but some top suspects would be extraneous characters in the field (extra whitespace, quotes, etc) which made them not match.That said, I tried running a few different strings through a base64 encoder and I didn't see any that started with
VGF
.