OPNsense Forum
English Forums => General Discussion => Topic started by: TheLatestWire on March 23, 2016, 02:53:15 pm
-
Hi - For the last few days I've been unable to fetch updates. I get "Connection Error". I'm wondering if I've inadvertently blocked the update mirror or if it's perhaps down.
I noticed this in the log file but I'm not sure what to make of it.
Mar 23 08:43:47 OPNsense configd.py: [43fa4099-7ea5-4ebf-992c-a7000f60502c] retrieve package status
Mar 23 08:46:55 OPNsense lighttpd[49412]: (connections.c.1550) SSL: 1 -1 error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
Any assistance would be greatly appreciated.
Thank you.
-
Which version is this? Restart configd from Services: Diagnostics and try again.
-
Versions:
OPNsense 16.1.7-amd64
FreeBSD 10.2-RELEASE-p13
OpenSSL 1.0.2g 1 Mar 2016
I restarted configd and then tried again but the same thing happened:
Connection Error
Click to retry
Thanks.
-
Maybe DNS is not set up correctly... can you run console option 12 for me?
-
Is this a static WAN configuration?
Edit: Sorry, I misread the previous. So DNS works, but that would mean a proxy or port setting somewhere else makes this fail.
-
No, it's actually getting it's IP (172.16.1.36) from DHCP and is behind the DSL firewall that my ISP provided me with. I have the OPNSense box's WAN interfaced DMZ'd.
Internet-->ISP-ADLS-Firewall(172.16.1.0/24)-->OPNSense-WAN-DMZ'd-->Private-LAN(192.168.1.0/24)
Would it help if I didn't use DHCP on it? I have been able to fetch updates in the past and it seems to have just recently stopped.
-
I think I found something that might be an issue. I was looking through the logs and found this:
Mar 23 13:42:42 opnsense: /usr/local/etc/rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan).
It just doesn't make sense to me that I could still have internet access from behind the OPNsense box (and even ping from it) if there was really no IPV4 gateway for interface (wan).
-
I tried switching the WAN interface to a static IP address and static gateway and deleted the old gateway but that didn't help.
Also unchecked "Block private networks" on the WAN device but it didn't help.
Also restarted configd and apinger, but that didn't help.
The log no longer says "Could not find IPv4 gateway for interface (wan)." but now shows "configd.py: [xxx-xxx] retrieve package status" and the fetch update fails with "Connection Error".
For what it's worth, pkg update from the shell also doesn't work. I'm guessing that I shot myself in the foot with a firewall rule that is blocking pkg.opnsense.org?
# sudo pkg -d update
DBG(1)[51806]> pkg initialized
Updating OPNsense repository catalogue...
DBG(1)[51806]> PkgRepo: verifying update for OPNsense
DBG(1)[51806]> Pkgrepo, begin update of '/var/db/pkg/repo-OPNsense.sqlite'
DBG(1)[51806]> Fetch: fetching from: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/meta.txz with opts "i"
DBG(1)[51806]> Fetch: fetching from: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/meta.txz with opts "i"
DBG(1)[51806]> Fetch: fetching from: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/meta.txz with opts "i"
pkg: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/meta.txz: Operation timed out
repository OPNsense has no meta file, using default settings
DBG(1)[51806]> Fetch: fetching from: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/packagesite.txz with opts "i"
DBG(1)[51806]> Fetch: fetching from: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/packagesite.txz with opts "i"
DBG(1)[51806]> Fetch: fetching from: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/packagesite.txz with opts "i"
pkg: http://pkg.opnsense.org/FreeBSD:10:amd64/16.1/latest/packagesite.txz: Operation timed out
Unable to update repository OPNsense
I can ping it but I can't trace route to it.
# ping pkg.opnsense.org
PING pkg.opnsense.org (37.48.77.141): 56 data bytes
64 bytes from 37.48.77.141: icmp_seq=0 ttl=50 time=121.960 ms
64 bytes from 37.48.77.141: icmp_seq=1 ttl=50 time=121.236 ms
--- pkg.opnsense.org ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 121.236/121.598/121.960/0.362 ms
# traceroute pkg.opnsense.org
traceroute to pkg.opnsense.org (37.48.77.141), 64 hops max, 40 byte packets
1 172.16.0.1 (172.16.0.1) 1.371 ms 2.823 ms 1.167 ms
2 * * *
3 * * *
4 12.83.79.169 (12.83.79.169) 24.207 ms 24.930 ms 23.445 ms
5 gar13.cgcil.ip.att.net (12.122.132.121) 26.812 ms 27.284 ms 27.977 ms
6 chi-b21-link.telia.net (213.248.87.253) 25.707 ms 25.055 ms 26.035 ms
7 nyk-bb1-link.telia.net (80.91.246.163) 62.409 ms
nyk-bb2-link.telia.net (62.115.116.36) 61.679 ms
nyk-bb1-link.telia.net (62.115.137.30) 61.800 ms
8 * ldn-bb2-link.telia.net (80.91.248.253) 122.116 ms
ldn-bb3-link.telia.net (213.155.133.148) 121.204 ms
9 adm-bb3-link.telia.net (62.115.143.191) 131.551 ms
adm-bb4-link.telia.net (62.115.142.227) 125.943 ms
adm-bb4-link.telia.net (213.155.136.79) 127.700 ms
10 adm-b3-link.telia.net (213.155.136.241) 130.459 ms
adm-b3-link.telia.net (213.155.136.243) 129.427 ms
adm-b3-link.telia.net (62.115.137.151) 128.186 ms
11 leaseweb-ic-307467-adm-b3.c.telia.net (62.115.47.58) 127.121 ms
leaseweb-ic-307468-adm-b3.c.telia.net (62.115.47.62) 137.996 ms
leaseweb-ic-307466-adm-b3.c.telia.net (62.115.47.54) 132.865 ms
12 * * *
13 po1002.ngn-ams1-cs2-new.leaseweb.net (37.48.95.195) 132.442 ms
po1003.ngn-ams1-cs2-new.leaseweb.net (37.48.95.201) 127.365 ms
po1002.ngn-ams1-cs1-new.leaseweb.net (37.48.95.193) 154.472 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
-
Can you try switching to a different mirror to see if that helps? System: Settings: General: Firmware Mirror
This looks like a configuration type of problem. Is there a a default route now? Errors like that may be temporary depending on transition or bootup state, sometimes DHCP servers can take a bit of time to answer.
-
There is a default route listed in "System/Routes/Status". The first and default destination is the now static IP on the WAN interface.
I tried a number of different mirrors and had the same issue with all of them.
It might be worth mentioning that this is on VMWare ESXi 5.5 server and I'm using the VMXNET3 driver for both the LAN and WAN network adapters.
I thought maybe it was a config issue on my OPNsense server, so I created a brand new side by side VM. After setting it up, the first thing I did was to check for updates. It succeeded and said there was one update available, but I didn't install it. I then enabled "Intrusion Detection" and " IPS mode" and clicked "Download and Update Rules". Right after that I went back to the Dashboard on this fresh OPNSense install and clicked "Check for Updates", and it failed with "Connection Error"! This, only a few minutes after it had initially succeeded. The only things I did were to enable "Intrusion Detection" and "IPS Mode".
On the new/fresh install I unchecked "IPS Mode", hit Apply and then went back to the Dashboard and hit "Check for Updates" and it succeeded and said there was one update available. I still didn't install it yet though. I was able to reproduce this behavior a few times by toggling the "IPS Mode" on and off. This server's versions are OPNsense 16.1-amd64, FreeBSD 10.2-RELEASE-p11 and OpenSSL 1.0.2e 3 Dec 2015.
I was encouraged by this so I tried disabling "IPS Mode" on my original OPNsense server, hit Apply and then "Check for Updates" in the Dashboard, and it worked! :) This server's versions are OPNsense 16.1.7-amd64, FreeBSD 10.2-RELEASE-p13 and OpenSSL 1.0.2g 1 Mar 2016.
I took a look at the description for "IPS Mode" and noted the warning about disabling all hardware offloading first, so I disabled all the hardware offloading in "Advanced Network" and tried again but it didn't help. "Check for updates" fails when "IPS Mode" is enabled, even with all the hardware offloading disabled.
Sorry if I shouldn't have ever enabled "IPS Mode". I might have just been click happy and enabled it when I enabled "Intrusion Detection", thinking it was something that I would benefit from, but quite honestly I'm not even sure I know what it is.
So to sum it all up, unchecking "IPS Mode" in "Services/Intrusion Detection" allowed me to successfully "Check for updates" in the Dashboard.
Thanks.
-
Ah, glad you caught this! It was giving me a headache. I shall prepare a standard set of questions for support, this IPS mode and also some VM types give us the checksum blues a lot. :(
-
I have the same issue and IPS mode is disabled.
My current version:
OPNsense 16.1.8-amd64
FreeBSD 10.2-RELEASE-p14
OpenSSL 1.0.2g 1 Mar 2016
-
bapetc what shows up in your logs? Did you try switching update mirrors? franco will prob want that information to see if both issues are related.
-
Do you have an idea in which log file?
root@firewall:/var/log #
-
I have reboot the firewall and the update works again.
-
Either a DNS issue or the old configd background daemon problem we had in the early 16.1.x. Glad it works now. :)