IPsec MikroTik <–> pfSense 2.2 broken
-
Yea I had another thread about something similar for pfsense to pfsense. Think there are some changes in the new IPSEC which changes previously working behaviour.
-
Still, there's an issue. As per the MikroTik logs, it looks like OpenSwan is proposing "0.0.0.0/0" as the phase2 subnet, but only when working as a responder ???
Try disabling the unity plugin on the advanced settings tab under VPN>IPsec, there is some circumstance with unity which kicks strongswan into changing its local to 0.0.0.0/0. If you know of a config to reliably replicate that, I'd like to know details so we have a replicable test case to help get that problem fixed upstream in strongswan.
-
@cmb:
Still, there's an issue. As per the MikroTik logs, it looks like OpenSwan is proposing "0.0.0.0/0" as the phase2 subnet, but only when working as a responder ???
Try disabling the unity plugin on the advanced settings tab under VPN>IPsec, there is some circumstance with unity which kicks strongswan into changing its local to 0.0.0.0/0. If you know of a config to reliably replicate that, I'd like to know details so we have a replicable test case to help get that problem fixed upstream in strongswan.
Seems to be (at least) partially related to what you mention, except after disabling the Cisco Unity plugin it keeps behaving in the same way (I even rebooted the box after disabling unity).
This is a site-to-site IKEv1 VPN from an Alix 2D13 towards a MikroTik RB750 running RouterOS v6.25 (latest), configured with RSA authentication, which BTW worked fine with pfSense v2.1.x and racoon.
This is on the strongswan log:
Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Jan 26 20:31:41 pfsenseurq charon: 12[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Jan 26 20:31:41 pfsenseurq charon: 12[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> proposing traffic selectors for us: Jan 26 20:31:41 pfsenseurq charon: 12[CFG] proposing traffic selectors for us: Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> 172.21.2.0/24|/0 Jan 26 20:31:41 pfsenseurq charon: 12[CFG] 172.21.2.0/24|/0 Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> proposing traffic selectors for other: Jan 26 20:31:41 pfsenseurq charon: 12[CFG] proposing traffic selectors for other: Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> 172.21.3.0/24|/0 Jan 26 20:31:41 pfsenseurq charon: 12[CFG] 172.21.3.0/24|/0 Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> changing proposed traffic selectors for us: Jan 26 20:31:41 pfsenseurq charon: 12[CFG] changing proposed traffic selectors for us: Jan 26 20:31:41 pfsenseurq charon: 12[CFG] <con2000|39> 0.0.0.0/0|/0 Jan 26 20:31:41 pfsenseurq charon: 12[CFG] 0.0.0.0/0|/0</con2000|39></con2000|39></con2000|39></con2000|39></con2000|39></con2000|39></con2000|39></con2000|39>This is what gets logged on the MikroTik device:
no policy found: 0.0.0.0/0[0] 172.21.3.0/24[0] proto=any dir=in failed to get proposal for responder. failed to pre-process ph2 packet.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 cisco_unity = no interfaces_use = vr2,vr0 # 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 { } }Relevant part of ipsec.conf
conn con2000 reqid = 4 fragmentation = yes keyexchange = ikev1 reauth = yes forceencaps = no rekey = yes installpolicy = yes type = tunnel dpdaction = restart dpddelay = 10s dpdtimeout = 60s auto = route left = xxx.xxx.xxx.xxx right = yyy.yyy.yyy.yyy leftid = ikelifetime = 28800s lifetime = 3600s ike = aes128-sha1-modp1024! esp = aes128-sha1,aes128-sha1! leftauth = pubkey rightauth = pubkey leftcert=/var/etc/ipsec/ipsec.d/certs/cert-2.crt rightid = <<certificate cn="" between="" quotes="">> aggressive = no rightsubnet = 172.21.3.0/24 leftsubnet = 172.21.2.0/24</certificate>This is only happening when strongswan works as a responder.
On the MikroTik documentation, it says the following:
@http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Mode_Config:
Note: If RouterOS client is initiator, it will always send CISCO UNITY extension, and RouterOS supports only split-include from this extension.
Any clues?? I couldn't find further information on how to stop this behavior from strongswan.
If you need more info, please let me know.
Best regards!
-
Ok, although the option is checked on the GUI, unity does not seem to be disabled:
[2.2-RELEASE][root@xxx]/root: ipsec statusall Status of IKE charon daemon (strongSwan 5.2.1, FreeBSD 10.1-RELEASE-p4, i386): uptime: 49 seconds, since Jan 26 22:00:58 2015 worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 8 loaded plugins: charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf gmp xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke smp updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock unityDoes the "cisco_unity" option in strongswan.conf completely disable the plugin, or is it just a configuration option that makes it not send the flags when initiating a connection? Can it be disabled in other way besides at configure time??
Cheers!
-
Alright, I modified /etc/inc/vpn.inc so the generated strongswan.conf gets an explicit list of plugins to load:
# Automatically generated config file - DO NOT MODIFY. Changes will be overwritten. starter { load_warning = no } charon { load = charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf gmp xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke smp updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock # 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} {$accept_unencrypted} # cisco_unity = {$unity_enabled} {$ifacesuse} # 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 } } EOD;I got that list from the regular list of loaded plugins from "ipsec statusall" but removed unity from it. Once unity is not loaded, the phase2 settings are not automatically changed anymore and everything works fine.
I am not sure if this is the proper way to handle it, but I seriously needed this to work right away. Feedback is appreciated.
Conclusions from all these:
- The unity plugin is the culprit (probably worth reporting and/or fixing upstream)
- pfSense is not properly disabling the unity plugin
Best regards!!
-
It does set "cisco_unity = no" in strongswan.conf when you disable it, which should be adequate, but sounds like that's not enough to fix that problem.
Hopefully with your Mikrotik config there I'll be able to replicate it now. Added note to the still-open bug on this.
https://redmine.pfsense.org/issues/4178 -
Can you also please do a test by choosing another modp than 1024 on both phase1 and phase2?
-
Hi,
I am also having same issue, only the 1st entry of the P2 connected and rest dont work
the Tunnels are between 2 PFboxes,
at first i thought it was because tunnel from 2.1.5 were not compatible with 2.2 and created new ones
tried the following
- changed IKE to all three modes V1, V2 and Auto,
- disabled Unity option in advanced menu
- Changed PFS to off and other options
both boxes are upgraded to 2.2 release.
Regards
Abid -
@hongkonger: that is not the same issue
@ermal: I tried the following combinations of ph1 / ph2 and all of them behave in the same way when the unity plugin is loaded, as described before:
modp1024 / none
modp768 / none
modp768 / modp768
modp2048 / none
modp2048 / modp2048
modp1536 / modp768
modp768 / modp1536 -
Do all tunnels have the same subnets specified on phase2?
-
I forgot to mention that I tested with only one phase1 and one phase2 on both sides.
Best regards
-
Sorry to warm up this topic.
Is there any news on this? I've updated to 2.2.1 last week and am facing the same issues. Switch Mikrotik to passive helped but it is not realy a good solution for me (Mikrotik should be Initiator in my case).
-
The unity bug that was the source of OP's issue was fixed/worked around in 2.2.1. If you check the "disable unity" checkbox on the advanced tab, it'll prevent that from being an issue.
Is there any news on this? I've updated to 2.2.1 last week and am facing the same issues. Switch Mikrotik to passive helped but it is not realy a good solution for me (Mikrotik should be Initiator in my case).
That definitely sounds the same as OP's issue, disable unity.
-
This post is deleted!