Topics

Hi there,

17.7.4 updates also unbound to new version 1.6.6. However, unbound is not restarted after the update so that still 1.6.5 is running - is this by intention?

Br br

Hello,

after having fixed so fast (thanks again Franco !!) the matter around apinger (see https://forum.opnsense.org/index.php?topic=6028.0), there is another new error message in my system.log, which seems to have on a first look a similar root cause:

Code Select Expand


OPNsense opnsense: /usr/local/etc/rc.newwanipv6: Removing static route for monitor fe80::3631:c4ff:XXXX:XXXX%igb1 via fe80::3631:c4ff:XXXX:XXXX
OPNsense opnsense: /usr/local/etc/rc.newwanipv6: Adding static route for monitor fe80::3631:c4ff:XXXX:XXXX%igb1 via fe80::3631:c4ff:XXXX:XXXX
OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route add -host -'inet6' 'fe80::3631:c4ff:XXXX:XXXX%igb1' 'fe80::3631:c4ff:XXXX:XXXX'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add host fe80::3631:c4ff:XXXX:XXXX%igb1: gateway fe80::3631:c4ff:XXXX:XXXX fib 0: Network is unreachable'


Could it be that the link local address of the default ipv6 gateway is not assigned to my WAN interface too for the adding the static route which would require some adoption of the rc.newwanipv6?

Looking forward to your reply

Br br

Hello together

after having updated to 17.7.3 from 17.1.11, I get the following error messages in the gateways.log file for the ipv6 gateway monitoring:

Code Select Expand


Could not bind socket on address(fe80::217:3fff:XXXX:XXXX) for monitoring address fe80::3631:c4ff:XXXX:XXXX(WAN_DHCP6) with error Can't assign requested address
OPNsense apinger: bind(): Can't assign requested address

Considering the /var/etc/apinger.conf, apinger sets the srcip to be the interface link-local address but it does not set the scope on the source IP or target, so apinger cannot reach the gateway.

Code Select Expand


target "fe80::3631:c4ff:XXXX:XXXX" {
  description "WAN_DHCP6"
  srcip "fe80::217:3fff:XXXX:XXXX"
        alarms override "loss","delay","down";
  rrd file "/var/db/rrd/WAN_DHCP6-quality.rrd"
}

The correct config should look (if e.g. igb1 is your WAN interface)

Code Select Expand


target "fe80::3631:c4ff:XXXX:XXXX%igb1" {
  description "WAN_DHCP6"
  srcip "fe80::217:3fff:XXXX:XXXX%igb1"
        alarms override "loss","delay","down";
  rrd file "/var/db/rrd/WAN_DHCP6-quality.rrd"
}

Have tried this out manually, with this config setting, the error message disappears.

As apinger restarts every 30 min. with a freshly written apinger.conf this needs to be included in the script generating the apinger.conf.

See also here: https://redmine.pfsense.org/issues/3969

Br br

Hello together,

after upgrade to 17.1.8 for what reasons ever, one of my interface is not accepting to get configured with a linkloca address:

Code Select Expand

OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/ifconfig igb3 inet6 fe80::1:1%igb3' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): File exists'

I have then the  following error messages in routing.log:

Code Select Expand


Jun  7 20:28:26 OPNsense radvd[54605]: received icmpv6 RA packet with non-linklocal source address from 2003:46:e954:26f2:XXX:XXXX:XXXX:XXXX
Jun  7 20:28:26 OPNsense rtsold[88234]: <rtsol_input> invalid RA with non link-local source from 2003:46:e954:26f2:XXX:XXXX:XXXX:XXXX on igb3


and in dmesg

Code Select Expand

ifa_maintain_loopback_route: insertion failed for interface igb3: 17


igb3 is one of my internal networks .... Mr. google is not really enlighting .....

What is the corrective measure to get rid of these messages? RA on all other internal interfaces works and they also get an link local address  :-\

Thanks ...

br br

Hello together,

I am facing since the migration to 17.1 the phenomenon that about all 3-4 weeks my system out of the sudden simply HALTS. No Logs, no message on the console, no crash report.  As I saw a few others who are at least from their writing being in a similar situation (with perhaps different root cause), I would like to ask how we could analyze this further. (are there any additional debug option I could activate et al)

Phenomenologically, I observe a random service stop in three classes:

• In the first class, router advertising for ipv6 stops (once about every three days)
• In the second class, the WAN interface goes down (once all 10 days)
• a complete system HALT (once all three weeks, without any hints on console or logs)

Must not necessarily correlate but could.

The following phenomenons are then observed when these events happen:

1.) Dashboard does not show suddenly any valid IPv6 addresses on the interfaces and ipv6 to the outside does not work ... radvd still running according to process table, wireshark does not show any RA packets anymore on the interfaces.

2.) WAN interface down:

Code Select Expand


Apr 25 22:21:00 OPNsense opnsense: /usr/local/etc/rc.filter_configure: Could not find IPv6 gateway for interface(wan).
Apr 25 22:21:00 OPNsense opnsense: /usr/local/etc/rc.filter_configure: Could not find IPv6 gateway for interface(wan).
Apr 25 22:22:59 OPNsense kernel: igb1: Watchdog timeout -- resetting
Apr 25 22:22:59 OPNsense kernel: igb1: Queue(73303552) tdh = 718230942, hw tdt = 38012041
Apr 25 22:22:59 OPNsense kernel: igb1: TX(73303552) desc avail = 0,Next TX to Clean = 0
Apr 25 22:22:59 OPNsense kernel: igb1: link state changed to DOWN
Apr 25 22:22:59 OPNsense configd.py: [b7a4b9b8-7077-471d-b36b-88b921d53a20] Linkup stopping igb1
Apr 25 22:22:59 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Apr 25 22:23:00 OPNsense UNKNOWN[10427]: Exiting, sigterm or sigint received.
Apr 25 22:23:00 OPNsense UNKNOWN[10427]: sending stop adverts
Apr 25 22:23:00 OPNsense UNKNOWN[10427]: removing /var/run/radvd.pid
Apr 25 22:23:03 OPNsense kernel: igb1: link state changed to UP
Apr 25 22:23:03 OPNsense configd.py: [897d7623-e7c8-4e2d-bd7f-b1b2c1497d6e] Linkup starting igb1
Apr 25 22:23:03 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
Apr 25 22:23:03 OPNsense opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
Apr 25 22:23:03 OPNsense opnsense: /usr/local/etc/rc.linkup: Accept router advertisements on interface igb1
Apr 25 22:23:03 OPNsense opnsense: /usr/local/etc/rc.linkup: ROUTING: setting IPv4 default route to 192.168.2.1
Apr 25 22:23:04 OPNsense opnsense: /usr/local/etc/rc.linkup: The command '/sbin/route delete -inet 'default'' returned exit code '1', the output was 'route: route has not been found delete net default fib 0: not in table'
Apr 25 22:23:07 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting igb1.
Apr 25 22:23:07 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::217:3fff:febe:a21d) (interface: wan) (real interface: igb1).
Apr 25 22:23:10 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route delete -host 192.168.2.1' returned exit code '1', the output was 'route: route has not been found delete host 192.168.2.1 fib 0: not in table'
Apr 25 22:23:10 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route delete -host 8.8.8.8' returned exit code '1', the output was 'route: route has not been found delete host 8.8.8.8 fib 0: not in table'
Apr 25 22:23:10 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 192.168.2.1
Apr 25 22:23:10 OPNsense configd.py: [8d2bfedd-ecf1-403d-a361-aa63f27621ec] updating dyndns GW_WAN
Apr 25 22:23:11 OPNsense configd.py: [557139d3-e4f7-4dc3-b655-7e38388b6976] updating rfc2136 GW_WAN
Apr 25 22:23:11 OPNsense configd.py: [b519c996-1d03-49aa-9049-361ca6457316] Restarting ipsec tunnels
Apr 25 22:23:11 OPNsense configd.py: [6274acfb-b837-43fe-b148-788e960e93db] Restarting OpenVPN tunnels/interfaces GW_WAN
Apr 25 22:23:11 OPNsense configd.py: [4a6b68ba-78e4-4bb1-946e-847ee4f42255] Reloading filter
Apr 25 22:23:12 OPNsense configd.py: [f476d51c-71d5-47ef-93f6-2280408e2197] updating dyndns wan
Apr 25 22:23:13 OPNsense configd.py: [06014b09-7e86-4fb2-aa08-4e7ef3f51abe] updating rfc2136 wan
Apr 25 22:23:14 OPNsense opnsense: /usr/local/etc/rc.filter_configure: Could not find IPv6 gateway for interface(wan).
Apr 25 22:23:14 OPNsense opnsense: /usr/local/etc/rc.filter_configure: Could not find IPv6 gateway for interface(wan).
Apr 25 22:23:15 OPNsense configd.py: [9c8020e5-c3aa-44a3-91c2-6e4858bf2214] Reloading filter
Apr 25 22:23:18 OPNsense opnsense: /usr/local/etc/rc.filter_configure: Could not find IPv6 gateway for interface(wan).
Apr 25 22:23:18 OPNsense opnsense: /usr/local/etc/rc.filter_configure: Could not find IPv6 gateway for interface(wan).

Also here, WAN (igb1) needed to be restarted manually , traffic was not possible (neither ipv4 nor v6).

3.) System HALT: No logs or console messages
No interaction possible anymore (ssh, console, BMC console, no system activity anymore (flashing disk LED); BMC heartbeat still working). A simple hard restart makes everything working again until the next time.

I would like to analyze this further but can not figure out the trigger why the router advertising stops or what triggers  the watchdog for the WAN interface. (although showing in the log that igb1 is restarting, it is NOT let traffic through afterwards and need to be restarted once again manually ....

Checked also Memory consumption over time and CPU load pattern - no finding

I am running out of ideas how to analyze further. Does somebody has any further idea? - looking forward to your reply

Br br

PS: This is also the reason for getting this solved  (https://forum.opnsense.org/index.php?topic=5019.0) to get a really fully working console ...

Hello all

After recent reboot, I enabled gateway monitoring of the ipv6 default gateway. I noticed that the gateway monitoring on the ipv6 side is shown with status 'pending' and later 'unknown'. Earlier posts did relate this to the apinger problem. my gateways.log holds a lot of messages like

Code Select Expand


Apr 19 13:07:49 OPNsense apinger: Starting Alarm Pinger, apinger(15864)
Apr 19 13:07:59 OPNsense apinger: Exiting on signal 15.

When I disable gateway monitoring on the IPv6 gateway then everything is displayed fine /ipv6 gateway has state online) ....

I am running opnsense behind a fritzbox with a 'read from interface' config ... I have a firewall rule in WAN allowing ICMPv6 traffic. Is there any other prerequisite to make ipv6 gateway monitoring work?

Thanks for your help

Br br

Hello all,

there is a known way how to change the keymap setting for the console in FreeBSD. This can obviously not 1:1 applied in opnsense, as /etc/login.conf is overwritten with each reboot. Selecting German in GUI does not affect keymaps in console !?

How can I use a german keyboard with the console then which survives reboot?

Thanks for your help

Br br

Hello all,

now already the second time in the last 7 days, I experienced a loss of the WAN interface - out of the sudden, system .log contains

Code Select Expand


Mar 31 07:44:51 OPNsense kernel: igb1: Watchdog timeout -- resetting
Mar 31 07:44:51 OPNsense kernel: igb1: Queue(73303552) tdh = 718230942, hw tdt = 38012041
Mar 31 07:44:51 OPNsense kernel: igb1: TX(73303552) desc avail = 0,Next TX to Clean = 0
Mar 31 07:44:51 OPNsense kernel: igb1: link state changed to DOWN
Mar 31 07:44:52 OPNsense configd.py: [2613750e-b422-4cd4-b3e7-af62c8e262a4] Linkup stopping igb1
Mar 31 07:44:52 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Mar 31 07:44:52 OPNsense UNKNOWN[95178]: Exiting, sigterm or sigint received.
Mar 31 07:44:52 OPNsense UNKNOWN[95178]: sending stop adverts
Mar 31 07:44:52 OPNsense UNKNOWN[95178]: removing /var/run/radvd.pid
Mar 31 07:44:55 OPNsense kernel: igb1: link state changed to UP
Mar 31 07:44:55 OPNsense configd.py: [95439359-bc6d-431b-8e0c-17a8ec6b78d8] Linkup starting igb1
Mar 31 07:44:55 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
Mar 31 07:44:55 OPNsense opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
Mar 31 07:44:56 OPNsense opnsense: /usr/local/etc/rc.linkup: Accept router advertisements on interface igb1
Mar 31 07:44:56 OPNsense opnsense: /usr/local/etc/rc.linkup: ROUTING: setting IPv4 default route to 192.168.X.X
Mar 31 07:44:56 OPNsense opnsense: /usr/local/etc/rc.linkup: The command '/sbin/route delete -inet 'default'' returned exit code '1', the output was 'route: route has not been found delete net default fib 0: not in table'
Mar 31 07:44:59 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: Informational is starting igb1.
Mar 31 07:45:00 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::XX:XX:XX:a21d) (interface: wan) (real interface: igb1).
Mar 31 07:45:02 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route delete -host 192.168.X.X' returned exit code '1', the output was 'route: route has not been found delete host 192.168.X.X fib 0: not in table'
Mar 31 07:45:02 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route delete -host 8.8.8.8' returned exit code '1', the output was 'route: route has not been found delete host 8.8.8.8 fib 0: not in table'
Mar 31 07:45:02 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 192.168.X.X

Despite it seems that WAN is tried to be restarted and reconfigured, traffic is not possible over WAN. Situation can only be fixed by manually restarting the WAN interface via GUI.

Any Idea How I could track this down further?

Looking forward t your reply

Br br

Hello all,

after observing the discussion a while I made today my upgrade from 16.7.14_2 to 17.1.2

Worked absolutely seamless, three reboots, overall upgrade time <6 minutes

Hardware: Supermicro X11SBA-LN4F
                Intel NX 3700 FPGA CPU
                4G RAM
                20G SATA 3G SSD Super Dome
                4 Gb NICS Intel Pro

There is one very irritating thing:console

My old installation uses UEFI. At the last reboot, the last output on the console is:

Code Select Expand


FreeeBSD/and64 EFI loader, revision 1.1
(root@sennsey64, Mon, Feb20, 13:09:03 CET 2017)
Loading /boot/defaults/loader.conf
|


Which means that there is no boot prompt coming up where I could put the suggested changes in console configuration as boot parameter.

Fortunately, the system comes up in the background normally and I could make the console setting changes via GUI. However, I would suggest to enable VGA console by default also for UEFI systems.

Furthermore, the upgrade installation also overwrites some config files, e.g. /etc/ttys which means in my case that if something goes wrong, there is no login prompt at the console (which I activate temporarily when doing installation work).

Aside from that - great work! Thanks to the OPNsense team!!

Br br

Hi there,

I am in big trouble as i have locked me out from opnsense completely:

I accidentially disabled the lan port in GUI and I do not get the console up an running (no login). What options do I have now to get access to the system and patch the setting for the LAN again? Where is this config stored?

Looking forward to your reply!

With despreate greetings

Br

Hello,

on my 16.1.18 I just noticed that my /var/log/routing.log is flooded with

Code Select Expand


Jul 21 19:12:28 OPNsense rtsold[15608]: <rtsol_input> received RA from fe80::1:1 on an unexpected IF(xn0)
Jul 21 19:12:29 OPNsense rtsold[15608]: <rtsol_input> received RA from fe80::1:1 on an unexpected IF(xn2)
Jul 21 19:12:29 OPNsense rtsold[15608]: <rtsol_input> received RA from fe80::1:1 on an unexpected IF(xn3)
Jul 21 19:12:34 OPNsense rtsold[15608]: <rtsol_input> received RA from fe80::1:1 on an unexpected IF(xn2)
Jul 21 19:12:36 OPNsense rtsold[15608]: <rtsol_input> received RA from fe80::1:1 on an unexpected IF(xn0)
Jul 21 19:12:38 OPNsense rtsold[15608]: <rtsol_input> received RA from fe80::1:1 on an unexpected IF(xn3)
Jul 21 19:12:41 OPNsense rtsold[15608]: <rtsol_input> received RA from fe80::1:1 on an unexpected IF(xn0)

I have a dual stack configured with Capture from WAN. tcpdump does not show any further RA in my networks

How can I get this away?

Br br

Hi together,

I have a 4 port OPNsense mit a WAN, LAN, DMZ and an additional port for a Management Network which shall have access to the Internet over the Port OPT2 (named WLAN here, see rules). The firewall rules on this interface are as attached.

Connected to this port OPT2 is a server with the address 192.168.88.11, Gateway is 192.168.88.1, the gateway to the internet is 192.168.2.1. The server has 2 interfaces, the primary interface eno1 is connected to LAN (gateway 192.168.1.1), the alternate interface eno4 to the network 192.168.88.0. Consequently I have added on the server with iproute2 a second routing table (mng) and have added the necessary rules there:

Code Select Expand


controller# ip rule list
0: from all lookup local
32764: from all to 192.168.88.11 lookup mng
32765: from 192.168.88.11 lookup mng
32766: from all lookup main
32767: from all lookup default


In this second routing table I have configured:

Code Select Expand


controller# ip route list table mng
default via 192.168.88.1 dev eno4
192.168.88.0/24 dev eno4  scope link  src 192.168.88.11

So: what works:
LAN works normal.
I can ping another server in the network 192.168.88.0.
I can ping the gateway:

Code Select Expand


controller# ping -I eno4 192.168.88.1
PING 192.168.88.1 (192.168.88.1) from 192.168.88.11 eno4: 56(84) bytes of data.
64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=1061 ms
64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=52.2 ms
64 bytes from 192.168.88.1: icmp_seq=3 ttl=64 time=59.7 ms
64 bytes from 192.168.88.1: icmp_seq=4 ttl=64 time=1059 ms
64 bytes from 192.168.88.1: icmp_seq=5 ttl=64 time=83.2 ms
64 bytes from 192.168.88.1: icmp_seq=6 ttl=64 time=90.8 ms

(Remarkable the large variety and duration of the ping ...), but I can't reach the WAN address:

Code Select Expand


controller# ping -I eno4 192.168.2.101
PING 192.168.2.101 (192.168.2.101) from 192.168.88.11 eno4: 56(84) bytes of data.
From 192.168.88.11 icmp_seq=1 Destination Host Unreachable

Obviously, there is a missing route in the opnsense between the gateway 192.168.88.1 and the WAN. Evidence for this is when executing on the server:

Code Select Expand


controller # ip neigh show
104.68.210.119 dev eno4  FAILED
192.168.88.31 dev eno4 lladdr 00:25:kk:mm:rr:a1 STALE
192.168.2.1 dev eno4  FAILED
104.108.187.66 dev eno4  FAILED
192.168.88.1 dev eno4 lladdr 00:17:ww:ff:ww:1c STALE
192.168.1.83 dev eno1 lladdr ac:87:ww:ff:nn:rr REACHABLE
192.168.2.101 dev eno4  FAILED
192.168.1.1 dev eno1 lladdr 00:17:nn:aa:bb:1a STALE
(...)

(Don't ask me why even LAN connections are stale  8)); BUT, a trace route command to an address in the internet shows

Code Select Expand


controller# traceroute -i eno4 www.nokia.com
traceroute to www.nokia.com (104.68.210.119), 30 hops max, 60 byte packets
1  192.168.88.1 (192.168.88.1)  57.456 ms  59.551 ms  59.545 ms
2  192.168.2.1 (192.168.2.1)  59.573 ms  59.611 ms  59.592 ms
3  217.0.117.111 (217.0.117.111)  59.684 ms  59.668 ms  59.659 ms
4  (...)
8  a104-68-210-119.deploy.static.akamaitechnologies.com (104.68.210.119)  187.744 ms  187.735 ms  187.724 ms

something really confusing here .... :o :-\

I don't understand why with the given firewall rules the WAN net cannot be reached. How can I fix that?

Does anybody has an idea?

Looking forward to your reply.

Br br

Hello together,

I am facing currently on some web pages a very poor performance up to that they are not be shown at all in any browser of the network (LAN). Example ist eg www.lumas.de or also postbank.de. Commonality to these sites is

• widespread use of large java script files obtained from many different URLs
• Many Banner and images

but others with the same pattern work fine.

My Opnsense runs in a XEN VM. I am using unbound on the opnsense box as primary DNS resolver, being connected to OpenDNS and Google DNS Servers. Config on all of the opnsense box interfaces is

Code Select Expand


xn0: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=503<RXCSUM,TXCSUM,TSO4,LRO>
(...)
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet manual
status: active


No pecularity in the logs of the opnsense box. I correlate this behavior time wise  to the update to 16.1.14, getting slowly worse over time.

My config is a fritz box accessing the internet and being connected to the WAN interface in opnsense, running dual stack ipv4 and ipv6. All clients in the LAN (mobile and fixed) showing the same behavior for the same sites with the different browsers (Safari, Chrome, Firefox). Even if the problem page appears after a while, its mostly incomplete, elements are missing. I assumed an misconfig or anything like this in MTU, but so far I found no evidence for this ..

What I could find out so far:

• When I bypass opnsense and connect to the fritzbox directly, performance is fine
• When I switch off Javascript in the browser, then performance is also ok (but indeed not everything is shown)
• The progress bar for these pages hang for sometime several minutes and progress stepwise
• I randomly checked some of the URLs being embedded in the pages show pretty diverging DNS resolution time when resolved with unbound (22ms (normal) up to 340 ms) but not when resolved directly eg with google DNS server
• rebooting clients, deleting caches in the browser, rebooting opnsense did not change anything
• error monitor in safari indicates very long load times of some java scripts (eg postbank.js)

Has somebody an idea how such an issue can be systematically analysed further, eg with some diag tools on opnsense or client?

I am looking forward to any kind of ideas and tips.

Thanks for your support

Br br

Hello,

having this time some trouble with upgrading to 16.1.16 via the Dashboard. The process runs through until the message

Code Select Expand

Registering root shell

and then the UI hangs forever. No popup window that system is rebooting. The services are still normally running.

After 30min. I enforced a reboot via terminal and the system came up in the second attempt again. Dashboard issue has been reported already ...

Br br

... it still shows 16.1.8 as the last release and obviously 16.1.9 is out since a while and 16.1.10 shall come today ....

Is there now a different announcement instrument?

Looking forward to your reply

Br br

Hallo,

when starting a new XEN VM which obtain its IP Adress from the DHCP server of opnsense, I had to note that this lease is not forwarded to the unbound DNS resolver. Could somebody explain which lease types are forwarded and which not?

According to my understanding, opnsense DHCP server puts the leases in /var/var/dhcpd/var/db/dhcpd.leases. From there, the script /usr/local/opnsense/scripts/dns/unbound_dhcpd.py regularly checks and writes the leases in the unbound required format to /var/unbound/dhcpleases.conf. Then, they can be resolved with DNS requests.

Not clear is WHICH leases are written. I would expect that all leases which are active, have address and hostname and are not expired should be written. This seems to not to be the case:

Here 2 examples of my leases:

Code Select Expand


lease 192.168.1.213 {
  starts 6 2016/04/09 15:29:23;
  ends 0 2016/04/10 15:29:23;
  cltt 6 2016/04/09 15:29:23;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 74:81:14:30:f9:7f;
  uid "\001t\201\0240\371\177";
  client-hostname "iPad";
}


is in the unbound file available as

Code Select Expand


local-data-ptr: "192.168.1.213 iPad.example.xx"
local-data: "iPad.example.xx IN A 192.168.1.213"


Consequently, a command

Code Select Expand


dig iPad
; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> ipad.example.xx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39695
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipad.example.xx. IN A

;; ANSWER SECTION:
ipad.example.xx. 3600 IN A 192.168.1.213

;; Query time: 0 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Sat Apr 09 20:24:22 CEST 2016
;; MSG SIZE  rcvd: 76


leads to the desired result

A second lease

Code Select Expand


lease 192.168.1.206 {
  starts 6 2016/04/09 17:44:48;
  ends 6 2016/04/09 19:44:48;
  cltt 6 2016/04/09 17:44:48;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:16:3e:ef:c2:0c;
  client-hostname "develop";
}


has not been transferred to unbound during its entire active time.

Is there a reason for that? Although not so familiar with python, I could not find any reason in the script, why this lease should not be transferred.

Any ideas?

Looking forward to your reply.

Br br

Hi there,

in 15.7.23, an error has been described in https://forum.opnsense.org/index.php?topic=1890.0, which has been fixed;

In 16.1.2, it is back again in a similar form: dhcp server page throws

Code Select Expand

57 Warning: Illegal string offset 'lan' in /usr/local/www/services_dhcpv6.php on line 58 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 57 Warning: Illegal string offset 'opt1' in /usr/local/www/services_dhcpv6.php on line 58 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 57 Warning: Illegal string offset 'opt2' in /usr/local/www/services_dhcpv6.php on line 58

Part of this information is hidden behind the top menu bar on the page, however its visible; (last time it was in line 432, now in line 57...)

BR br

[on the dom0 side]

Hello,

I have a question wrt the checkbox 'Disable Hardware CRC offloading' in System->Einstellungen->Network. CRC Hardware offloading is indeed a known issue with some NIC drivers when Freebsd runs as XEN HVM. The issue manifests in almost zero throughput through Opnsense from any other VM and dom0. I would have assumed that the idea behind setting this box should fix the known NIC driver problem

In the (new extended) documentation it is also recommended to tick the checkbox when installing Opnsense as a VM. At least for my native XEN installation,  this setting has no effect except a slightly higher CPU load, while traffic ist still almost none.

After a lot of forum research and experimenting around when installing opnsense, the break through came when  CRC offloading has been configured for the vif between dom0 and opnsense on the dom0 side in tx direction. If  CRC offloading is not configured for the direction, then only less then 1k bit throughput can be seen to any VM through Opnsense. Why is still not really clear to me ....

Im still looking for a concept that this setting is automatically done when opnsense is booting.  Up to now, I still have to launch an ethtool command manually on the dom0 side after each reboot

Does anybody has different experiences with a XEN installation for this or has solved the booting problem?

Looking forward to your reply.

Br br

Hello,

I am trying since a while to make my IPTV (Entertain from Deutsche Telekom) working with the VLC player with some Apple clients. While several articles show how to achieve this by directly connecting over a VDSL Modem and XXsense (eg https://blog.tausys.de/2014/10/16/telekom-iptv-mit-pfsense/), I have to rely my Internet connection on a Fritzbox for several reasons. Many others have given up here, however I feel still some hope to be pretty close to a solution ... :o

I notice now that the igmpproxy of opnsense seem to show a behavior which prevents a stable igmp stream for more than 2 minutes. After that, the stream freezes; about 5-8 min later, another 2 min of TV can be seen on the client until the same happens again.

On the LAN side, I see the expected multicast behavior:

Code Select Expand


192.168.x.254  opnsense -> 224.0.0.1:           Opnsense sends general IGMP Membership Query
192.168.x.22    client        -> 239.35.10.4:       Client sends membership report for group 239.35.10.4 (i.e. German 1st TV program)

As opnsense' igmpproxy is only supporting IGMP V2 on the LAN side, this look OK to me, and this sequence is repeated every 120 sec. This means, that the client is reporting every 2 min, that it still wants to belong to this igmp IPTV group. So far so good ....

The - according to my understanding - strange behavior happens on the WAN side of opnsense: As said, in my configuration, it is connected with a fritz box. I also read about the igmpproxy that on the WAN side, igmpproxy speaks IGMPv3 as also the fritzbox does. I also read that igmpproxy shall behave LIKE A CLIENT. What I see is:

Code Select Expand


192.168.y.1         fritzbox         -> 224.0.0.1: Fritzbox sends general igmp membership query
192.168.y.100     opnsense     -> 224.0.0.22: IGMPv3: opnsense sends a Membership Report/Leave group 239.35.10.4 (why????)
and immediately after
192.168.y.100     opnsense     -> 224.0.0.22: IGMPv3: opnsense sends a Membership Report/join group 239.35.10.4 (why????)

After that, it does only sporadically or even not at all answers on the general igmp queries from the fritzbox for the IPTV stream; naturally, after 2 min, the fritzbox disconnects the igmp Data stream (UDP) with the TV data and sends from its side a leave group.

At least to me this sounds like a reasonable explanation pattern for the seen behavior. Not understood is indeed, why the stream starts after 5-8 min again and why then suddenly the igmpproxy again sends a join request...What might trigger it?

I would have expected, that for EACH membership report for the IP TV channel on the LAN side, also a membership report is generated on the WAN side. Does anybody here has seen the described behavior? Is this something what could be corrected with a config modification?

My igmpproxy.conf look as follow

Code Select Expand



##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint xn1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4

phyint xn0 downstream ratelimit 0 threshold 1
altnet 192.168.x.0/32

phyint xn2 disabled
phyint xn3 disabled



Looking forward to your reply
Br br

Hello together,

during systematically walking through all GUI pages of services and trying it out, another faulty behavior appeared on the service 'dhcp server' configuration page:

When you have made an addition or modification on the static mapping dhcp area at the bottom, you can store ist but then pressing the 'Änderungen übernehmen' button leads to the picture as shown in the screenshot below.

The 'Änderungen übernehmen' banner then is always there and even survives a log out/login and can only be made disappearing via reboot (at least so far ...)

Br br