PSKs incorrect in ipsec.secrets bug: 4126

[eri--]

Can you share the contents of /var/etc/ipsec anonymized?

[Clouseau]

/var/etc/ipsec/

# ipsec.conf

# This file is automatically generated. Do not edit
config setup
	uniqueids = yes
	charondebug=""

conn con2
	fragmentation = yes
	keyexchange = ikev2
	reauth = yes
	forceencaps = no
	rekey = yes
	installpolicy = yes
	type = tunnel
	dpdaction = restart
	dpddelay = 10s
	dpdtimeout = 60s
	auto = route
	left = 19.13.xxx.xxx
	right = 19.15.xxx.xxx
	leftid = 19.13.xxx.xxx
	ikelifetime = 28800s
	lifetime = 3600s
	ike = aes256-sha1-modp1024!
	esp = aes256-sha1!
	leftauth = psk
	rightauth = psk
	rightid = 19.15.xxx.xxx
	rightsubnet = 10.0.1.0/24
	leftsubnet = 10.0.0.0/24

conn con4000
	reqid = 2
	fragmentation = yes
	keyexchange = ikev1
	reauth = yes
	forceencaps = no
	rekey = yes
	installpolicy = yes
	type = tunnel
	dpdaction = restart
	dpddelay = 10s
	dpdtimeout = 110s
	auto = route
	left = 19.13.xxx.xxx
	right = 19.15.xxx.xxx
	leftid = 19.13.xxx.xxx
	ikelifetime = 28800s
	lifetime = 3600s
	ike = aes256-sha1-modp1024!
	esp = aes256-sha1!
	leftauth = psk
	rightauth = psk
	rightid = 19.15.xxx.xxx
	aggressive = no
	rightsubnet = 10.0.4.0/24
	leftsubnet = 10.0.0.0/24

conn con5
	reqid = 3
	fragmentation = yes
	keyexchange = ikev1
	reauth = yes
	forceencaps = yes
	rekey = yes
	installpolicy = yes
	type = tunnel
	dpdaction = none
	auto = add
	left = 19.13.xxx.xxx
	right = %any
	leftid = 19.13.xxx.xxx
	ikelifetime = 28800s
	lifetime = 3600s
	rightsourceip = 10.0.222.0/24
	ike = aes256-sha1-modp1024!
	esp = aes256-sha1!
	leftauth = psk
	rightauth = psk
	aggressive = yes
	rightsubnet = 10.0.222.0/24
	leftsubnet = 10.0.0.0/24

	# Strongswan.conf

# Automatically generated config file - DO NOT MODIFY. Changes will be overwritten. 
starter {
load_warning = no
}

charon {
# number of worker threads in charon
threads = 16
ikesa_table_size = 32
ikesa_table_segments = 4
init_limit_half_open = 1000
install_routes = no
i_dont_care_about_security_and_use_aggressive_mode_psk=yes

cisco_unity = yes
interfaces_use = re0

# And two loggers using syslog. The subsections define the facility to log
# to, currently one of: daemon, auth.
syslog {
	identifier = charon
	# default level to the LOG_DAEMON facility
	daemon {
	}
	# very minimalistic IKE auditing logs to LOG_AUTHPRIV
	auth {
		default = -1
		ike = 1
		ike_name = yes
	}
}
	plugins {
		attr {
			subnet = 10.0.222.0/24
			dns = 10.0.0.1,10.0.0.xxx,8.8.8.8,4.4.4.4
			nbns = 10.0.0.xxx
			split-include = 10.0.0.0/24
			# Search domain and default domain
			28674 = ourdomain.local
			28675 = ourdomain.local
			28672 = ourdomain LTD - ALL ACCESS IS MONITORED
		}
		xauth-generic {
			script = /etc/inc/ipsec.auth-user.php
			authcfg = Local Database
		}
	}
}

	#ipsec.secrets

%any 19.15.xxx.xxx : PSK 0sSPSWPSWPSWPSWPSWPSWPSW=
%any 19.15.xxx.xxx : PSK 0sSPSWPSWPSWPSWPSWPSWPSW=
%any vpnuser1 : PSK 0sSPSWPSWPSWPSWPSWPSWPSW=
%any vpnuser1@mydomain.com : PSK 0sSPSWPSWPSWPSWPSWPSWPSW=
%any 1.1.1.3 : PSK 0sU2FmPSWPSWPSWPSWPSWPSW=
%any 1.1.1.2 : PSK 0sSPSWPSWPSWPSWPSWPSWPSW=
%any 1.1.1.1 : PSK 0sSPSWPSWPSWPSWPSWPSWPSW=

Secrets are here false of cource  8) but you can see what kind of identifier I tryed to use. IP's like 1.1.1.1 works, but like vpnuser1 or vpnuser1@mydomain.com are not!

[eri--]

If you remove the %any from the user@domain definition does it work?

[Clouseau]

@ermal:

If you remove the %any from the user@domain definition does it work?

Edit done - no change, see log:

charon: 08[IKE] <con5|12431> no shared key found for '19.13.xxx.xxx'[19.13.xxx.xxx] - '8.11.xxx.xx'[8.11.xx.xx]</con5|12431>

Change to IP identifier - all OK.

[eri--]

What is the other side?

Seems like the other side is not sending the correct identifier here?

[Clouseau]

@ermal:

What is the other side?

Seems like the other side is not sending the correct identifier here?

That might be correct analyze but it will send identifier correctly after I change identifier based on IP [myname@domain.com => 1.1.1.1.]
Question is why?

This issue stop me upgrading to 2.2. I have about 20 remote managed firewall sites that I don't want to loose contact after update. To get access to remote devices it would take a few days drive with car… so I must get this figured out. I see that others has similar kind of issues here too.

[eri--]

You still have not replied to my question, what is on the other end?

Are you sure that the other end is sending the right attributes?
Can you show me a log of your failure?

[cmb]

#4126 is most definitely fixed, there was a scenario with a Shrew Soft client where it worked in 2.1.5, and broke post-upgrade, which was fixed when #4126 was marked resolved. That scenario still works now.

Just because you change it to an IP and it works doesn't mean that isn't fixed, your client config might be broken, there could be some different issue.

Please answer questions when we're trying to help, we can't help you without knowing what the problem is.

What is the other end?
Logs of failure?

[Clouseau]

Ah sorry about not answering correctly:

ShrewSoft VPNClient (2.2.2) <=> pfSense 2.2-RELEASE

Or should there be used a better working free/OpenSource VPN Client available? Which one?

[newmember]

I deleted my 'Mobile Client'  under Tunnels, then went to 'Mobile Clients' tab and saw that "Create Phase 1" option was available.
I re-created Phase and Phase 2 and the vpn worked again.

Cheers

VPN: IPsec: Edit Phase 1: Mobile Client

Key Exchange version  V1
Internet Protocol      Ipv4
Interface  WAN
Description Mobile Client

Authentication method  Mutual PSK
Negotiation mode  Aggressive
My identifier  My IP Address

Encryption algorithm  AES 256
Hash algorithm    SHA1
DH key group  2
Lifetime  28800

NAT Traversal  Force
Dead Peer Detection  Enable  /  10  /  5

VPN: IPsec: Edit Phase 2: Mobile Client

Local Network  DMZ  (mine is DMZ but yours might be LAN)
Protocol  ESP

Encryption algorithms  AES 256 (only)
Hash algorithms    SHA1
PFS key group  2
Lifetime  3600