Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - interfaSys

#1
Just to confirm.
The replacement box had some changes which made it look like dpinger wasn't working.
OpenVPN connections were established, but content could not flow through due to a cipher issue. That means that dpinger could no ping the monitoring IP.
And the WAN gateway had monitoring disabled for some reason, which is the reason the dpinger service was never started when the other gateways were down.

Thanks for your help marjohn56
#2
Something I've noticed.
The gateway at the top of the list is an OpenVPN one. When it's online, dpinger starts and is marked as green. I have logs.
It goes down, dpinger goes down, depsite the fact that WAN is still up, lower in the list.
Is this the way it's supposed to work? If the only Gateway up is the default, then dpinger is always down?
#3
I think I've found one of the problems.
All the OpenVPN interfaces had been reset to the LAN NIC instead of keeping their VLAN due to a bug in the Interface sub-routine on 19.1.1.
I've re-assigned all of them and now the single interfaces show up as online in the "Single" view, but dpinger still doesn't start.
#4
I edited my answer earlier with my config. It looks like yours, except for the default gateway.

<quote>How is your WAN setup is it static, dhcp PPPoE? Are your gateways auto created or manual?</quote>

WAN is up, using DHCP. It's marked as online, depsite dpinger being down.

The OpenVPN gateway is also using DHCP. It was manually created as an OpenVPN client, then the interface was assigned, in the Interfaces section.
#5
Same problem as in all gateways relying on dpinger are down and cannot be started.
I have gateway monitoring on OpenVPN, but the OpenVPN service is up an running and connected to the remote locations.
Both appliances are on 19.1.1.
Nothing in the gateway or main logs.

Gateway config:
Interface: OpenVPN interface 1
Address family: IPv4
IP address: synamic
Monitor IP: 1.1.1.1

Everything else in unticked.
#6
Same problem here.

Upgrading from 18.7 broke all Open VPN gateways. They can't be started. Gateway logs show nothing.
Happened on 2 different appliances.
#7
Any way to already upgrade to 19.1 RC via the console?
I have a spare system on 18.7 with ZFS which I could test with.
#8
General Discussion / Re: ZFS
October 01, 2018, 11:58:44 AM
Just a heads up. When using ZFS, password recovery from the live image does not work any more. The script can't mount the partitions.
#9
Fitlet2 with extra LAN on 0.46 bios.

Since I wanted to use ZFS, I had to start with FreeBSD 11.1 and use a script to install of 18.7.4.
The only parameter I needed to add after the installation was: set hint.ahci.0.msi=2

I had disabled mwait and SDHC in the BIOS.

Had to install twice because of the broken installation wizard which destroy passwords. When using ZFS, password recovery from the live image does not work.

#10
OK, so the last step is to upgrade via the GUI.

1. console:

select 8
# opnsense-update -t opnsense-devel
# exit


2. console

select 12
type "18.1.r2" and hit enter


3. GUI

Check for update and upgrade to 18.1.r2

4. console

select 8
# opnsense-patch bba40c97 947718b

#11
Post reboots, the console tells me I'm on r66 and the GUI still says my version is NA, but I can upgrade to 18.1.r2.

Is this the normal behaviour?
#12
Re-read the instructions...

Missed this: type "18.1.r2"

So, it's my fault, but I find the interactive menu confusing. When reading it, I thought it was asking me if I wanted to update to 18.1.r2 and so I pressed "y".

Seems to be downloading base + kernel now, so it should work :)
#13
I've followed the steps above, but it doesn't work. I've edited my message too many times.

Started with 18.1.b + 17.7.11.

After using option 12, I get:

QuoteKernel locked at 18.1.b-amd64, skipping.
Base locked at 18.1.b-amd64, skipping.

Console says I'm on 18.1.r_82. Not sure if it's the same as R2 or if it's still b1

No reboots were performed.

GUI says my current version is "N/A" and that I can upgrade to 17.7.12.

So it seems the upgrade process is missing some steps.
#14
I was on 18.1.b + 17.7.11 and the upgrade process described above doesn't work.

System did not reboot a single time.

Kernel locked at 18.1.b-amd64, skipping.
Base locked at 18.1.b-amd64, skipping.



1 patch didn't apply cleanly.

# opnsense-patch bba40c97 947718b
...
|diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc
|index e93a9f4f6..cc6a08317 100644
|--- a/src/etc/inc/filter.inc
|+++ b/src/etc/inc/filter.inc
--------------------------
Patching file etc/inc/filter.inc using Plan A...
Reversed (or previously applied) patch detected!  Assuming -R.Hunk #1 succeeded at 510.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
...


Post was edited because I was missing a step.
#15
Quote from: Ren on November 20, 2017, 08:31:24 PM
I'm running the same system with 4GB of ram and did not experience any reboots.

Which BIOS are you running?