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



  • Should have been fixed in newer snapshots.



  • Did not work with snapshot of Aug, 13 but works with one from Aug, 16 now – great!  :)



  • I am seeing this same problem now, since the change from strongswan 5.1.3 to 5.2.0.  Currently using snapshot 6-Sep-14.  Was working previously.



  • I can confirm that this can be fixed by manually adding the appropriate line into /var/etc/ipsec/ipsec.conf.  In my case:

    rightsourceip = 192.168.3.0/24
    

    and then manually restarting:

    ipsec restart
    

    Of course ipsec.conf is overwritten if restarted from the gui.  Seems the 'rightsourceip' line was added to the 'xauth_psk_server' case but not the 'pre_shared_key' case (in /etc/inc/vpn.inc)



  • Check newer snapshots i pushed fix.



  • @ermal:

    Check newer snapshots i pushed fix.

    Thanks, that allows the tunnel to be set up.

    But I still have problems: phase 1 and phase 2 are both setup, tunnel is established, but I cannot pass any traffic.  This setup (psk, roadwarrior, using shrewsoft client) was working before the change from strongswan 5.1.3 to 5.2.0.  Adding 'rightsourceip' allows the tunnel to be established, but no traffic can pass.

    I'll take a look through the 5.2.0 change log, but in the mean time, any debugging suggestions would be appreciated.



  • Its easy setkey -PD setkey -D

    and ipsec logs.



  • This may well be a configuration error on my part, but still, it was working earlier.  I don't see any errors on either the client or pfSense side, just no traffic.  This capture is with pfSense "Built On: Thu Sep 11 09:25:40 CDT 2014"

    Here
    xx.yy.zz.132 is the WAN connection on the pfSense box,
    aaa.bbb.ccc.137 is the WAN connection of the client,
    192.168.2.0/24 is the LAN behind pfSense,
    192.168.3.1 is the virtual IP assigned to the client.  Client is on a NAT'd LAN network 10.5.60.0/24

    setkey -D and setkey -PD output (note that 'lastused' time never changes from creation time):

    xx.yy.zz.132 aaa.bbb.ccc.137 
    	esp mode=tunnel spi=1572953404(0x5dc15d3c) reqid=1(0x00000001)
    	E: rijndael-cbc  50725a75 f02eb788 f888fb98 da4872b6 c16c47c5 8f87ae3b 4b184b01 cd6c1c99
    	A: hmac-sha1  c9cc9950 a4d5c037 825fe8ef 4927e83e bb8390c2
    	seq=0x00000000 replay=32 flags=0x00000000 state=mature 
    	created: Sep 11 12:02:46 2014	current: Sep 11 12:03:49 2014
    	diff: 63(s)	hard: 3600(s)	soft: 2674(s)
    	last:                     	hard: 0(s)	soft: 0(s)
    	current: 0(bytes)	hard: 0(bytes)	soft: 0(bytes)
    	allocated: 0	hard: 0	soft: 0
    	sadb_seq=1 pid=8606 refcnt=1
    aaa.bbb.ccc.137 xx.yy.zz.132 
    	esp mode=any spi=3482626703(0xcf94aa8f) reqid=1(0x00000001)
    	E: rijndael-cbc  dd784cd1 86593380 9fddc58a 5d4179b5 0080d03d 43a46c1d b8879113 110cf70e
    	A: hmac-sha1  519fb0a9 f4bcac6f 8318e207 072fe9cc 845d4620
    	seq=0x00000000 replay=32 flags=0x00000000 state=mature 
    	created: Sep 11 12:02:46 2014	current: Sep 11 12:03:49 2014
    	diff: 63(s)	hard: 3600(s)	soft: 2546(s)
    	last:                     	hard: 0(s)	soft: 0(s)
    	current: 0(bytes)	hard: 0(bytes)	soft: 0(bytes)
    	allocated: 0	hard: 0	soft: 0
    	sadb_seq=0 pid=8606 refcnt=1
    
    192.168.3.1[any] 192.168.2.0/24[any] any
    	in ipsec
    	esp/tunnel/aaa.bbb.ccc.137-xx.yy.zz.132/unique:1
    	created: Sep 11 12:02:46 2014  lastused: Sep 11 12:02:46 2014
    	lifetime: 9223372036854775807(s) validtime: 0(s)
    	spid=4 seq=1 pid=32577
    	refcnt=1
    192.168.2.0/24[any] 192.168.3.1[any] any
    	out ipsec
    	esp/tunnel/xx.yy.zz.132-aaa.bbb.ccc.137/unique:1
    	created: Sep 11 12:02:46 2014  lastused: Sep 11 12:02:46 2014
    	lifetime: 9223372036854775807(s) validtime: 0(s)
    	spid=3 seq=0 pid=32577
    	refcnt=1
    

    And the condensed ipsec.log.  This log is from boot, set up shrewsoft link, 5 failed pings from the client, and tear down of the connection.  I have the corresponding logs on the client side as well.

    Sep 11 12:02:46 pfsense charon: 12[NET] received packet: from aaa.bbb.ccc.137[500] to xx.yy.zz.132[500] (484 bytes)
    Sep 11 12:02:46 pfsense charon: 12[ENC] parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V V V V V ]
    Sep 11 12:02:46 pfsense charon: 12[IKE] <1> received draft-ietf-ipsec-nat-t-ike-00 vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
    Sep 11 12:02:46 pfsense charon: 12[ENC] received unknown vendor ID: 16:f6:ca:16:e4:a4:06:6d:83:82:1a:0f:0a:ea:a8:62
    Sep 11 12:02:46 pfsense charon: 12[IKE] <1> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] <1> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] <1> received NAT-T (RFC 3947) vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] received NAT-T (RFC 3947) vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] <1> received FRAGMENTATION vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] received FRAGMENTATION vendor ID
    Sep 11 12:02:46 pfsense charon: 12[ENC] received unknown vendor ID: f1:4b:94:b7:bf:f1:fe:f0:27:73:b8:c4:9f:ed:ed:26
    Sep 11 12:02:46 pfsense charon: 12[ENC] received unknown vendor ID: 16:6f:93:2d:55:eb:64:d8:e4:df:4f:d3:7e:23:13:f0:d0:fd:84:51
    Sep 11 12:02:46 pfsense charon: 12[ENC] received unknown vendor ID: 84:04:ad:f9:cd:a0:57:60:b2:ca:29:2e:4b:ff:53:7b
    Sep 11 12:02:46 pfsense charon: 12[IKE] <1> received Cisco Unity vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] received Cisco Unity vendor ID
    Sep 11 12:02:46 pfsense charon: 12[IKE] <1> aaa.bbb.ccc.137 is initiating a Aggressive Mode IKE_SA
    Sep 11 12:02:46 pfsense charon: 12[IKE] aaa.bbb.ccc.137 is initiating a Aggressive Mode IKE_SA
    Sep 11 12:02:46 pfsense charon: 12[CFG] looking for pre-shared key peer configs matching xx.yy.zz.132...aaa.bbb.ccc.137[vpnusers@home.com]
    Sep 11 12:02:46 pfsense charon: 12[CFG] selected peer config "con1"
    Sep 11 12:02:46 pfsense charon: 12[ENC] generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V V ]
    Sep 11 12:02:46 pfsense charon: 12[NET] sending packet: from xx.yy.zz.132[500] to aaa.bbb.ccc.137[500] (492 bytes)
    Sep 11 12:02:46 pfsense charon: 12[NET] received packet: from aaa.bbb.ccc.137[4500] to xx.yy.zz.132[4500] (140 bytes)
    Sep 11 12:02:46 pfsense charon: 12[ENC] parsed AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
    Sep 11 12:02:46 pfsense charon: 12[IKE] <con1|1>IKE_SA con1[1] established between xx.yy.zz.132[vpnusers@home.com]...aaa.bbb.ccc.137[vpnusers@home.com]
    Sep 11 12:02:46 pfsense charon: 12[IKE] IKE_SA con1[1] established between xx.yy.zz.132[vpnusers@home.com]...aaa.bbb.ccc.137[vpnusers@home.com]
    Sep 11 12:02:46 pfsense charon: 12[IKE] <con1|1>scheduling reauthentication in 85824s
    Sep 11 12:02:46 pfsense charon: 12[IKE] scheduling reauthentication in 85824s
    Sep 11 12:02:46 pfsense charon: 12[IKE] <con1|1>maximum IKE_SA lifetime 86364s
    Sep 11 12:02:46 pfsense charon: 12[IKE] maximum IKE_SA lifetime 86364s
    Sep 11 12:02:46 pfsense charon: 12[IKE] <con1|1>local host is behind NAT, sending keep alives
    Sep 11 12:02:46 pfsense charon: 12[IKE] local host is behind NAT, sending keep alives
    Sep 11 12:02:46 pfsense charon: 12[IKE] <con1|1>remote host is behind NAT
    Sep 11 12:02:46 pfsense charon: 12[IKE] remote host is behind NAT
    Sep 11 12:02:46 pfsense charon: 14[NET] received packet: from aaa.bbb.ccc.137[4500] to xx.yy.zz.132[4500] (92 bytes)
    Sep 11 12:02:46 pfsense charon: 14[ENC] parsed INFORMATIONAL_V1 request 588915076 [ HASH N(INITIAL_CONTACT) ]
    Sep 11 12:02:46 pfsense charon: 14[NET] received packet: from aaa.bbb.ccc.137[4500] to xx.yy.zz.132[4500] (156 bytes)
    Sep 11 12:02:46 pfsense charon: 14[ENC] parsed TRANSACTION request 3720127689 [ HASH CPRQ(ADDR EXP MASK U_BANNER U_NATTPORT VER U_FWTYPE) ]
    Sep 11 12:02:46 pfsense charon: 14[IKE] <con1|1>peer requested virtual IP %any
    Sep 11 12:02:46 pfsense charon: 14[IKE] peer requested virtual IP %any
    Sep 11 12:02:46 pfsense charon: 14[CFG] assigning new lease to 'vpnusers@home.com'
    Sep 11 12:02:46 pfsense charon: 14[IKE] <con1|1>assigning virtual IP 192.168.3.1 to peer 'vpnusers@home.com'
    Sep 11 12:02:46 pfsense charon: 14[IKE] assigning virtual IP 192.168.3.1 to peer 'vpnusers@home.com'
    Sep 11 12:02:46 pfsense charon: 14[ENC] generating TRANSACTION response 3720127689 [ HASH CPRP(ADDR SUBNET DNS U_SPLITINC U_BANNER) ]
    Sep 11 12:02:46 pfsense charon: 14[NET] sending packet: from xx.yy.zz.132[4500] to aaa.bbb.ccc.137[4500] (156 bytes)
    Sep 11 12:02:46 pfsense charon: 14[NET] received packet: from aaa.bbb.ccc.137[4500] to xx.yy.zz.132[4500] (172 bytes)
    Sep 11 12:02:46 pfsense charon: 14[ENC] parsed QUICK_MODE request 3113463846 [ HASH SA No ID ID ]
    Sep 11 12:02:46 pfsense charon: 14[IKE] <con1|1>received 28800s lifetime, configured 3600s
    Sep 11 12:02:46 pfsense charon: 14[IKE] received 28800s lifetime, configured 3600s
    Sep 11 12:02:46 pfsense charon: 14[ENC] generating QUICK_MODE response 3113463846 [ HASH SA No ID ID ]
    Sep 11 12:02:46 pfsense charon: 14[NET] sending packet: from xx.yy.zz.132[4500] to aaa.bbb.ccc.137[4500] (188 bytes)
    Sep 11 12:02:46 pfsense charon: 14[NET] received packet: from aaa.bbb.ccc.137[4500] to xx.yy.zz.132[4500] (76 bytes)
    Sep 11 12:02:46 pfsense charon: 14[ENC] parsed QUICK_MODE request 3113463846 [ HASH ]
    Sep 11 12:02:46 pfsense charon: 14[IKE] <con1|1>CHILD_SA con1{1} established with SPIs cf94aa8f_i 5dc15d3c_o and TS 192.168.2.0/24|/0 === 192.168.3.1/32|/0 
    Sep 11 12:02:46 pfsense charon: 14[IKE] CHILD_SA con1{1} established with SPIs cf94aa8f_i 5dc15d3c_o and TS 192.168.2.0/24|/0 === 192.168.3.1/32|/0 
    Sep 11 12:03:10 pfsense charon: 14[IKE] <con1|1>sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:03:10 pfsense charon: 14[IKE] sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:03:30 pfsense charon: 14[IKE] <con1|1>sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:03:30 pfsense charon: 14[IKE] sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:03:50 pfsense charon: 14[IKE] <con1|1>sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:07:10 pfsense charon: 14[IKE] sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:07:30 pfsense charon: 14[IKE] <con1|1>sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:07:30 pfsense charon: 14[IKE] sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:07:50 pfsense charon: 14[IKE] <con1|1>sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:07:50 pfsense charon: 14[IKE] sending keep alive to aaa.bbb.ccc.137[4500]
    Sep 11 12:07:50 pfsense charon: 14[NET] received packet: from aaa.bbb.ccc.137[4500] to xx.yy.zz.132[4500] (92 bytes)
    Sep 11 12:07:50 pfsense charon: 14[ENC] parsed INFORMATIONAL_V1 request 4150358938 [ HASH D ]
    Sep 11 12:07:50 pfsense charon: 14[IKE] <con1|1>received DELETE for ESP CHILD_SA with SPI 5dc15d3c
    Sep 11 12:07:50 pfsense charon: 14[IKE] received DELETE for ESP CHILD_SA with SPI 5dc15d3c
    Sep 11 12:07:50 pfsense charon: 14[IKE] <con1|1>closing CHILD_SA con1{1} with SPIs cf94aa8f_i (0 bytes) 5dc15d3c_o (0 bytes) and TS 192.168.2.0/24|/0 === 192.168.3.1/32|/0 
    Sep 11 12:07:50 pfsense charon: 14[IKE] closing CHILD_SA con1{1} with SPIs cf94aa8f_i (0 bytes) 5dc15d3c_o (0 bytes) and TS 192.168.2.0/24|/0 === 192.168.3.1/32|/0 
    Sep 11 12:07:50 pfsense charon: 08[NET] received packet: from aaa.bbb.ccc.137[4500] to xx.yy.zz.132[4500] (92 bytes)
    Sep 11 12:07:50 pfsense charon: 08[ENC] parsed INFORMATIONAL_V1 request 2594436540 [ HASH D ]
    Sep 11 12:07:50 pfsense charon: 08[IKE] <con1|1>received DELETE for IKE_SA con1[1]
    Sep 11 12:07:50 pfsense charon: 08[IKE] received DELETE for IKE_SA con1[1]
    Sep 11 12:07:50 pfsense charon: 08[IKE] <con1|1>deleting IKE_SA con1[1] between xx.yy.zz.132[vpnusers@home.com]...aaa.bbb.ccc.137[vpnusers@home.com]
    Sep 11 12:07:50 pfsense charon: 08[IKE] deleting IKE_SA con1[1] between xx.yy.zz.132[vpnusers@home.com]...aaa.bbb.ccc.137[vpnusers@home.com]
    Sep 11 12:07:50 pfsense charon: 08[CFG] lease 192.168.3.1 by 'vpnusers@home.com' went offline</con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1></con1|1> 
    


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

    Are you sourcing your ping correctly?



  • @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.



  • Which snapshot are you on?

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



  • 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.



  • 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):
    
    


  • Can you share your configs?

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



  • @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.
    
    


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



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



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



  • @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.



  • 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.





  • @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!


Log in to reply