Topics

1

20.7 Legacy Series / FFR: RIP set Neighbor possible?

« on: October 16, 2020, 08:18:37 am »

Hi guys,

can we set the neighbor-ip in the RIP-Settings for OPNsense to use unicast-messages to the neighbor?

Thanks and

Greetings
Mike

2

General Discussion / Where is the forum for 20.1?

« on: December 15, 2019, 09:44:31 pm »

Hey guys,

where is the forum for OPNsense 20.1? I think, i'm missing this

Cheers
Migele

3

18.7 Legacy Series / HAProxy: Redirect to subfolder don't work

« on: December 04, 2018, 12:42:58 pm »

Hello,

actually i work on a redirect-rule in HAProxy, which doesn't work.
In my example, a call to http://intranet.complex.org should redirected to http://intranet.complex.org/department. Following is the configured setup. What i do wrong?

This is what i already configured (IP's and Names are fictional):

Real-Server
Name:              Webserver
IP:                   192.168.69.69
Port:                 80

Condition:
Name:              Intranet
Type:                Host start with
Prefix:              intranet

Rule:
Name:              Intranet
Test type:         IF
condition:         Intranet
Log. operator:   none
execute func:    http-request redirect
HTTP Redirect:  location http://intranet.complex.org/department

Backend Pool:
Name:              Intranet
Servers:           Webserver
Rules:              Intranet

Public Service:
Name:              HTTP_Internal
Listen-Address: 192.168.69.1:80
Backend-Pool:   none
Rules:               Intranet

4

17.7 Legacy Series / [SOLVED] Update to 18.1 is successful, but after restart still on old version

« on: May 14, 2018, 04:34:30 pm »

Hello Guys,

today, i saw, that one of our firewalls are on a older version (17.7.11). Now, i want to move to a newer version...

I try the update from the GUI. First the OPNsense has made an update to the 17.7.12 without reboot.
Then, as usual, I had to "unlock" the upgrade to 18.1 in the GUI to be able to install the latest version afterwards. After the upgrade, OPNsense will restart automatically, but after login, OPNsense shows me the version 17.7.11.

The same issue occure, when i try these steps from Shell and running "opnsense-upgrade", "pkg update -f" or rather with "opnsense-update" and type "18.1". In addition, the upgrade via the menu item "12" for a "Upgrade" do work, but after a new reboot, it will boot with 17.7.11 again :-/

What I also noticed is that the configuration does not contain the latest changes after each restart.

This machine is a APU1D4 with 16GB SSD-Storage, and how the name describes with 4GB RAM...

What can I do, to resolve this problem and switch to a new secure platform?



Cheers Mikele

5

18.1 Legacy Series / [SOLVED] Is the i386 architecture supported with OPNsense 18.1 and later?

« on: January 16, 2018, 10:08:08 am »

Hello,

is the i386 architecture supported with OPNsense 18.1 and later?

The question arises because I have some ALIX 2D13 that I want to install with the OPNsense,
but I don't know how long OPNsense supports i386.

Thanks

Regards
Mike

6

17.7 Legacy Series / HA - Syncing takes a long time | HA - Synchronisierung braucht lange

« on: November 28, 2017, 04:23:42 pm »

Hello Ladys and Gentlemen ,

not long ago, we turned our backs on pfSense and switched to OPNsense.
And really, we are very happy even if there are small differences or subtleties here and there.

However, there is a problem that we would like to have solved. We have two OPNsense in VMs with functional high availability.

If we save something on the master (whether it is a rule or a gateway), it takes about 2 minutes until the rule has been adopted on both systems.

In the event log, we cannot detect any errors during synchronization.
The fact that we have over 18 VLANs and 22 interfaces should not go unmentioned.

What can we do to speed up the synchronization or is this a system error?

------------------
German Version
------------------
Hallo Ladys and Gentlemen  ,

vor nicht allzu langer Zeit haben wir pfSense den Rücken gekehrt und sind zu OPNsense gewechselt.
Und wirklich, wir sind sehr glücklich, auch wenn es hier und da kleine Unterschiede oder Feinheiten gibt.
Es gibt jedoch ein Problem, welches wir gerne gelöst haben wollen. Wir haben zwei OPNsense in VMs mit funktierender Hochverfügbarkeit.

Wenn wir auf dem Master etwas abspeichern (sei es eine Regel oder ein Gateway), dauert es ca. 2 Minuten, bis die Regel auf beiden System übernommen wurde.

Im Ereignisprotokoll können wir keine Fehler bei der Synchronisierung ausmachen.
Dass wir über 18 VLANs und 22 Interfaces haben, soll auch nicht unerwähnt bleiben.

Was können wir machen, um die Synchronisierung zu beschleunigen oder ist das ein Fehler im System?

tested with:
- 18.1.x
- 17.7.8
- 17.7.7

Nov 28 16:00:16   configd.py: [c352d80d-23ca-4341-8200-8f62d4cf0561] request pfctl byte/packet counters
Nov 28 16:00:11   configd.py: [958c25b6-ab7e-481c-959b-86d8d0d5e72d] request pfctl byte/packet counters
Nov 28 16:00:05   configd.py: [82d47999-6a71-43c6-a3e5-ab52ae830388] request pfctl byte/packet counters
Nov 28 16:00:00   configd.py: [c6430ee4-45a9-41f8-ab4a-ee85d3b6fbf8] request pfctl byte/packet counters
Nov 28 15:59:54   configd.py: [f221a75f-f7d7-4dc2-a1c9-d71c67ff7472] request pfctl byte/packet counters
Nov 28 15:59:49   configd.py: [248ad6be-15d3-4b98-b731-683639fea538] request pfctl byte/packet counters
Nov 28 15:59:43   configd.py: [c377882f-3c64-4c6d-8956-10cb6d5d53df] request pfctl byte/packet counters
Nov 28 15:59:37   configd.py: [33b5d090-051a-45c2-b247-aca52b2ca98d] request pfctl byte/packet counters
Nov 28 15:59:35   opnsense: /usr/local/etc/rc.filter_synchronize: Filter sync successfully completed with https://10.XXX.XXX.X:XX/xmlrpc.php.
Nov 28 15:59:32   configd.py: [15f25cba-d4e1-46f2-851f-d83a20fe427c] request pfctl byte/packet counters
Nov 28 15:59:26   configd.py: [5e044820-db01-4ecc-bafb-65cb9ddad286] request pfctl byte/packet counters
Nov 28 15:59:21   configd.py: [cc33c2fa-28fe-41f7-bf0e-1f790feae0d9] request pfctl byte/packet counters
Nov 28 15:59:15   configd.py: [70e8390b-0fff-4c4a-b4a6-222bb920ad87] request pfctl byte/packet counters
Nov 28 15:59:10   configd.py: [510b110a-210b-4c9a-bc2a-23153cafeda3] request pfctl byte/packet counters
Nov 28 15:59:04   configd.py: [5afde80e-9b4b-4cc4-9b2c-928a96c7fa66] request pfctl byte/packet counters
Nov 28 15:58:58   configd.py: [0ffd2acb-96f1-4f07-a122-c5a9ab966aaf] request pfctl byte/packet counters
Nov 28 15:58:53   configd.py: [aed4dd90-b611-47b8-b70b-b234707ad988] request pfctl byte/packet counters
Nov 28 15:58:47   configd.py: [424e803d-7355-4d8f-803f-aa54f58c19e7] request pfctl byte/packet counters
Nov 28 15:58:42   configd.py: [795037f0-e93b-47e2-bf19-9bfa263cde8c] request pfctl byte/packet counters
Nov 28 15:58:36   configd.py: [feaca92b-af7f-4bbd-a20c-f0c0f982ec58] request pfctl byte/packet counters
Nov 28 15:58:31   configd.py: [6b9a64c2-f3f8-4643-a675-ad01b5fbd762] request pfctl byte/packet counters
Nov 28 15:58:25   configd.py: [264626da-c674-49b6-8743-0dab9f5ca181] request pfctl byte/packet counters
Nov 28 15:58:19   configd.py: [76afef29-ad3e-4051-8c0f-4893d0df3659] request pfctl byte/packet counters
Nov 28 15:58:14   configd.py: [e4ac451d-ece7-46a4-bf0e-f6a6d012c10f] request pfctl byte/packet counters
Nov 28 15:58:08   configd.py: [165ae544-addf-4053-8249-2c5c4b18d3a5] request pfctl byte/packet counters
Nov 28 15:58:03   configd.py: [543db775-21f3-478a-af21-df83bcafb7c8] request pfctl byte/packet counters
Nov 28 15:57:57   configd.py: [a549d050-9126-40ed-b6dd-c8d9102483cb] request pfctl byte/packet counters
Nov 28 15:57:52   configd.py: [1fa9b1a1-cbd5-41f3-a023-5872941c5f3a] request pfctl byte/packet counters
Nov 28 15:57:52   configd.py: [9226d475-1ef7-44e6-8a19-fde3bafc9019] Syncing firewall restart
Nov 28 15:57:48   configd.py: [7e0bd41c-7389-43ee-894c-93d131ea4b38] Reloading filter