Topics

1

24.7 Production Series / renewed user certificates are not (visibly) linked to the users anymore

« on: November 24, 2024, 04:08:03 pm »

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

2

High availability / HA when OPNsense also acts as a WAN router

« on: December 20, 2023, 03:56:28 pm »

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?

3

Virtual private networks / OpenVPN peer2peer broken after update to 23.7.5

« on: October 07, 2023, 11:24:00 am »

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]

<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]

<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]

# /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?

4

Zenarmor (Sensei) / zenamor missing wan interface em0 (and not blocking anything anymore)

« on: September 29, 2023, 09:45:16 am »

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?

5

22.1 Legacy Series / bring back the vendor realtek driver

« on: January 30, 2022, 01:09:44 pm »

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]

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.

6

Tutorials and FAQs / Captive Portal: how to recover a broken database

« on: December 10, 2020, 10:24:43 pm »

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

Code: [Select]

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]

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

Code: [Select]

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

7

20.1 Legacy Series / firewall stopped logging after upgrade

« on: November 03, 2020, 10:32:55 pm »

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

8

Hardware and Performance / [SOLVED] slow network performance with OPNsense on proxmox and e1000e NIC

« on: March 30, 2020, 09:53:31 pm »

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]

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

9

19.1 Legacy Series / gateway marked as "offline" but DHCP client claims to be "up"

« on: June 15, 2019, 01:50:50 pm »

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?

10

16.1 Legacy Series / [SOLVED] squid transparent proxy: 127.0.0.1 TCP_DENIED/403

« on: April 12, 2016, 04:23:17 pm »

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]

==> /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]

==> /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]

% 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]

% 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 ...