PSKs incorrect in ipsec.secrets bug: 4126
-
This bug is still active and ipsec connections fails with Key ID string identifier. I can't establish Mobile VPN connection with myname@email.com Key ID string identifier, but changing that as IP address like 1.1.1.1 it works. (Mutal PSK)
https://redmine.pfsense.org/issues/4126
Any new when this will be fixed? Can't upgrade to latest 2.2 RELEASE because we will loose a lot of Mobile user connections…
-
Can you share the contents of /var/etc/ipsec anonymized?
-
/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!
-
If you remove the %any from the user@domain definition does it work?
-
@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.
-
What is the other side?
Seems like the other side is not sending the correct identifier here?
-
@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.
-
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? -
#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? -
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?
-
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 ClientAuthentication method Mutual PSK
Negotiation mode Aggressive
My identifier My IP AddressEncryption algorithm AES 256
Hash algorithm SHA1
DH key group 2
Lifetime 28800NAT Traversal Force
Dead Peer Detection Enable / 10 / 5VPN: IPsec: Edit Phase 2: Mobile Client
Local Network DMZ (mine is DMZ but yours might be LAN)
Protocol ESPEncryption algorithms AES 256 (only)
Hash algorithms SHA1
PFS key group 2
Lifetime 3600