"Recent posts
#1
26.1, 26,4 Series / Re: kea dhcp option for debian...
Last post by Monviech (Cedrik) - Today at 10:07:14 PMWell there is a difference between:
- BOOTP
and
- Option 67
BOOTP comes from a time where DHCP options have not yet existed standardized.
Its weird that Debian doesnt take a notmal DHCP option and prefers the legacy BOOTP file.
Since its not a DHCP option, it's not available in the new DHCP option framework that we built.
- BOOTP
and
- Option 67
BOOTP comes from a time where DHCP options have not yet existed standardized.
Its weird that Debian doesnt take a notmal DHCP option and prefers the legacy BOOTP file.
Since its not a DHCP option, it's not available in the new DHCP option framework that we built.
#2
26.1, 26,4 Series / Re: kea dhcp option for debian...
Last post by cybermcm - Today at 10:00:07 PMI tried it with option 67 as string and also converted to hex. But the string doesn't get send to the client with the GUI setting whereas with the manual config it works.
#3
26.1, 26,4 Series / Re: kea dhcp option for debian...
Last post by Monviech (Cedrik) - Today at 09:50:01 PMIsnt boot file name just option 67?
Why doesn't the docs example work for you?
It's a string, you can also input your full URL in there.
Inside the config file you will always see hex since it will be converted when written into the configuration (GUI shows the string, config shows that string as hex)
Does that debian installer only react to the legacy "BOOTP header file field" and not to the standard option 67?
Why doesn't the docs example work for you?
It's a string, you can also input your full URL in there.
Inside the config file you will always see hex since it will be converted when written into the configuration (GUI shows the string, config shows that string as hex)
Does that debian installer only react to the legacy "BOOTP header file field" and not to the standard option 67?
#4
26.1, 26,4 Series / Re: ping: sendto: Invalid argu...
Last post by viragomann - Today at 09:37:03 PMYour outbound NAT rules are not clear to me. Why did you use single from addresses:
And I don't see a rule for 127.0.0.0/28 at all.
Maybe a screenshot can show it better.
Are the rule on master and backup even the same?
Note, that you have to add the rule on the master if they are synced to the backup. Otherwise the backup rules get overwritten by the sync.
Quote from: ajr on Today at 06:52:38 PMnat on igb1 inet from ! <opn2_igb1_plus_lo_addr> ...
nat on igb1 inet from <opn2_igb1_plus_lo_addr> ...
And I don't see a rule for 127.0.0.0/28 at all.
Maybe a screenshot can show it better.
Are the rule on master and backup even the same?
Note, that you have to add the rule on the master if they are synced to the backup. Otherwise the backup rules get overwritten by the sync.
#5
26.1, 26,4 Series / Re: kea dhcp option for debian...
Last post by cybermcm - Today at 09:29:47 PMI did some more digging and from my point of view the substring part isn't the problem. I did a trace and I figured out that option 60 is exactly 'd-i'. I think the problem is that with my working manual config the return value from kea is only 'Boot file name: https://xyz.net/preseed.cfg'; but not as an actual DHCP option. Is this doable with the GUI settings, provide a 'boot file name' if option 60 is 'd-i'?
#6
26.1, 26,4 Series / Upgrade from 25.7 to 26.1 resu...
Last post by transmissionend - Today at 09:21:18 PMHello everyone,
I currently have a reproducible issue with OPNsense on a PC Engines APU2D4 and would appreciate any hints or similar experiences.
## Hardware / Setup
* PC Engines APU2D4
* Serial console only (no VGA)
* mSATA SSD
* FreeBSD base installation with GELI encryption
* Afterwards bootstrapped to OPNsense
## Initial Situation
The system previously worked fine with OPNsense 25.7.
The upgrade to 26.1 was performed from an existing FreeBSD installation using:
opnsense-update -ur 26.1
pkg upgrade
The upgrade process itself completes successfully without errors.
---
# Problem
After:
* successfully upgrading to 26.1 with 3 reboots
or
* performing a completely fresh FreeBSD - OPNsense 26.1 (bootstrap) installation and restoring my old configuration
the system gets stuck during the boot process.
Without restoring the config on fresh FreeBSD - OPNsense 26.1 (bootstrap) installation, it boots normally.
But with restored config:
* GELI unlock works
* boot messages continue normally
* output then appears to stop at:
amdtemp0: found 4 cores and 1 sensors
---
# Important Findings:
After additional testing, the system also seems to not be completely frozen on newer versions.
If I:
* install a fresh FreeBSD + OPNsense 25.7
* then restore the same old config
the APU2 shows EXACTLY the same behavior at serial:
* console output appears to stop at `amdtemp0`
HOWEVER, with the older 25.7 version:
* network interfaces are initialized correctly
* the WebGUI is fully reachable
* routing/firewall functionality works normally
This strongly suggests that:
* the serial console and/or
* console login / getty / tty handling
stops working correctly after restoring the configuration.
---
# Additional Observations
* newly attached USB devices are still detected
* corresponding kernel messages continue to appear on the serial console
* the kernel/system itself therefore still appears to be running
On OPNsense 26.1 additionally (with also old config restore:
* no reachable interfaces/WebGUI
* possibly an additional issue related to config/plugins/interface mapping
---
# Additional Important Information:
During the original FreeBSD installation I enabled all optional security hardening settings offered by the installer, including:
* hide_uids
* hide_gids
* hide_jail
* procfs restrictions
* read_msgbuf
* random_pid
* additional sysctl/hardening options
(Possibly relevant regarding tty/getty/login/serial console behavior.)
---
# Current Suspicions
At the moment I suspect a combination of:
* serial console/getty issue
* old console/TTY settings in config.xml
* possible plugin incompatibility
* old interface/VLAN mapping
* FreeBSD 14 / OPNsense 26.1 interaction on APU2
* possible interaction with enabled FreeBSD hardening options
Currently the behavior looks more like:
* console/login broken plus some init issues or something else during startup
rather than:
* a complete system freeze.
---
# Planned Analysis
Next I plan to:
* boot the system with the restored config until the apparent "hang"
* power it off
* boot the mSATA in another machine
* analyze logs and config.xml there
=> however, as a FreeBSD beginner, recovering/debugging FreeBSD bootloader issues is still somewhat tricky for me and can take some time
Relevant files are probably:
/var/log/system/latest.log
/var/log/boot/latest.log
/var/log/configd/latest.log
/conf/config.xml
---
# Questions
1. Has anyone experienced similar issues with
* APU2
* serial console
* restored configs
* OPNsense 26.1
* FreeBSD 14?
2. Are there any known issues involving
* old console/TTY settings
* plugins
* getty/serial login
* restored config.xml on 26.1?
3. Could the enabled FreeBSD hardening options be relevant here?
Thanks in advance
I currently have a reproducible issue with OPNsense on a PC Engines APU2D4 and would appreciate any hints or similar experiences.
## Hardware / Setup
* PC Engines APU2D4
* Serial console only (no VGA)
* mSATA SSD
* FreeBSD base installation with GELI encryption
* Afterwards bootstrapped to OPNsense
## Initial Situation
The system previously worked fine with OPNsense 25.7.
The upgrade to 26.1 was performed from an existing FreeBSD installation using:
opnsense-update -ur 26.1
pkg upgrade
The upgrade process itself completes successfully without errors.
---
# Problem
After:
* successfully upgrading to 26.1 with 3 reboots
or
* performing a completely fresh FreeBSD - OPNsense 26.1 (bootstrap) installation and restoring my old configuration
the system gets stuck during the boot process.
Without restoring the config on fresh FreeBSD - OPNsense 26.1 (bootstrap) installation, it boots normally.
But with restored config:
* GELI unlock works
* boot messages continue normally
* output then appears to stop at:
amdtemp0: found 4 cores and 1 sensors
---
# Important Findings:
After additional testing, the system also seems to not be completely frozen on newer versions.
If I:
* install a fresh FreeBSD + OPNsense 25.7
* then restore the same old config
the APU2 shows EXACTLY the same behavior at serial:
* console output appears to stop at `amdtemp0`
HOWEVER, with the older 25.7 version:
* network interfaces are initialized correctly
* the WebGUI is fully reachable
* routing/firewall functionality works normally
This strongly suggests that:
* the serial console and/or
* console login / getty / tty handling
stops working correctly after restoring the configuration.
---
# Additional Observations
* newly attached USB devices are still detected
* corresponding kernel messages continue to appear on the serial console
* the kernel/system itself therefore still appears to be running
On OPNsense 26.1 additionally (with also old config restore:
* no reachable interfaces/WebGUI
* possibly an additional issue related to config/plugins/interface mapping
---
# Additional Important Information:
During the original FreeBSD installation I enabled all optional security hardening settings offered by the installer, including:
* hide_uids
* hide_gids
* hide_jail
* procfs restrictions
* read_msgbuf
* random_pid
* additional sysctl/hardening options
(Possibly relevant regarding tty/getty/login/serial console behavior.)
---
# Current Suspicions
At the moment I suspect a combination of:
* serial console/getty issue
* old console/TTY settings in config.xml
* possible plugin incompatibility
* old interface/VLAN mapping
* FreeBSD 14 / OPNsense 26.1 interaction on APU2
* possible interaction with enabled FreeBSD hardening options
Currently the behavior looks more like:
* console/login broken plus some init issues or something else during startup
rather than:
* a complete system freeze.
---
# Planned Analysis
Next I plan to:
* boot the system with the restored config until the apparent "hang"
* power it off
* boot the mSATA in another machine
* analyze logs and config.xml there
=> however, as a FreeBSD beginner, recovering/debugging FreeBSD bootloader issues is still somewhat tricky for me and can take some time
Relevant files are probably:
/var/log/system/latest.log
/var/log/boot/latest.log
/var/log/configd/latest.log
/conf/config.xml
---
# Questions
1. Has anyone experienced similar issues with
* APU2
* serial console
* restored configs
* OPNsense 26.1
* FreeBSD 14?
2. Are there any known issues involving
* old console/TTY settings
* plugins
* getty/serial login
* restored config.xml on 26.1?
3. Could the enabled FreeBSD hardening options be relevant here?
Thanks in advance
#7
German - Deutsch / Re: OpenVPN Roadwarrior auf Si...
Last post by Monviech (Cedrik) - Today at 09:19:51 PMDas Problem ist das Routing.
Auf Site B kennt kein Gerät das OpenVPN Netz, die Pakete werden nicht zurückgeroutet.
Löse es entweder durch Source NAT (Site A OpenVPN client IPs auf Site A LAN interface IP)...
oder durch anpassen des Wireguard Tunnels dass das OpenVPN Netz durchgeroutet wird. Alle Geräte auf Site B müssen zum OpenVPN Netz zurückrouten dürfen.
Beides nicht leicht (wenn man nicht weiß wie), am besten ein Schaubild zeichnen und mal händisch den Weg eines Paketes nachspielen, das hilft immer.
Im Routing Schaubild folgende Fragen für sich selbst beantworten:
- Wer kennt welches Netz?
- Wer ist Gateway für wen?
- Wo wird genattet?
- Wo endet der Tunnel?
- Welche Netze dürfen durch die Policy des Tunnels?
- Wie kommt das Antwortpaket zurück?
Auf Site B kennt kein Gerät das OpenVPN Netz, die Pakete werden nicht zurückgeroutet.
Löse es entweder durch Source NAT (Site A OpenVPN client IPs auf Site A LAN interface IP)...
oder durch anpassen des Wireguard Tunnels dass das OpenVPN Netz durchgeroutet wird. Alle Geräte auf Site B müssen zum OpenVPN Netz zurückrouten dürfen.
Beides nicht leicht (wenn man nicht weiß wie), am besten ein Schaubild zeichnen und mal händisch den Weg eines Paketes nachspielen, das hilft immer.
Im Routing Schaubild folgende Fragen für sich selbst beantworten:
- Wer kennt welches Netz?
- Wer ist Gateway für wen?
- Wo wird genattet?
- Wo endet der Tunnel?
- Welche Netze dürfen durch die Policy des Tunnels?
- Wie kommt das Antwortpaket zurück?
#8
German - Deutsch / OpenVPN Roadwarrior auf Site2S...
Last post by cklahn - Today at 08:51:05 PMHallo,
ich habe zwei Standorte mittels Wireguard verbunden. Standort A hat 192.168.0.0/24, Standort B hat 172.16.10.0/24. An beiden Standorten befinden sich OPNsenses. Ich kann jeweils von beiden Standorten auf Netzwerkfreigaben des gegenüberliegenden Standortes zugreifen. So weit so gut.
Nun habe ich bei Standort A zusätzlich OpenVPN für Roadwarrior eingerichtet, damit man per Notebook auf die Netzlaufwerke von Standort A zugreifen kann. Funktioniert auch.
Nun möchte ich aber, dass ich bei bestehender OpenVPN-Verbindung zu Standort A von ausserhalb auch gleichzeitig auf die Freigaben von Standort B zugreifen, ohne dass ich für Standort B auch ein OpenVPN einrichten muss.
Pings von Extern auf Standort A klappen, auf Geräte in Standort B nicht.
Wie bzw. welche Regeln muss ich zusätzlich bauen?
Für mein Verständnis befindet sich der externe Client bei stehendem OpenVPN-Tunnel im entsprechenden Tunnelnetz. Ich habe hier die folgende Regel:
IP IPv4+6, Protocol Any, Source: OpenVPN_Server Net, Port *, Destination *, Port *, Gateway *, Schedule *
Damit sollte doch alles funktionieren, oder?
Gruß
Christoph
ich habe zwei Standorte mittels Wireguard verbunden. Standort A hat 192.168.0.0/24, Standort B hat 172.16.10.0/24. An beiden Standorten befinden sich OPNsenses. Ich kann jeweils von beiden Standorten auf Netzwerkfreigaben des gegenüberliegenden Standortes zugreifen. So weit so gut.
Nun habe ich bei Standort A zusätzlich OpenVPN für Roadwarrior eingerichtet, damit man per Notebook auf die Netzlaufwerke von Standort A zugreifen kann. Funktioniert auch.
Nun möchte ich aber, dass ich bei bestehender OpenVPN-Verbindung zu Standort A von ausserhalb auch gleichzeitig auf die Freigaben von Standort B zugreifen, ohne dass ich für Standort B auch ein OpenVPN einrichten muss.
Pings von Extern auf Standort A klappen, auf Geräte in Standort B nicht.
Wie bzw. welche Regeln muss ich zusätzlich bauen?
Für mein Verständnis befindet sich der externe Client bei stehendem OpenVPN-Tunnel im entsprechenden Tunnelnetz. Ich habe hier die folgende Regel:
IP IPv4+6, Protocol Any, Source: OpenVPN_Server Net, Port *, Destination *, Port *, Gateway *, Schedule *
Damit sollte doch alles funktionieren, oder?
Gruß
Christoph
#9
Hardware and Performance / Re: TOPTON Mini PC Running OPN...
Last post by Nullman - Today at 08:22:34 PMQuote from: pfry on Today at 08:05:21 PMThere's nothing wrong with a good passive system. It just costs money. (Note the "good".)
If money is issue, go for Qotom. If you cheap out, eventually, its going to cost you more.
Quote from: pfry on Today at 08:05:21 PM(And, going off-topic a bit, it's particularly hard to passively cool a 100+W CPU in an 86+F (30+C) environment.)
100W is overkill for bare metal opnsense machine. If you are running virtualizied with bunch of other stuff, thats a different story. We talk bare metal machines.
Quote from: pfry on Today at 08:05:21 PMUnderstandable. A tradeoff I wasn't willing to make. My firewall is not my loudest device, but even if it was, I'd still make the same choice.We are talking normal home use. Not the rack filled with enterprise grade arista quad power redundant switches and 1kW rack mounted pc monsters running hypervisors. Please stay on track.
Quote from: pfry on Today at 08:05:21 PMSpeaking of thermal testing, mprime is generally more appropriate than memtest, but I don't know of a bootable package that contains a newer version (the UBCD's is a bit old). It's easy enough to fire up a live Linux or FreeBSD image and execute it - it just takes a bit more effort than a bootable package.
Going way of topic dude.
#10
Hardware and Performance / Re: TOPTON Mini PC Running OPN...
Last post by pfry - Today at 08:05:21 PMQuote from: Nullman on Today at 06:36:34 PM[...]Opnsense appliances should always be passive machines with no moving parts.[...]
Opinions are like... (There's a "one size fits all" joke in there somewhere.)
There's nothing wrong with a good passive system. It just costs money. (Note the "good".) (And, going off-topic a bit, it's particularly hard to passively cool a 100+W CPU in an 86+F (30+C) environment.)
Quote[...]I dont want to think about this. I want to setup my firewall and forget that its there.
Understandable. A tradeoff I wasn't willing to make. My firewall is not my loudest device, but even if it was, I'd still make the same choice.
Speaking of thermal testing, mprime is generally more appropriate than memtest, but I don't know of a bootable package that contains a newer version (the UBCD's is a bit old). It's easy enough to fire up a live Linux or FreeBSD image and execute it - it just takes a bit more effort than a bootable package.
