Topics

Hi,

are there any issues with repositories? Neither I get the announced 20.1.6 version, nor any plugins.

Either I get timeouts for repositories or the message that no updates are available.

Beside the updates, I should install a plugin, but the plugin list is completely empty. Even installed ones are  not listed. I tried 'pkg update -f' then I got at least the installed ones as 'orphaned'.

But no chance to install any new plugins. How can I manually install plugins, since my update mechanism seems to be broken on both ha members?

What is the trick to get caching in NGINX active?

I created a cache folder:

Code Select Expand

proxy_cache_path /var/cache/lighttpd levels=1:2 keys_zone=209ab9ff8560484caaf081f8bcac9c2d:10m max_size=1g inactive=10m use_temp_path=off;

(lighthttpd runs as same www user like nginx, rights should fit and folder already existed)

I added caching to location:

Code Select Expand

location  / {
    SecRulesEnabled;
    LearningMode;
    BasicRule wl:19;
    CheckRule "$policy4434ab68a29c40a2ba8165bb0152726b >= 8" BLOCK;
    CheckRule "$policye1e33beefff64c3aac540aa206da52c4 >= 8" BLOCK;
    CheckRule "$policy005d90775be94cdfb326ff4249e5c949 >= 8" BLOCK;
    CheckRule "$policy6dbf193648204b3f9da750d19b0dfd14 >= 8" BLOCK;
    CheckRule "$policy30b8fbbed9854f1eb42a19353326f25e >= 8" BLOCK;
    CheckRule "$policy9c0c9f9ad1b44a52b52ca20418d980dc >= 8" BLOCK;
    DeniedUrl "/waf_denied.html";
    autoindex off;
    http2_push_preload on;
    proxy_set_header Host $host;
    proxy_cache 209ab9ff8560484caaf081f8bcac9c2d;
    proxy_cache_use_stale  error timeout invalid_header updating http_429 http_500 http_502 http_503 http_504;
    proxy_cache_min_uses 10;
    proxy_cache_background_update on;
    proxy_cache_lock on;
    proxy_cache_revalidate on;
    proxy_cache_methods GET HEAD;
    proxy_set_header X-TLS-Cipher $ssl_cipher;
    proxy_set_header X-TLS-Protocol $ssl_protocol;
    proxy_set_header X-TLS-SNI-Host $ssl_server_name;
    # proxy headers for backend server
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-TLS-Client-Intercepted $tls_intercepted;
    proxy_ignore_client_abort off;
    proxy_request_buffering on;
    proxy_max_temp_file_size 1024m;
    proxy_buffering on;
    proxy_pass http://upstreambcd9e05221ad4fb3852fb408c4fe5030;
    proxy_hide_header X-Powered-By;
    proxy_hide_header Referrer-Policy;
    proxy_hide_header X-XSS-Protection;
    proxy_hide_header X-Content-Type-Options;
    proxy_hide_header Strict-Transport-Security;
    proxy_hide_header Content-Security-Policy;
    proxy_hide_header Content-Security-Policy-Report-Only;

}


The caching directory stays empty. :-(

Till version 19.x I had the same VHID for ipv4 and ipv6 addresses on same interface, so that in a case of failover both address families failover.

Since opnsense version 20.x you are forced to use different VHIDs for ipv4 and ipv6 on same interface. Today I triggered a failover (temporarly disable carp) and while all ipv4 addresses on backup node moved to MASTER, the ipv6 addresses kept BACKUP.

Any ideas why? Else I would have to manually edit the config.xml to have same VHIDs again, since gui prevents this since 20.x.

Hi all,

I created some dashboards with 19.x series in a 3col layout and had some widgets spanning three columns. Now with 20.1 I wanted to rearange existing ones and add new widgets, but I do not manage any more to span more columns?
Was there anything changed, so that only 1col widgets are possible or is there a trick to do multi cols?

I checked config.xml and did not find any special tag that seems to handle col layout. But when I restore dashboard from old config, I can restore my old multo-col layouts. So where does it determine how many cols to span? Then I could at least hack it via config.xml.

Any hints?

I run a transparent squid proxy on 19.7.5_5 (80, 443 redirected to localhost 3128, 3129).

Everything is working: Traffic intercepted, redirected to localhost proxy, processed and clients browse without additional settings.

The only issue are the log entries which are generated and rise the impression that traffic is blocked which is actually not the case:

Log entry:

Code Select Expand


StudentsNet Oct 24 08:23:18 10.1.0.241:63039 127.0.0.1:3129 tcp Default deny rule


I tested traffic, ports and logs. Everything works and for users no problems, except these deny rules flooding logs.

Port forward:

Code Select Expand

GRPStudents TCP GRPStudents net Port_unprivileged  * 80 (HTTP) 127.0.0.1 3128 redirect traffic to local proxy
GRPStudents TCP GRPStudents net Port_unprivileged  * 443 (HTTPS) 127.0.0.1 3129 redirect traffic to local proxy

Associated rules:

Code Select Expand

IPv4 TCP GRPStudents net Port_unprivileged  127.0.0.1 3128 * * NAT redirect traffic to local proxy (IPv4)
IPv4 TCP GRPStudents net Port_unprivileged  127.0.0.1 3129 * * NAT redirect traffic to local proxy (IPv4)

GRPStudents is an interface group, consisting of three interfaces.

Hallo!

Ich habe mehrere Netzwerke, die durch verschiedene Gateways verbunden sind. Einige Gateways befinden sich im selben Subnetz, leiten jedoch zu anderen Subnetzen weiter.

Jetzt habe ich z. B. Gateway A (192.168.1.254) im Subnetz 192.168.1.0/24 und wird für drei Routen als Ziel verwendet:

• 10.10.1.0/24 -> 192.168.1.254
• 10.10.2.0/24 -> 192.168.1.254
• 10.10.3.0/24 -> 192.168.1.254

Sobald ich Gateway B (192.168.1.10) hinzufüge, das sich ebenfalls im Subnetz 192.168.1.0/24 befindet, übernimmt es alle Routen von Gateway A. Ich habe noch nicht einmal die Route für Gateway B hinzugefügt, aber sobald es hinzugefügt wird, wird mein Routing ist beschädigt.

Das Merkwürdige ist die Routingtabelle: netstat -rn wird nicht geändert. Gateway A (192.168.1.254) wird weiterhin als Gateway angezeigt. Bei einer Traceroute wird jedoch Gateway B verwendet.
Als nächsten Schritt habe ich einen Linux-PC mit 192.168.1.100 als 2. Gateway hinzugefügt und tcpdump ausgeführt. Und wieder übernimmt der 192.168.1.100 alle Routen von Gateway A und tcpdumps zeigt den Routing-Verkehr an, der zum Linux-PC gelangt.

Gibt es eine Shadow-Routing-Tabelle, die beim Hinzufügen eines Gateways im selben Subnetz wie ein Vorhandenes überschrieben wird? Für mich war netstat -rn der einzige Ort für Routen. Nur Einträge in dieser Tabelle werden verwendet, aber jetzt habe ich eine Situation in der diese Routingtabelle nicht mit der effektiv verwendeten übereinstimmt.

Handelt es sich um einen FreeBSD-Bug oder welche Befehle werden beim Hinzufügen / Löschen / Aktivieren / Deaktivieren eines Gateways ausgegeben?

Normalerweise sollte es kein Problem mit Gateways im selben Subnetz und einer Routing-Tabelle wie dieser geben:

• 10.10.1.0/24 -> 192.168.1.254
• 10.10.2.0/24 -> 192.168.1.254
• 10.10.3.0/24 -> 192.168.1.254
• 10.20.3.0/24 -> 192.168.1.10

Hi!

I have running several networks, connected by various gateways. Some gateways resist in the same subnet, but each routes to other subnets.

Now I have e.g. gateway A (192.168.1.254) in subnet 192.168.1.0/24 used as destination in three routes:

• 10.10.1.0/24 --> 192.168.1.254
• 10.10.2.0/24 --> 192.168.1.254
• 10.10.3.0/24 --> 192.168.1.254

As soon as I add gateway B (192.168.1.10) also located in subnet 192.168.1.0/24, it takes over all routes of gateway A. I did not even add the route for gateway B, but as soon as it gets added, my routing is damaged.

The strange thing is the routing table: netstat -rn is not changed. Gateway A (192.168.1.254) is still shown as gateway. But when doing a traceroute, gateway B is used.
I a next step, I added a linux pc with 192.168.1.100) as 2nd gateway and run tcpdump. And again, the 192.168.1.100 takes over all routes of gateway A and tcpdumps shows the routing traffic getting into the linux pc.

Is there a shadow routing tables that gets overwritten when adding a gateway in the same subnet as an existing one? For me netstat -rn was the only place for routes. Entries in this table are used, but now I have a situation where this routing table is not in sync with the effective used one.

Is this a FreeBSD bug or what commands are issued when adding/deleting/enabling/disabling a gateway?

Usually it should no problem with gateways in same subnet and a routing table like this:

• 10.10.1.0/24 --> 192.168.1.254
• 10.10.2.0/24 --> 192.168.1.254
• 10.10.3.0/24 --> 192.168.1.254
• 10.20.3.0/24 --> 192.168.1.10

Hello,

in 19.7.2 there was this hint:

Code Select Expand

system: fix writing gateway information for DNS servers

I hoped this would solve my problem with icmp redirects, but instead of just one dns added to gateway list, all dns are now added to gateway list.
For the dns server in far subnets routed anyway via gateway this will not be a problem, but why add a gateway entry for a dns server in the same layer 2 subnet? Instead of sending direct on link/wire, the dns requests are sent to the local router and it returns icmp redirect messages, since the packet could/should go directly.

After every reboot, I have to delete this host route.

Could you please fix this and stop creating host routes for dns servers on the same subnet as a direct attached interface?

Thanks.

I have to reopen this issue: https://forum.opnsense.org/index.php?topic=5988.0

New 19.1.6 installation, plugins clamav and c-icap installed. Even when I try this timing delay, I get error when starting c-icap.

Code Select Expand

root@fw01:/var/log/c-icap # /usr/local/etc/rc.d/clamav-clamd start
Starting clamav_clamd.
WARNING: Ignoring deprecated option AllowSupplementaryGroups at /usr/local/etc/clamd.conf:14
root@fw01:/var/log/c-icap # sleep 5
root@fw01:/var/log/c-icap # /usr/local/etc/rc.d/c-icap restart
c_icap not running? (check /var/run/c-icap/c-icap.pid).
Starting c_icap.


/var/log/c-icap/server.log

Code Select Expand

Fri Apr 26 13:11:58 2019, main proc, clamd_init: Not valid response from server:
Fri Apr 26 13:11:58 2019, main proc, Registry 'virus_scan::engines' does not exist!
Fri Apr 26 13:12:18 2019, 41119/689028864, Registry 'virus_scan::engines' does not exist!
Fri Apr 26 13:12:18 2019, 41119/689028864, Registry 'virus_scan::engines' does not exist!
Fri Apr 26 13:13:08 2019, 41119/689028864, Registry 'virus_scan::engines' does not exist!
Fri Apr 26 13:13:08 2019, 41119/689028864, Registry 'virus_scan::engines' does not exist!
Fri Apr 26 13:14:00 2019, 41119/689028864, Registry 'virus_scan::engines' does not exist!
Fri Apr 26 13:14:00 2019, 41119/689028864, Registry 'virus_scan::engines' does not exist!


Since no connection to clamav, all eicar downloads pass.

My live log stopped, filter.log is empty and I have no idea how to get it working again.

I checked and uncheck the "Log Firewall Default Blocks" rules, reset/cleared all logs, rebooted, added the log option to nearly every rule, but no entries in live view, overview or plain view. filter.log stays empty.

Tried also:
https://forum.opnsense.org/index.php?topic=9542.0

Did not help either

My current workaround is:

Code Select Expand

#  tcpdump -n -e -ttt -i pflog0

So, pflog0 interface is working. What component is between pflog0 and live view?

filterlog and syslog are running:

Code Select Expand

55019  -  Ss     0:00.05 /usr/local/sbin/filterlog -i pflog0 -p /var/run/filterlog.pid
60021  -  Ss     0:00.10 /usr/local/sbin/syslogd -s -c -c -P /var/run/syslog.pid -l /var/dhcpd/var/run/log -l /var/unbound/var/run/log -f /var/etc/syslog.conf


System is a fresh installation with 19.1.4 updated to 19.1.6. No mods in file system have been done, just configurations via web gui for interfaces and carp. Now I wanted to start adding rules and boom ... no logs to check.

[Update]

I am just setting up a new ha cluster. Added many interfaces and configured the CARP.

Now I finally reached the stage where I can set up rules. For installation I added a temporary allow all rules which I already removed and replaced with more granular ones.

I wondered why everything is still possible and the redirect to proxy is not triggered.

Now I made a

Code Select Expand

pfctl -sr and I just see my old temporary allow all rule. No matter what I do, the rules in gui are not applied to pf. Any known new issues in 19.1.6? How can I force the gui to sync rules to pf?

Update
Rebooted machine and now: no rules at all.

Code Select Expand

#pfctl -sr

Code Select Expand

#pfctl -sn

is empty  :(

Usually when I check uptime and my ssh sessions I just use w to displaythis information.

Now I did a fresh install with 19.1.4 and upgraded to 19.1.6.

When I now check sessions, I get many virtual tty-sessions (7). I edited /etc/ttys and disabled virtual ttys, but after reboot /etc/ttys is restored and all virtuall ttys are present again.

19.1.6

Code Select Expand


11:17AM  up 17:38, 10 users, load averages: 0.90, 0.74, 0.69
USER       TTY      FROM                                      LOGIN@  IDLE WHAT
admin      pts/0    nb-mn01                                  11:17AM     - w
root       v1       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       v5       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       v2       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       v3       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       v0       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       v6       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       v7       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       u0       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell
root       v4       -                                        Tue05PM 17:34 /bin/sh /usr/local/sbin/opnsense-shell


I checked my older opnsense installations (19.1.4) and there virtual ttys are also enabled in /etc/ttys, but finally there is just one v0 session.

19.1.4

Code Select Expand


11:20AM  up 9 days,  2:18, 2 users, load averages: 0.66, 0.76, 0.73
USER       TTY      FROM                                      LOGIN@  IDLE WHAT
admin      pts/0    nb-mn01                                  11:20AM     - w
root       v0       -                                        08Apr19 5days -


Is there any chance to revert 19.1.6 behaviour to just one tty session?

Since my suricate is completely silent and I have no alerts, I took a look at the rules. Now I see that some rules are emtpy:

Code Select Expand

-rw-r-----  1 root  wheel       58 Mar 20 09:47 botcc.portgrouped.rules
-rw-r-----  1 root  wheel       58 Mar 20 09:47 botcc.rules
-rw-r-----  1 root  wheel       58 Mar 20 09:47 drop.rules
-rw-r-----  1 root  wheel       58 Mar 20 09:47 dshield.rules
-rw-r-----  1 root  wheel       58 Mar 20 09:47 tor.rules

The only content is a 58 bytes hash-string like:

#@opnsense_download_hash:8885524e8c925b9882c4602c9e517e2a

The curious thing is the tor ruleset. Before I upgraded to ET Pro telemetry edition and used the free rules, I got tor alerts. So I assume it has not been that empty before.

[Problem]

Problem

The default OPNsense auto proxy configuration is designed to work best with plain http (port 80). As soon as you use port redirect to https (443) you will run into problems, since

• some auto proxy configurations mechanism rely on http
• you may run into certificate issues (self-signed) with https

The best option is to provide wpad.dat via http, so you can even restrict your web gui port just to your admin pcs.

How to configure

• redirect your web gui to https or other port
• restrict this port to your admin pcs
• install nginx web server

Configure nginx

• Nginx: Configuration --> HTTP(S) --> Location




• Description: WPAD
• URL pattern: wpad.dat
• Match type: Excact match("=")
• File system root: /usr/local/www


• Nginx: Configuration --> HTTP(S) --> HTTP server
  
  
  
  
  • Listen port: 80
  • Server name : localhost
  • Location: WPAD
  • File system root: /usr/local/www
  
  


• Nginx: Configuration --> General settings




• Enable nginx: enabled

Now nginx will listen on port 80 and provide the original wpad.dat file created via gui.

DHCP and Unbound provide gui options to enable WPAD support, but these options will (partitual) create configuration entries that point to your (inaccessible) web gui port. So we have to add those option manually instead.

Configure DHCP service

• Services: DHCPv4: [Interface]
  
  
  
  
  • WPAD: unchecked
  • Additional Options:
    
    
    
    • Number: 252
    • Type: text
    • Value: http://[interface-ip]/wpad.dat

Configure Unbound
The A and AAAA records would already be right with the WPAD option, since these records cannot provide ports anyway, but there are also TXT records with port entries created that would be wrong. So we skip TXT records (not supported via gui) and just add A and AAAA records.

• Services: Unbound DNS: General
  
  
  
  
  • Advanced: Show advanced options
  • WPAD Records: unchecked
    
    
• Services: Unbound DNS: Overrides
  
  
  
  
  • Host: wpad
  • Domain: your [interface-domain]
  • Type: A or AAAA
  • IP: [interface ip]

Configure firewall
Add a rule that allows [interface net]:1024-65535 --> This firewall:80

With this configuration clients should be able to acquire either via DNS or DHCP a valid proxy configuration via port http (80).

Anybody else having issues with ldap as authentication server and using encrypted connections?

I made the update to 19.7.3 this morning and ldap with startTLS worked. After upgrade no authentication possible any more. I also tried SSL but neither works.

Changelog:

system: improve LDAPS mode and related authentication cleanups

opnsense: Could not startTLS on ldap connection [error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get issuer certificate),Connect error]

Edit:
Changed from StartTLS to SSL and vice versa. Changed hostnames of ldap from subjectAlternative to main and back. Everything configured like before.

I do not know why, but now it works again. Very strange. All certificates in chain had been imported. Else I would say a cache has been deleted during upgrade and certificates got just fetched by a cron during my tests.

Hi,

I want to migrate from quite old cisco concentrator  ::) to OPNsense. My problem are the multiple clients groups.
Cisco is configured for three road warrior groups, each with own PSK.

Per default OPNsense only allows one mobile client configuration. Via manual duplication of phase1 block in config.xml and restoring the modded version, I was able to setup more mobile clients. Each one has its own PSK.

But unfortunatelly it will not work. Only the last phase 1 entry is working. I already tried to modify ipsec.secrets and replaced WAN ip with %any or %any6.

Matching IDs with selectors is fairly straightforward: they have to be equal. In the case of a Road Warrior connection, if an equal match is not found for the Peer's ID, and it is in the form of an IP address, a selector of %any will match the peer's IP address if IPV4 and %any6 will match a the peer's IP address if IPv6. Currently, the obsolete notation 0.0.0.0 may be used in place of %any.
When using IKEv1 an additional complexity arises in the case of authentication by preshared secret: the responder will need to look up the secret before the Peer's ID payload has been decoded, so the ID used will be the IP address.

It does not seem that all PSKs are tried up-down to find the fitting one. But since road warriors have dynamic ips, I have to use %any/%any6.

Any ideas how to fix this?

Hi all!

Since OPNsense provides many possibilities to filter traffic, I wonder which method is the best, less performance consuming one and maybe user friedly one. I do not think that you have to use every method because filtering lists/results maybe redundant.

Filtering methods:

• Firewall and blocklist as URL Table (applies to every traffic)
• Squid proxy with remote ACL (applies to proxied webtraffic)
• Bind and DNSBL/RPZ (applies to FQDN)
• OpenDNS (applies to FQDN)
• Suricata IPS (applies to every traffic)
• Sensei (applies to every traffic)

The first question is the layer/order/time when a method is applied. When I already block DNS, then clients will not request the resource and neither firewall, squid, IPS nor sensei will have to handle anything. But in this case, e.g. a web resource has been requested, the user will not know why his requests fails. If I had blocked via squid/sensei at least an info page would have been shown.
DNS blocking will not help if direct IPs are accessed. Damn! The more I think about it, you have to use at least some combinations to block everything.

What would you suggest to successfully block for example adware and tracker?

Dear all,

I cannot get ISC dhcpv6 to assign leases to clients.

• I assigned static ip6-address to interface (LAN)
• I set up an ip range (no prefix delegation)
• I activated RA for interface with assisted mode (defaults, dns from dhcp)

dhcpv6 is running

Code Select Expand


Nov 30 16:41:34 hbc-gw01 dhcpd: Listening on Socket/7/lagg0_vlan2058/2001:xxxx:xxxx:2058::/64
Nov 30 16:41:34 hbc-gw01 dhcpd: Sending on   Socket/7/lagg0_vlan2058/2001:xxxx:xxxx:2058::/64


the request is coming

Code Select Expand


#> tcpdump -i lagg0_vlan2058 ip6
16:42:17.470232 IP6 fe80::fd23:a211:46b2:7057.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
16:42:18.474917 IP6 fe80::fd23:a211:46b2:7057.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
16:42:20.480535 IP6 fe80::fd23:a211:46b2:7057.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
16:42:24.483401 IP6 fe80::fd23:a211:46b2:7057.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
16:42:32.483771 IP6 fe80::fd23:a211:46b2:7057.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
16:42:48.491134 IP6 fe80::fd23:a211:46b2:7057.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
16:43:20.499374 IP6 fe80::fd23:a211:46b2:7057.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit


The requests passes the rules (I had to disable the bogus network option, since ff02:: gets blocked by it)

Code Select Expand


LAN Nov 30 16:42:17 fe80::fd23:a211:46b2:7057 ff02::2 ICMPv6         IPv6 requirements (ICMP)
LAN Nov 30 16:42:17 [fe80::fd23:a211:46b2:7057]:546 [ff02::1:2]:547 UDP allow access to DHCPv6 server on LAN


But then no reply by server. I know ff00::8 is ip6-multicast, but since I sniff on fire wall interface directly and I get this request, no multcast security like mld snooping blocks it. The requests gets to my lagg0 interface on my firewall, but the dhcp server does not seem to reply.
There is no log entry about a lease and no reply paket.

Do you have any ideas, suggestions why this happens?

I have the same issue on a pfsense. Two interfaces work with dhcpv6 server, one won't (same settings on every interface, dhcp-server and vlan).

Now I migrate to opnsense and add the first network with ip6 - same issue. What am I doing wrong?