Topics

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?

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?

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?

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,

after working for quite a long time, zenamor has stopped working for me some weeks ago following the latest major update. What essentially happens is nothing. While I can have a look at open web/dns/tls/... sessions (so it appears to be intercepting traffic), nothing is blocked or "protected" at all anymore.

The best guess I have about this is because in the new configuration my wan interface em0 is missing, see the attached screenshots.

Any ideas?

Hi,

like some others, I have also been bitten by the realtek driver issue. Before upgrading to 22.1, I read the announcement that the vendor driver had been dropped in favor of the original FreeBSD variant and that I should have a look, if the FreeBSD driver supported my NIC. Here's what the release announcement says https://forum.opnsense.org/index.php?topic=26536.0:

The Realtek vendor driver is no longer bundled with the updated FreeBSD kernel.  If unsure whether FreeBSD 13 supports your Realtek NIC please install the os-realtek-re plugin prior to upgrading to retain operability of your NICs.

And so I did, I verified that my NICs were supported by the vanilla FreeBSD driver and so I decided that using the os-realtek-re drivers was not necessary and instead I gave the FreeBSD drivers a try.

Code Select Expand

re0@pci0:2:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
re1@pci0:3:0:0: class=0x020000 rev=0x0c hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet


Unfortunately, like some others have noticed, too, the FreeBSD driver would work for a while but then just drop all connections, constantly toggling between UP to DOWN state.

So at least from my POV, it might be a good idea to tell people that checking if the vanilla FreeBSD realtek driver supports a NIC or not is not sufficient and that things may break randomly any time later.

And if I could choose, I'd rather stick with the os-realtek-re vendor driver for the time being, until it is clear, which NICs are not only (allegedly) supported but also known to be working with the vanilla FreeBSD driver.

From time to time, the captive portal stops to work and the log show this:

Code Select Expand

Traceback (most recent call last): File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/cp-background-process.py", line 207, in main bgprocess.db.cleanup_sessions() File "/usr/local/opnsense/scripts/OPNsense/CaptivePortal/lib/db.py", line 403, in cleanup_sessions """) sqlite3.DatabaseError: database disk image is malformed

This seems to have been an issue occurring for a long time, see https://forum.opnsense.org/index.php?topic=12843.0 for example.

The solution laid out there is pretty brute force, however. Instead of deleting the database altogether and losing all session and state information, the right way to do it is to simply repair the database:

1. stop the captive portal
2. move away the broken database

Code Select Expand

mv /var/captiveportal/captiveportal.sqlite /var/captiveportal/captiveportalbad.sqlite
3. recover the database

Code Select Expand

sqlite3 /var/captiveportal/captiveportalbad.sqlite ".recover" | sqlite3 /var/captiveportal/captiveportal.sqlite

I just noticed, that the firewall stopped logging after I upgraded on of our firewalls to the latest 20.1 version (OPNsense 20.1.9_1-amd64) some weeks ago.

Neither the live view nor the plain view show new log data, only data from before the upgrade.

Any ideas what how to debug the issue appreciated :)

Hi,

I run OPNsense 20.1 in a proxmox 6.1 virtualized environment on a GA-IMB310TN mainboard with two on board Intel NICs.

Unfortunately, my WAN download speed refused to exceed 12 or 13Mbit, usually it was even lower, despite my 200Mbit uplink speed.

I've tried a lot of things, changing drivers from virtio to e1000e, PCI passthru of the physical NIC, FreeBSD tuning guides and a lot more, all to no avail.

After days of trial and error testing I finally found a solution, maybe it will help someone in the same situation:

The trick is to disable hardware checksum offload and hardware TCP segmentation offload on the physical linux (=proxmox) side as well.

This can be done by changing the WAN bridge configuration in /etc/network/interfaces in proxmox like this:

Code Select Expand

auto vmbr1
iface vmbr1 inet manual
        bridge_stp off
        bridge_fd 0
        bridge_ports eno1
        pre-up ethtool -G eno1 rx 1024 tx 1024
        pre-up ethtool -K eno1 tx off gso off
        post-up ethtool -K vmbr1 tx off gso off
#uplink

As you see, the settings are made both for the bridge vmbr1 and the physical device eno1. The eno1 NIC is a Intel Corporation Ethernet Connection (7) I219-V, controlled by the e1000e driver. No idea if the same applies to other hardware, too. To be honest, I've actually never had a problem like this even though I have virtualized a lot of OPNsense installations.

All the credits for this nice workaround go to this subreddit: https://www.reddit.com/r/PFSENSE/comments/842unp/having_an_issue_with_virtualized_pfsense_speeds/

Cheers

I've an issue that has bothering me for quite some time, and each time I thought it had been solved by some update, it reappears again. So maybe someone here can shed a little light on my problem.

OPNsense is connected to the internet using a Netgear LB1110 4G LTE Modem, which is configured for bridge mode, so OPNsense gets a routeable, public IP address via DHCP from the ISP.

Now, from time to time OPNsense loses internet connectivity and marks the gateway as "offline" in System->Gateways->Single

At the same time, if I look at Interfaces->Overview->WAN interface, I see that both status and DHCP are "up".

My first idea was an issue with gateway monitoring, and so I checked in System->Gateways->Single, if "Disable Gateway Monitoring" was active, but it was not and I see dpinger up and running. I've also entered a dedicated "Monitor IP", but to no avail.

I can manually "fix" the situation by either releasing or renewing the DHCP connection in Interfaces->Overview->WAN interface, but manual intervention is the last resort.

I've hacked together a simple cronjob checking connectivity every minute and restart the DHCP connection, if the connection goes down, but I really hope there's a better solution to this :)

Ah yes, and this currently happens on a 19.1.6 installation, but it has also happened previously, IIRC with 18.x versions, too.

Any ideas?

Hi,

after an upgrade from 16.1.6 to the latest production 16.1.9 release (that is from squid 3.5.15 to 3.5.16), our previously working transparent squid proxy refuses to work.

All transparent HTTP traffic is answered by an "Access denied" page from squid and the access.log shows this:

Code Select Expand

==> /var/log/squid/access.log <==
1460469079.970      0 127.0.0.1 TCP_DENIED/403 4946 GET http://www.example.com - HIER_NONE/- text/html
1460469079.971      2 172.25.1.1 TCP_MISS/403 5041 GET http://www.example.com - ORIGINAL_DST/127.0.0.1 text/html

When accessing squid explicitly by configuring a proxy, it works:

Code Select Expand

==> /var/log/squid/access.log <==
1460469599.113    126 172.25.1.1 TCP_MISS/304 249 GET http://www.example.com - HIER_DIRECT/93.184.216.34 -

If I try to access squid's intercept port directly from the firewall, the same is logged:

Code Select Expand

% telnet localhost 3128
root@theseus:/var/log # telnet localhost 3128
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET HTTP://www.example.com HTTP/1.0

HTTP/1.1 403 Forbidden
Server: squid
Mime-Version: 1.0
Date: Tue, 12 Apr 2016 14:02:38 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3411
X-Squid-Error: ERR_ACCESS_DENIED 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from localhost
X-Cache-Lookup: NONE from localhost:3128
Via: 1.1 localhost (squid)
[...]

Even if I manually add "http_access allow all" to squid.conf, localhost is still denied access ...

Nothing fancy about the setup, it has worked for some months now.

squid says this about its configuration (obfuscated the IP addresses a bit :) )

Code Select Expand

% squid -k parse
2016/04/12 16:09:49| Startup: Initialized Authentication Scheme 'basic'
2016/04/12 16:09:49| Startup: Initialized Authentication Scheme 'digest'
2016/04/12 16:09:49| Startup: Initialized Authentication Scheme 'negotiate'
2016/04/12 16:09:49| Startup: Initialized Authentication Scheme 'ntlm'
2016/04/12 16:09:49| Startup: Initialized Authentication.
2016/04/12 16:09:49| Processing Configuration File: /usr/local/etc/squid/squid.conf (depth 0)
2016/04/12 16:09:49| Processing: http_port 127.0.0.1:3128 intercept
2016/04/12 16:09:49| Starting Authentication on port 127.0.0.1:3128
2016/04/12 16:09:49| Disabling Authentication on port 127.0.0.1:3128 (interception enabled)
2016/04/12 16:09:49| Processing: http_port [::1]:3128 intercept
2016/04/12 16:09:49| Starting Authentication on port [::1]:3128
2016/04/12 16:09:49| Disabling Authentication on port [::1]:3128 (interception enabled)
2016/04/12 16:09:49| Processing: http_port 172.25.1.250:3128
2016/04/12 16:09:49| Processing: acl ftp proto FTP
2016/04/12 16:09:49| Processing: http_access allow ftp
2016/04/12 16:09:49| Processing: acl localnet src 172.25.1.0/24 # Possible internal network
2016/04/12 16:09:49| Processing: acl localnet src fc00::/7       # RFC 4193 local private network range
2016/04/12 16:09:49| Processing: acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
2016/04/12 16:09:49| Processing: acl subnets src 172.25.1.0/24
2016/04/12 16:09:49| Processing: acl subnets src 127.0.0.0/24
2016/04/12 16:09:49| Processing: acl unrestricted src 172.25.1.0/24
2016/04/12 16:09:49| Processing: acl SSL_ports port 443 # https
2016/04/12 16:09:49| Processing: acl Safe_ports port 80 # http
2016/04/12 16:09:49| Processing: acl Safe_ports port 21 # ftp
2016/04/12 16:09:49| Processing: acl Safe_ports port 443 # https
2016/04/12 16:09:49| Processing: acl Safe_ports port 70 # gopher
2016/04/12 16:09:49| Processing: acl Safe_ports port 210 # wais
2016/04/12 16:09:49| Processing: acl Safe_ports port 1025-65535 # unregistered ports
2016/04/12 16:09:49| Processing: acl Safe_ports port 280 # http-mgmt
2016/04/12 16:09:49| Processing: acl Safe_ports port 488 # gss-http
2016/04/12 16:09:49| Processing: acl Safe_ports port 591 # filemaker
2016/04/12 16:09:49| Processing: acl Safe_ports port 777 # multiling http
2016/04/12 16:09:49| Processing: acl CONNECT method CONNECT
2016/04/12 16:09:49| Processing: icap_enable off
2016/04/12 16:09:49| Processing: auth_param basic program /usr/local/etc/inc/squid.auth-user.php
2016/04/12 16:09:49| Processing: auth_param basic realm OPNsense proxy authentication
2016/04/12 16:09:49| Processing: auth_param basic credentialsttl 2 hours
2016/04/12 16:09:49| Processing: auth_param basic children 5
2016/04/12 16:09:49| Processing: acl local_auth proxy_auth REQUIRED
2016/04/12 16:09:49| Processing: http_access allow unrestricted
2016/04/12 16:09:49| Processing: http_access deny !Safe_ports !unrestricted
2016/04/12 16:09:49| Processing: http_access deny CONNECT !SSL_ports !unrestricted
2016/04/12 16:09:49| Processing: http_access allow localhost manager
2016/04/12 16:09:49| Processing: http_access deny manager
2016/04/12 16:09:49| Processing: http_access deny to_localhost
2016/04/12 16:09:49| Processing: http_access allow local_auth
2016/04/12 16:09:49| Processing: http_access allow localnet
2016/04/12 16:09:49| Processing: http_access allow localhost
2016/04/12 16:09:49| Processing: http_access allow subnets
2016/04/12 16:09:49| Processing: http_access deny all
2016/04/12 16:09:49| Processing: cache_mem 256 MB
2016/04/12 16:09:49| Processing: cache_dir ufs /var/squid/cache 1024 16 256
2016/04/12 16:09:49| Processing: coredump_dir /var/squid/cache
2016/04/12 16:09:49| Processing: refresh_pattern ^ftp: 1440 20% 10080
2016/04/12 16:09:49| Processing: refresh_pattern ^gopher: 1440 0% 1440
2016/04/12 16:09:49| Processing: refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
2016/04/12 16:09:49| Processing: refresh_pattern . 0 20% 4320
2016/04/12 16:09:49| Processing: cache_store_log /var/log/squid/store.log
2016/04/12 16:09:49| Processing: httpd_suppress_version_string on
2016/04/12 16:09:49| Processing: uri_whitespace strip
2016/04/12 16:09:49| Processing: forwarded_for transparent
2016/04/12 16:09:49| Processing: logfile_rotate 0
2016/04/12 16:09:49| Processing: visible_hostname localhost
2016/04/12 16:09:49| Processing: cache_mgr admin@localhost.local
2016/04/12 16:09:49| Initializing https proxy context

Not sure how to fix this now, the "best" I could find was this old thread about openbsd & squid http://comments.gmane.org/gmane.os.openbsd.misc/205257 talking about using "divert-to" instead of "rdr-to", but that doesn't sound very probable ...