Messages

+1!!!

I'd recommend two three pihole nodes and you're done..

 Smooth Upgrade here as well!

Hi, I did upgrade to 20.3.1 and now we're back to normal with the synchronisation for Apple Mail. Not sure what caused the disruption but the 20.3.1 or Wireguard package upgrade resolved the issue!

Hello, I have been implementing the Wireguard client (plug-in OS-wireguard 1.1) on Opnsense 20.1.1, succeeding the OVPN client. The idea is that the users connecting with WLAN (specific IP range) connect via VPN to the internet..

All went well with the WLAN endusers enjoying more speed and uptime with wireguard on opnsense..with one exception: on the Macs / iPhones I had the issue that the iCloud email didn't connect (via IMAP to p47-imap.mail.me.com resp. SMTP to p47-smtp.mail.me.com). All the other email accounts (i.e. google, hotmail, local ones) could establish the imap, smtp connection when connecting opnsense with Wireguard.

If I revert back to use the OVPN client, the iCloud email connection issue is gone (no change to the config other than switching the interface).

I checked with the VPN provider (IVPN) but they are not aware of any issues. The IP is not blocked by Apple.

Have you experienced the same and what could be possible root causes/fixes?

Got it thanks for the advise ✅

unfortunately not that much... see below


$ sudo pkg install -f os-sensei
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'os-sensei' have been found in the repositories
$

See attached

Hi, any advise how I upgrade SENSEI if the packages are shown as orphaned in the systems firmware section of opnsense 20.1?

Hi, thanks. Indeed I should change the reboot sequence (first modem, then mikrotik router and then firewall) and will do so. However, I am sure this was not the issue as I rebooted the firewall manually afterwards.

I could only remedy the situation in the console by doing a reset to factory defaults and then re-applying the previously saved configuration. Not very elegant I confess but opnsense works flawlessly again. This is only way to get back the internet connection / ping without tinkering around. Probably something with the DNS settings or Wan connection. Any suggestions welcome!

[Setup:]

The Opnsense configuration (on a new DEC4610) was running well since the installation two weeks ago until today when I rebooted the ISP Cablemodem + Mikrotik Router. Now after reboot of the modem there is no internet connection for Wireguard to connect, ping fails and also I get the timeout for the firmware update. When I ping (w/ssh)  I did notice that when I reboot opnsense, I get one(!) ping result connecting to the internet properly. Please advise what would need to be done to get this one back to work..

Setup: Latest Opnsense release 19.7.9, with Wireguard (ivpn), based on the latest Deciso DEC4610 Hardware.

Interfaces (all unchanged):

WAN: Internet > ISP Cablemodem (rebooted) > Mikrotik CCR Router > Opnsense DEC4610 WAN igb3
LAN: Opnsense DEC4610 (igb4) > Mikrotik CCR Router > Aruba LAN/WLAN
WG: wg0

On igb3 I only have ipv4 (ipv6 is set to none) and just one ipv4 gateway
I have two external DNS servers for the WAN (without any override)

I have only a minimum set of additional manual firewall / NAT rules (unchanged):

LAN Interface: ipv4 pass all source: LANnet
WG Interface: iPV4 pass all in
Wireguard Interface: iPV4 pass all in

NAT outbound: Wireguard interface, ipv4, pass, all, Interface address as NAT address
NAT outbound: WG interface, ipv4, pass, all, Interface address as NAT address

thanks this helped to fix it

Thanks to @JohnDoe17's help, we figured out what's causing the Elasticsearch issue.

With 1.1 release, we had removed Elasticsearch package dependency (Because from now on, Sensei can also run with other databases).

With prior installation of Sensei, this means, elasticsearch is now an orphaned package.

OPNsense update triggered a pkg autoclean, which resulted in orphaned elasticsearch5 package being removed.  Reports data is not deleted and safe.

For the workaround, you'll need to re-install elasticsearch with this command;

Code Select Expand

pkg install elasticsearch5

1.1_2 is on the way to handle the new updaters.

hi @mb, hmm thanks! As a first measure, I disabled the use of /tmp RAM disk and /var RAM disk (so that tmp and var are on the hd as opposed to the memory). Since then I rebooted twice and the reporting looks fine. Will let it boot & run for a couple of days to check if this did the trick. Br, Chris

..I get after every reboot the "An error occurred while report is being loaded" message in Sensei.

Error
{
  "error": {
    "root_cause": [
      {
        "type": "index_not_found_exception",
        "reason": "no such index",
        "resource.type": "index_or_alias",
        "resource.id": "conn_all",
        "index_uuid": "_na_",
        "index": "conn_all"
      }
    ],
    "type": "index_not_found_exception",
    "reason": "no such index",
    "resource.type": "index_or_alias",
    "resource.id": "conn_all",
    "index_uuid": "_na_",
    "index": "conn_all"
  },
  "status": 404
}

Also the Live Sessions Explorer does not work then after the reboot. Not sure if Sensei is still operational or not. I can fix this by Reseting the Reporting (under Sensei : Configuration : Reporting & Data) but would expect that this functionality is there out of the box and Sensei survives a system reboot?

Sensei standard install (https://help.sunnyvalley.io/hc/en-us/articles/360024899634-Installing-Sensei-on-OPNsense) on Deciso Rack Xeon box with OPNsense 19.7.3.

Please advise & thanks in advance, Chris

I am on OPNsense 17.7.12-amd64, and I have one simple setup (1 LAN, 2 WAN) and connect all clients through the openvpn client. So three interfaces: 1 LAN, 2 WAN,  3 OpenVPN client. All works fine and I wanted to enable the web proxy as well. Hence I followed https://docs.opnsense.org/manual/how-tos/proxywebfilter.html to setup the web proxy.

In the last step 6 - when I block the port 80/443 to disable proxy bypass, the clients cannot browse in the internet anymore so somehow the clients are not routed to port 3128 http / 3129 https of the webproxy?

Please advise if you have a tip on the above with the correct firewall / NAT settings in conjunction with the ovpninterface/alias?