1. Home
  2. pfSense® Software
  3. Retired
  4. 2.2 Snapshot Feedback and Problems - RETIRED
  5. IPSec widget broken

IPSec widget broken

  • E

    2.2-RC (i386)
    built on Mon Dec 29 17:24:57 CST 2014

    I have upgraded to the latest available RC22 build, and the IPSec widget is still broken on my system.
    Some screen shots from the widget and ipsec status are attached.

    EDIT:
    Noted the following messages in the IPSec log. Not sure if it is related:

    charon: 00[CFG] opening triplet file /var/etc/ipsec/ipsec.d/triplets.dat failed: No such file or directory
    charon: 00[LIB] unable to load 6 plugin features (5 due to unmet dependencies)






    0
  • E

    Same for me …

    2.2-RC (i386)
    built on Mon Dec 29 17:24:57 CST 2014

    Reality: 6 Tunnels definitively running and up (also shown up in IPSec status page)
    Dashboard Widget: 1 Up / 5 Down (only the first P2 child entry is up ... child 2 to n never displayed up)

    0
  • dennypage

    Broken for me as well. Always shows zero tunnels up even though tunnels show active on the IPSEC status page.

    0
  • C

    @eskild:

    EDIT:
    Noted the following messages in the IPSec log.

    that's unrelated, normal.

    What does the output of command "ipsec statusall" look like?

    0
  • dennypage

    It was pointed out in another thread that the IPSEC widget always showing zero tunnels up is likely the results of tunnels created by older versions of pfSense that do not have the IKE type explicitly set. The current version always sets the IKE type.

    For what it's worth, this fixed the issue for me. Just going into the edit page for IPSEC phase 1 configuration and re-saving it was sufficient.

    0
  • E

    @cmb:

    @eskild:

    EDIT:
    Noted the following messages in the IPSec log.

    that's unrelated, normal.

    What does the output of command "ipsec statusall" look like?

    $ ipsec statusall
    Status of IKE charon daemon (strongSwan 5.2.1, FreeBSD 10.1-RELEASE-p3, i386):
      uptime: 2 hours, since Dec 30 19:20:13 2014
      worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
      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 unity
    Listening IP addresses:
      xxx.xxx.xxx.xxx
      192.168.101.162
      192.168.123.1
      192.168.101.129
      192.168.101.1
      2001:470:abc🔤:abc
      192.168.100.1
      192.168.100.33
      192.168.101.65
      192.168.120.1
      10.100.0.1
      2001:470:zzz💤:z
      192.168.102.1
    Connections:
        con1000:  xxx.xxx.xxx.xxx…yyy.yyy.yyy.yyy  IKEv1
        con1000:  local:  [xxx.xxx.xxx.xxx] uses pre-shared key authentication
        con1000:  remote: [yyy.yyy.yyy.yyy] uses pre-shared key authentication
        con1000:  child:  0.0.0.0/0|/0 === 10.10.12.16/28|/0 TUNNEL
        con1001:  child:  0.0.0.0/0|/0 === 10.10.12.32/28|/0 TUNNEL
        con1002:  child:  192.168.101.32/27|/0 === 10.10.12.1/32|/0 TUNNEL
        con1003:  child:  192.168.101.32/27|/0 === 10.10.12.48/28|/0 TUNNEL
        con1004:  child:  192.168.101.36/32|/0 === 10.10.12.3/32|/0 TUNNEL
        con1005:  child:  192.168.101.37/32|/0 === 10.10.12.33/32|/0 TUNNEL
        con1006:  child:  192.168.101.38/32|/0 === 10.10.15.1/32|/0 TUNNEL
    Routed Connections:
        con1006{1006}:  ROUTED, TUNNEL
        con1006{1006}:  192.168.101.38/32|/0 === 10.10.15.1/32|/0
        con1005{1005}:  ROUTED, TUNNEL
        con1005{1005}:  192.168.101.37/32|/0 === 10.10.12.33/32|/0
        con1004{1004}:  ROUTED, TUNNEL
        con1004{1004}:  192.168.101.36/32|/0 === 10.10.12.3/32|/0
        con1003{1003}:  ROUTED, TUNNEL
        con1003{1003}:  192.168.101.32/27|/0 === 10.10.12.48/28|/0
        con1002{1002}:  ROUTED, TUNNEL
        con1002{1002}:  192.168.101.32/27|/0 === 10.10.12.1/32|/0
        con1001{1001}:  ROUTED, TUNNEL
        con1001{1001}:  0.0.0.0/0|/0 === 10.10.12.32/28|/0
        con1000{1000}:  ROUTED, TUNNEL
        con1000{1000}:  0.0.0.0/0|/0 === 10.10.12.16/28|/0
    Security Associations (1 up, 0 connecting):
        con1000[1]: ESTABLISHED 2 hours ago, xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]…yyy.yyy.yyy.yyy[yyy.yyy.yyy.yyy]
        con1000[1]: IKEv1 SPIs: 035338d1b668bc75_i f58f06d2025ca81e_r*, pre-shared key reauthentication in 20 hours
        con1000[1]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768
        con1000{1000}:  INSTALLED, TUNNEL, ESP SPIs: c087624b_i bf9cd7a5_o
        con1000{1000}:  3DES_CBC/HMAC_MD5_96, 44149 bytes_i (266 pkts, 10206s ago), 141472 bytes_o (291 pkts, 6214s ago), rekeying in 2 hours
        con1000{1000}:  0.0.0.0/0|/0 === 10.10.12.16/28|/0
        con1003{1003}:  INSTALLED, TUNNEL, ESP SPIs: c700efaf_i 33378587_o
        con1003{1003}:  3DES_CBC/HMAC_MD5_96, 0 bytes_i, 0 bytes_o, rekeying in 2 hours
        con1003{1003}:  192.168.101.32/27|/0 === 10.10.12.48/28|/0
        con1001{1001}:  INSTALLED, TUNNEL, ESP SPIs: c113e145_i 6f60d84b_o
        con1001{1001}:  3DES_CBC/HMAC_MD5_96, 0 bytes_i, 0 bytes_o, rekeying in 2 hours
        con1001{1001}:  0.0.0.0/0|/0 === 10.10.12.32/28|/0
        con1002{1002}:  INSTALLED, TUNNEL, ESP SPIs: cc28c9e8_i 955e5ede_o
        con1002{1002}:  3DES_CBC/HMAC_MD5_96, 1451 bytes_i (3 pkts, 10196s ago), 320 bytes_o (3 pkts, 10196s ago), rekeying in 2 hours
        con1002{1002}:  192.168.101.32/27|/0 === 10.10.12.1/32|/0

    0
  • E

    @dennypage:

    It was pointed out in another thread that the IPSEC widget always showing zero tunnels up is likely the results of tunnels created by older versions of pfSense that do not have the IKE type explicitly set. The current version always sets the IKE type.

    For what it's worth, this fixed the issue for me. Just going into the edit page for IPSEC phase 1 configuration and re-saving it was sufficient.

    Thanks!
    I read the same thread and did the same as you, re-saved the ph1 config. After that, 1 ph2 entry shows as up in the widget. The rest of the ph2 entries still displays as down.

    0
  • dennypage

    @eskild:

    I read the same thread and did the same as you, re-saved the ph1 config. After that, 1 ph2 entry shows as up in the widget. The rest of the ph2 entries still displays as down.

    Yea, I spoke a bit too soon. It didn't completely cure it for me either.

    Is it always the first tunnel tab entry that shows as up? Regardless of which tunnel is actually up?

    0
  • C

    Thanks for the feedback, that helped narrow things down to two remaining issues.

    One, for upgraded configs.
    https://redmine.pfsense.org/issues/4163
    To work around that, just edit and save each phase 1 config.

    Two, for multiple P2s.
    https://redmine.pfsense.org/issues/4164
    No workaround available there.

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

© 2020 Rubicon Communications, LLC | Privacy Policy