IPsec mobile client problems: no virtual IP found for %any …

eri--

I have tested this all day today and it works correctly.

Are you sourcing your ping correctly?

charliem

@ermal:

Are you sourcing your ping correctly?

I believe so; the routing table on the client is correct. It's failed with two different client machines on two different external networks.

Hmm, unrelated, but I just tried to refresh diap_ipsec.php after bringing up the tunnel, and noticed it hanging. php-fpm is cpu-bound at 100%, and I see this in the logs:

Sep 11 17:31:54 pfsense charon: 02[IKE] assigning virtual IP 192.168.3.1 to peer 'vpnusers@home.com'
Sep 11 17:31:54 pfsense charon: 02[ENC] generating TRANSACTION response 1975182865 [ HASH CPRP(ADDR SUBNET DNS U_SPLITINC U_BANNER) ]
Sep 11 17:31:54 pfsense charon: 02[NET] sending packet: from xx.yy.zz.132[4500] to aaa.bbb.ccc.137[4500] (156 bytes)
Sep 11 17:32:00 pfsense charon: 02[DMN] thread 2 received 10
Sep 11 17:32:00 pfsense charon: 02[LIB]  dumping 2 stack frame addresses:
Sep 11 17:32:00 pfsense charon: 02[LIB]   /lib/libthr.so.3 @ 0x801340000 (_swapcontext+0x15b) [0x80134e4ab]
Sep 11 17:32:00 pfsense charon: 02[LIB]     ->
Sep 11 17:32:00 pfsense charon: 02[LIB]   /lib/libthr.so.3 @ 0x801340000 (sigaction+0x343) [0x80134e093]
Sep 11 17:32:00 pfsense charon: 02[LIB]     ->
Sep 11 17:32:00 pfsense charon: 02[DMN] killing ourself, received critical signal
Sep 11 17:32:07 pfsense charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.2.0, FreeBSD 10.1-PRERELEASE, amd64)

This hasn't happened before.

eri--

Which snapshot are you on?

Please update to the latest one.
That was due to makeing the status page include necessary information.

charliem

This was "Built On: Thu Sep 11 09:25:40 CDT 2014"

I will wait for the next snapshot with your latest changes to appear, and re-test, thanks.

charliem

On version "built on Thu Sep 11 19:41:05 CDT 2014"

Good news is I can't reproduce the hang in php-fpm.

Bad news is now no SAD or SPD entries are created, but a lease does show up in the pool. Still no traffic though.

Further bad news is that setting any loglevels to '-1' is not possible any more. This triggers corresponding entries in syslog:

Sep 12 07:59:35 pfsense php-fpm[27936]: /vpn_ipsec_settings.php: The command '/usr/local/sbin/ipsec stroke loglevel tls -1' returned exit code '255', the output was 'stroke: invalid option -- 1 stroke [OPTIONS] command [ARGUMENTS]  Options:   -h, --help             print this information.   -d, --daemon=NAME      name of the daemon. Commands:   Add a connection:     stroke add NAME MY_ID OTHER_ID MY_ADDR OTHER_ADDR\            MY_NET OTHER_NET     where: ID is any IKEv2 ID            ADDR is a IPv4 address            NET is a IPv4 subnet in CIDR notation   Delete a connection:     stroke delete NAME     where: NAME is a connection name added with "stroke add"   Initiate a connection:     stroke up NAME     where: NAME is a connection name added with "stroke add"   Initiate a connection without blocking:     stroke up-nb NAME     where: NAME is a connection name added with "stroke add"   Terminate a connection:     stroke down NAME     where: NAME is a connection name added with "stroke add"   Terminate a connecti

And it fails interactively as well. Note the usage text still shows it as a valid command:

[2.2-ALPHA][root@pfsense.localdomain]/var/log(17): /usr/local/sbin/ipsec stroke loglevel imc -1
stroke: invalid option -- 1

< lots of usage info deleted here >

Error: invalid option
[2.2-ALPHA][root@pfsense.localdomain]/var/log(18):

eri--

Can you share your configs?

I will check the loglevel thing.
Though it will have been there even before but it was not noticed!

charliem

@ermal:

Can you share your configs?

Sure, thanks for looking! First ipsec.conf, then strongswan.conf and last ipsec listall output (with tunnel up, client appears OK and gets the login banner).

[2.2-ALPHA][root@pfsense.localdomain]/var/etc/ipsec(37): cat ipsec.conf
# This file is automatically generated. Do not edit
config setup
        uniqueids = yes
        charondebug="dmn = 1,mgr = 0,ike = 0,chd = 0,job = 0,cfg = 0,knl = 0,net = 1,enc = 0,app = 0,esp = 1,lib = 1"

conn con1
        aggressive = yes
        fragmentation = yes
        keyexchange = ikev1
        reauth = yes
        rekey = yes
        reqid = 1
        installpolicy = yes
        type = tunnel
        dpdaction = none
        auto = add
        left = xx.yy.zz.132
        right = %any
        leftid = vpnusers@home.com
        ikelifetime = 86400s
        lifetime = 3600s
        rightsourceip = 192.168.3.0/24
        rightsubnet = 192.168.3.0/24
        leftsubnet = 192.168.2.0/24
        ike = aes256-sha256-modp1024!
        esp = aes256-md5,aes256-sha1,aes256-sha256,blowfish256-md5,blowfish256-sha1,blowfish256-sha256,blowfish192-md5,blowfish192-sha1,blowfish192-sha256,blowfish128-md5,blowfish128-sha1,blowfish128-sha256,3des-md5,3des-sha1,3des-sha256!
        leftauth = psk
        rightauth = psk

[2.2-ALPHA][root@pfsense.localdomain]/var/etc/ipsec(38): cat strongswan.conf

#Automatically generated please do not modify
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;

        # XXX: There is not much choice here really users win their security!
        i_dont_care_about_security_and_use_aggressive_mode_psk=yes

        # 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
                }
        }
        cisco_unity = yes
        plugins {
                attr {
                subnet = 192.168.3.0/24
                dns = 8.8.8.8
                split-include = 192.168.2.0/24
                28672 = Welcome to Test .. Authorized use only!
                }
        xauth-generic {
                script = /etc/inc/ipsec.auth-user.php
                authcfg = Local Database
        }
        }
}

[2.2-ALPHA][root@pfsense.localdomain]/var/etc/ipsec(41): ipsec statusall
Status of IKE charon daemon (weakSwan 5.2.0, FreeBSD 10.1-PRERELEASE, amd64):
  uptime: 11 hours, since Sep 11 22:56:08 2014
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 11
  loaded plugins: charon curl 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 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-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock
Virtual IP pools (size/online/offline):
  192.168.3.0/24: 254/1/0
Listening IP addresses:
  192.168.2.128
  xx.yy.zz.132
  192.168.100.5
Connections:
        con1:  xx.yy.zz.132...%any  IKEv1 Aggressive
        con1:   local:  [vpnusers@home.com] uses pre-shared key authentication
        con1:   remote: uses pre-shared key authentication
        con1:   child:  192.168.2.0/24|/0 === 192.168.3.0/24|/0 TUNNEL
Security Associations (1 up, 0 connecting):
        con1[5]: ESTABLISHED 24 seconds ago, xx.yy.zz.132[vpnusers@home.com]...aaa.bbb.ccc.137[vpnusers@home.com]
        con1[5]: IKEv1 SPIs: 0076e8adb5b55a1e_i 4fe2ea1d13eec388_r*, pre-shared key reauthentication in 23 hours
        con1[5]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
[2.2-ALPHA][root@pfsense.localdomain]/var/etc/ipsec(42): setkey -D
No SAD entries.
[2.2-ALPHA][root@pfsense.localdomain]/var/etc/ipsec(43): setkey -PD
No SPD entries.

eri--

You should have some warnings on your ipsec log.
Why the policies have not been created!

charliem

No obvious errors in the log that I can see, they look just like what I posted yesterday.

eri--

Well try using a different subnet for the rightsourceip rather than peer ip address.

charliem

@ermal:

Well try using a different subnet for the rightsourceip rather than peer ip address.

SAD and SPD entries can be created if I comment out 'rightsubnet=192.168.3.0/24' from ipsec.conf (not sure that's possible with the current webgui code). But I still cannot pass any traffic through the tunnel.

I will start from scratch and take a close look over the weekend, thanks.

charliem

This strongswan bug https://wiki.strongswan.org/issues/586 was properly rejected because it was not a strongswan issue, but rather a FreeBSD 10.0 issue.

Symptoms seem to match what I'm seeing … Was or is this a valid bug? I can't immediately find a similar patchset in FreeBSD sources, but I can't believe a bug like this would still be around.

hege

FYI:

i have the same issue.
https://forum.pfsense.org/index.php?topic=81657.msg446613#msg446613

eri--

@charliem:

This strongswan bug https://wiki.strongswan.org/issues/586 was properly rejected because it was not a strongswan issue, but rather a FreeBSD 10.0 issue.

Symptoms seem to match what I'm seeing … Was or is this a valid bug? I can't immediately find a similar patchset in FreeBSD sources, but I can't believe a bug like this would still be around.

The fix is already present in FreeBSD 10 afaik.
So that patch is already merged!