Messages

thanks, this makes sense!

Hi,

I am just refactoring a couple of our firewalls and doing so, I stumbled upon how outbound NAT has been configured so far.

Some of our outbound translation targets have x.x.x.x/32, whereas some have x.x.x.x/28 for example. Both settings work, apparently, and if I use dig to find out what IP address they are translated to, I get

- for a x.x.x.x/32 translation target:
$ dig +short myip.opendns.com @resolver1.opendns.com
x.x.x.x

- for a x.x.x.x/28 translation target:
$ dig +short myip.opendns.com @resolver1.opendns.com
x.x.x.0

So far so good, but I am confused: why would I ever specify anything else but a /32 host address as a translation target? What's the usecase for such a scenario?

thanks, I was afraid so. IPSec is no option for me, unfortunately.

What I did instead was to implement a very dirty outbound NAT rule that would force the required IP address for connections to my remote WG peer ... In the end it's just one connection to do NAT, so I have some hope that this won't be too bad on system load. This isn't in production yet, so hopefully this works out until this can be done properly in OPNsense.

My network configuration is somewhat unusual, as my WAN side is actually a private network, while my LAN side is a publicly routable /24 network.

In simplified terms, the data flow looks as follows:

Internet -> public IP@dedicated hardware router -> private network for CARP@OPNsense -> public /24 network

To allow various infrastructure devices to access the Internet, the dedicated hardware router has been configured to perform simple NAT functions for the CARP network only.

When I initiate a Wireguard connection from OPNsense, the connection is established via the CARP address of OPNsense and then routed to the dedicated router, which takes over the NAT functions. Although this works technically, it is not a practical option because the hardware router cannot handle the amount of data in terms of both bandwidth and connections that will pass over wireguard.

Instead, I would like Wireguard to initiate the connection via the OPNsense LAN address. This way, no NAT takes place at the router because the packets are only routed.

Does anyone have any idea how this can be achieved?

Now I get you, thanks!

well, unfortunately it turns out that you cannot change the web UI's listen interface to loopback, at least not in the settings page:

You cannot view this attachment.

thanks again. The manual page you mention says this about the "Listen Interfaces" for the Web GUI:

"Can be used to limit interfaces on which the Web GUI can be accessed. This allows freeing the interface for other services, such as HAProxy."

And this is actually quite exactly what I need.

But I really like the workaround with loopback. While this adds some complexity, this is a very good and simple enough workaround, and I'll just do that. Thanks for bringing it up!

yes, thanks, but this would only be some kind of a workaround.

It would, for example, occupy a prominent port on the WAN interface (443), which is unfortunately not possible. And I also don't want to use a port other than 443 for the web UI, because that would make integration into the rest of our infrastructure more difficult.

Hi,

we're using a dedicated management VLAN and want to restrict access to the Web UI to this VLAN.

After changing the "Listen Interfaces" in System->Administation for the Web UI to anything else but "All", the webgui does not survive a reboot. The lighttpd process does not start:

Code Select Expand

$ ps auxw | grep lighttpd
root 37063  0.0  0.0  432  260  0  R+  15:45  0:00.00 grep lighttpd
$
$ grep -3 webgui /conf/config.xml
  <nextgid>2000</nextgid>
    <timezone>Europe/Vienna</timezone>
    <timeservers>0.opnsense.pool.ntp.org 1.opnsense.pool.ntp.org 2.opnsense.pool.ntp.org 3.opnsense.pool.ntp.org</timeservers>
    <webgui>
      <protocol>https</protocol>
      <ssl-certref>6797c09c58f44</ssl-certref>
      <port/>
      <ssl-ciphers/>
      <interfaces>lan,wan,management</interfaces>
      <compression/>
    </webgui>
    <disablenatreflection>yes</disablenatreflection>
    <usevirtualterminal>1</usevirtualterminal>
    <disableconsolemenu>1</disableconsolemenu>
Both LAN, WAN and management interfaces obviously exist in the system.

I can manually start the web ui via configctl:

Code Select Expand

$ configctl webgui restart
OK


$ ps auxw | grep lighttpd
root 87536  0.0  0.9 20188  8796  -  S    15:50  0:00.00 /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf
root 98794  0.0  0.0  432  268  0  R+  15:51  0:00.00 grep lighttpd
The only way I can make the web ui start up after a reboot is by resetting the "Listen Interfaces" back to "All":

Code Select Expand

$ grep -3 webgui /conf/config.xml
[...]    
    <webgui>
      <protocol>https</protocol>
      <ssl-certref>6797c09c58f44</ssl-certref>
      <port/>
      <ssl-ciphers/>
      <interfaces/>
      <compression/>
    </webgui>
[...]    
For what it's worth, all the interfaces (LAN, WAN, management) are tagged for a dedicated VLAN, so maybe that's the problem.

This happens with version 24.7, haven't tried with 25.x yet.

Some releases ago, we got the new "renew certificate" feature in System->Trust (via edit->"reissue and replace certificate").

We mostly use certificates to authenticate users against the OpenVPN instance running on OPNsense and the renewal itself works just fine. What seems to get lost however is the link to the users. The "in use" column shows that most certificates don't appear to be "used" when instead they do actually belong to an user, see the attached screenshot. Only original certificates created using Access->Users->User certificates have the user icon in the "in use" column. But once they get renewed, they loose the user icon in the System->Trust list and also, they are not listed in the user's profile page in Access->Users.

But OpenVPN nevertheless seems to correctly link them to the users. Looks like a bug to me, or is there a reason for this behaviour?

Thanks

Hi all,

I'm just planning a new OPNsense deployment where we have been assigned a public /28 network plus a public gateway address from a different /29 range. Both the public /28 network and the gateway are being managed by OPNsense, see the attached image for an graphic description.

So in other words, OPNsense acts as a router via the public 1.2.3.2/29 address and as a firewall for the /28 public addresses.

This has been working as a standalone installation for a while, but now I need to convert this into a more failsafe version.

As far as I understood from reading the docs, doing some research on the FreeBSD forums and google in general, the only thing that can be made highly available are the public /28 adresses, but not the gateway/router functionality. We've been assigned only one gateway address out of the /29 upstream network and afaik CARP on the other hand requires 3 public IPs to achieve HA. Is that correct or did I miss something here?

One way I can think of was asking to my ISP to assign us more than one IP from the /29 upstream network and then configure a different metric value for the two potential routes into our public /28 network in their routers, but I have no clue if they would do it and also, if I could make this work in OPNsense.

Another option I can think of is to squeeze a dedicated router between upstream and OPNsense, but that wouldn't exactly be highly available ...

Or is there another reasonable way to do this?

Alright, so after a day of debugging and trying to figure out what was doing on I also investigated the remote firewall settings that I was trying to connect to.

What helped there was to disable the OpenVPN address pool that was configured at the server side to keep client IP tunnel addresses stable over disconnects.

After disabling the pool on the server side (peera.example.com in my example), I could connect to the server from peerb.example.com as a client, now assigned a new peer to peer tunnel address.

So for the time being, things are working again, but I am still flabbergasted what went wrong after the update in the first place ...

thanks for that idea. From a network POV, I should be able to assign the same IP address to multiple interfaces (for very exotic configurations), but that isn't the case here anyways:

Code Select Expand

root@peerb:~ # ifconfig | grep -2 '10.19'
root@peerb:~ #
root@peerb:~ # ifconfig ovpnc1
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
groups: tun openvpn
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@peerb:~ # /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
ifconfig: ioctl (SIOCAIFADDR): File exists
root@peerb:~ #
root@peerb:~ # /sbin/ifconfig ovpnc1 10.19.0.16 10.19.0.15 mtu 1500 netmask 255.255.255.255 up
root@peerb:~ # ifconfig ovpnc1
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 10.19.0.16 --> 10.19.0.15 netmask 0xffffffff
groups: tun openvpn
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
root@peerb:/var/etc/openvpn #


... so how weird is that ... I cannot assign 10.19.0.6, but I can assign 10.19.0.16 ...

Hi,

after doing a minor update from 23.7.x to 23.7.5, one of our firewalls fails to establish a previously working OpenVPN peer-to-peer connection to another firewall. No setting has been changed and looking at the logs, I don't see much of a difference, except that after the upgrade I see a "FreeBSD ifconfig failed: external program exited with error status: 1", but have a look for yourself (IP addresses and host names etc redacted):

logs from before the upgrade:

Code Select Expand

<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="26"] WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="27"] DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="28"] OpenVPN 2.6.6 amd64-portbld-freebsd13.2 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD]
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48537 - [meta sequenceId="29"] library versions: OpenSSL 1.1.1v  1 Aug 2023, LZO 2.10
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="30"] MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="31"] WARNING: using --pull/--client and --ifconfig together is probably not what you want
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="32"] WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
<28>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="33"] NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="34"] TCP/UDP: Preserving recently used remote address: [AF_INET]233.252.0.237:1195
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="35"] Socket Buffers: R=[42080->42080] S=[57344->57344]
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="36"] UDPv4 link local (bound): [AF_INET]233.252.0.103:0
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="37"] UDPv4 link remote: [AF_INET]233.252.0.237:1195
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="38"] TLS: Initial packet from [AF_INET]233.252.0.237:1195, sid=74dd58be 5cba6ac3
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="39"] VERIFY OK: depth=2, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com CA 2022, emailAddress=foobar@example.com
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="39"] VERIFY OK: depth=1, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com HTTPS CA 2022, emailAddress=foobar@example.com
<29>1 2023-09-09T19:54:17+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="39"] VERIFY OK: depth=0, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=peera.example.com, emailAddress=foobar@example.com
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="58"] Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="59"] [peera.example.com] Peer Connection Initiated with [AF_INET]233.252.0.237:1195
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="60"] TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="61"] TLS: tls_multi_process: initial untrusted session promoted to trusted
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="62"] PUSH: Received control message: 'PUSH_REPLY,route 172.21.1.0 255.255.255.0,route 172.21.254.0 255.255.255.0,route 172.16.5.0 255.255.255.0,route 172.21.7.0 255.255.255.0,route 172.22.0.0 255.255.255.0,route 172.22.1.0 255.255.255.0,route 172.21.253.0 255.255.255.0,route 10.9.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.19.0.6 10.19.0.5,peer-id 0,cipher AES-256-GCM'
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="63"] OPTIONS IMPORT: --ifconfig/up options modified
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="64"] OPTIONS IMPORT: route options modified
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="65"] ROUTE_GATEWAY 233.252.0.242/255.255.255.255 IFACE=pppoe0 HWADDR=00:00:00:00:00:00
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="66"] TUN/TAP device ovpnc1 exists previously, keep at program end
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="67"] TUN/TAP device /dev/tun1 opened
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="68"] /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="69"] /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpnc1 1500 0 10.19.0.6 10.19.0.5 init
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="70"] /sbin/route add -net 172.21.251.0 10.9.0.5 255.255.255.0
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="71"] /sbin/route add -net 172.16.5.0 10.9.0.5 255.255.255.0
<29>1 2023-09-09T19:54:18+02:00 peerb.example.com openvpn_client1 48688 - [meta sequenceId="72"] /sbin/route add -net 172.21.1.0 10.9.0.5 255.255.255.0
[...]


logs from after the upgrade with the failing connection:

Code Select Expand


<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="26"] WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="27"] DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="28"] OpenVPN 2.6.6 amd64-portbld-freebsd13.2 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD]
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81021 - [meta sequenceId="29"] library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.10
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="30"] MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="31"] WARNING: using --pull/--client and --ifconfig together is probably not what you want
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="32"] WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
<28>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="33"] NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="34"] TCP/UDP: Preserving recently used remote address: [AF_INET]233.252.0.237:1195
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="35"] Socket Buffers: R=[42080->42080] S=[57344->57344]
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="36"] UDPv4 link local (bound): [AF_INET]233.252.0.103:0
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="37"] UDPv4 link remote: [AF_INET]233.252.0.237:1195
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="38"] TLS: Initial packet from [AF_INET]233.252.0.237:1195, sid=ece7d1b9 47113c63
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="39"] VERIFY OK: depth=2, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com CA 2022, emailAddress=foobar@example.com
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="40"] VERIFY OK: depth=1, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=Example.com HTTPS CA 2022, emailAddress=foobar@example.com
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="41"] VERIFY OK: depth=0, C=AT, ST=Tirol, L=Innsbruck, O=Example.com, OU=sysops team, CN=peera.example.com, emailAddress=foobar@example.com
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="58"] Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="59"] [peera.example.com] Peer Connection Initiated with [AF_INET]233.252.0.237:1195
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="60"] TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="61"] TLS: tls_multi_process: initial untrusted session promoted to trusted
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="62"] PUSH: Received control message: 'PUSH_REPLY,route 172.21.1.0 255.255.255.0,route 172.21.254.0 255.255.255.0,route 172.16.5.0 255.255.255.0,route 172.21.7.0 255.255.255.0,route 172.22.0.0 255.255.255.0,route 172.22.1.0 255.255.255.0,route 172.21.253.0 255.255.255.0,route 10.9.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.19.0.6 10.19.0.5,peer-id 0,cipher AES-256-GCM'
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="63"] OPTIONS IMPORT: --ifconfig/up options modified
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="64"] OPTIONS IMPORT: route options modified
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="65"] ROUTE_GATEWAY 233.252.0.242/255.255.255.255 IFACE=pppoe0 HWADDR=00:00:00:00:00:00
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="66"] TUN/TAP device ovpnc1 exists previously, keep at program end
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="67"] TUN/TAP device /dev/tun1 opened
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="68"] /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
<27>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="69"] FreeBSD ifconfig failed: external program exited with error status: 1
<29>1 2023-10-06T17:52:04+02:00 peerb.example.com openvpn_client1 81047 - [meta sequenceId="70"] Exiting due to fatal error


In the meantime, I've tried all kinds of things (like recreating the connection in new "Instances" page), but all to no avail unfortunately.

little update: when trying to initiate the connection directly on the shell, I see that ifconfig fails with "ifconfig: ioctl (SIOCAIFADDR): File exists":

Code Select Expand

# /usr/local/sbin/openvpn --log /var/log/foobar.log --errors-to-stderr --config /var/etc/openvpn/client1.conf
root@peerb:/usr/local # tail -5 /var/log/foobar.log
2023-10-07 12:46:27 TUN/TAP device /dev/tun1 opened
2023-10-07 12:46:27 /sbin/ifconfig ovpnc1 10.19.0.6 10.19.0.5 mtu 1500 netmask 255.255.255.255 up
ifconfig: ioctl (SIOCAIFADDR): File exists
2023-10-07 12:46:27 FreeBSD ifconfig failed: external program exited with error status: 1
2023-10-07 12:46:27 Exiting due to fatal error


Any ideas?

Hi Beki,

thanks for the information. I wasn't aware that the WAN interface wouldn't be shown on purpose and subsequently didn't really check the new config UI, because I thought that all my issues were due to the "missing" interface.

However, after checking the available config options, it seems that I simply didn't configure any blocks and after enabling them, everything works now.

Thanks again!