2.2.4 no updates



  • Hi all,

    TLDR;  I can intermittently use fetch to get packages.pfsense.org via command line, but web gui can never check for updates or install packages.  Firewall rules are any any for testing, even added 208.123.73.88 and 162.208.119.39 as explicit rules to allow through.  Using 2.2.4 release.

    Witnessing some pretty odd behavior with one of my pfSense instances.  This is the first time I'm running 2.2.4 and for the most part it's configured like my other working instances.

    DNS resolution is working properly.  NTP is configured and up.

    I can sometimes get fetch https://packages.pfsense.org -v to work and give me output (see below).  But the majority of the time it does not work.

    Navigating to System > Packages takes a lot of time.  When I get a successful fetch (the whole output), I immediately try to navigate to System > Packages in the GUI and then I can no longer use the command line to fetch.  It gets stuck at

    Using CA cert file: /usr/local/etc/ssl/cert.pem
    

    I get the following two errors when going to System > Packages in the Web GUI:

    
    The package server's SSL certificate could not be verified. The SSL certificate itself may be invalid, its chain of trust may have failed validation, or the server may have been impersonated. Downloaded packages may come from an untrusted source. Proceed with caution.
    
    

    And then going to the available packages tab gives me this:

    
    Unable to communicate with https://packages.pfsense.org. Please verify DNS and interface configuration, and that pfSense has functional Internet connectivity.	Close
    
    

    DNS query using drill

    
    [2.2.4-RELEASE][root@mypfsense]/root: drill packages.pfsense.org
    ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3078
    ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;; packages.pfsense.org.        IN      A
    
    ;; ANSWER SECTION:
    packages.pfsense.org.   300     IN      A       208.123.73.88
    
    ;; AUTHORITY SECTION:
    
    ;; ADDITIONAL SECTION:
    
    ;; Query time: 222 msec
    ;; SERVER: 4.2.2.2
    ;; WHEN: Mon Oct  5 00:39:42 2015
    ;; MSG SIZE  rcvd: 54
    
    

    Here is a successful fetch of https://packages.pfsense.org.

    
    [2.2.4-RELEASE][root@mypfsense]/root: fetch https://packages.pfsense.org -v
    looking up packages.pfsense.org
    connecting to packages.pfsense.org:443
    SSL options: 81004bff
    Peer verification enabled
    Using CA cert file: /usr/local/etc/ssl/cert.pem
    Verify hostname
    SSL connection established using ECDHE-RSA-AES256-GCM-SHA384
    Certificate subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.pfsense.org
    Certificate issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
    requesting https://packages.pfsense.org/
    local size / mtime: 23 / 1394690197
    remote size / mtime: 23 / 1394690197
    packages.pfsense.org                          100% of   23  B   45 kBps 00m00s
    
    

    And when it's unsuccessful it looks like this.  It just hangs.

    
    [2.2.4-RELEASE][root@mypfsense]/root: fetch https://packages.pfsense.org -v
    looking up packages.pfsense.org
    connecting to packages.pfsense.org:443
    SSL options: 81004bff
    Peer verification enabled
    Using CA cert file: /usr/local/etc/ssl/cert.pem
    ^C^C
    
    

  • Banned

    Does this file exist? /usr/local/etc/ssl/cert.pem



  • @doktornotor:

    Does this file exist? /usr/local/etc/ssl/cert.pem

    Yes, it exists.  The problem ended up being the networking+hypervisor setup.  We had LRO enabled and it was causing issues on the pfSense guest.  After disabling it ALL packets were properly hitting the pfSense guest.

    Running in to other quarks which I don't quite understand why they were designed this way.  After establishing an IPSec tunnel I'm unable to traverse over that tunnel from the shell of the pfsense box - but if I add a route (which then causes a routing loop), it does.  An example would be to setup an OpenVPN server and have it authenticate against an LDAP server - pfSense can't reach the LDAP server if it's over the IPSec tunnel.  Quick fix to that was adding a route.  Doesn't seem like the right thing to do.

    pfSense in this case is used to extend the network to a new location over an IPSec tunnel as well as act as a VPN server at that new location.


Log in to reply