IPsec IKE secrets not written properly

4920441 0

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 IKEv2

The 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

4920441 0

@4920441-0

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

jimp

@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 with VGF 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.