Messages

1

23.1 Legacy Series / Re: DynDNS with ddclient

« on: March 14, 2023, 07:25:10 am »

Just running through OpnSense setup for the first time.
Is there any issue with DynDNS.com support in ddclient? I've set up the service much as I had previously on pfsense but I'm seeing some odd errors:
Service: DynDNS.com
Username: <entered>
Password: <client key>
Wildcard: Unchecked
Hostname: <hostname.dyn.com>
Check IP Method: Interface
Check IP Timeout: 10
ForceSSL: Checked
Interface to monitor: WAN

Current IP never gets updated, or a last updated time appear. Also errors in debug log:
FAILED: was not updated because protocol <undefined> is not supported.
FAILED: updating : unexpected status (0)
WARNING: updating : nochg: No update required; unnecessary attempts to change to the current address are considered abusive
FAILED: updating hostname.dyn.com unexpected status (12)
WARNING: found neither IPv4 nor IPv6 address
FAILED: updating hostname.dyn.com: Could not connect to members.dyndns.org.

Has anyone got this working or do people still rely on the older dyndns plugin?

It seems that the protocol is not defined.

Can you check your ddclient.conf (/usr/local/etc/ddclient.conf) for the created entry?

It might be that you have to manually adjust the config.

Here's an example I use for desec.io:

Code: [Select]

syslog=yes                  # log update msgs to syslog
pid=/var/run/ddclient.pid   # record PID in file.
ssl=yes


use=if, if=igb0, \
protocol=dyndns2, \
server=update.dedyn.io, \
login=USERNAME, \
password=PASSWORD \
<DOMAIN>.dedyn.io

You could try either protocol=dyndns1 or protocol=dyndns2.

2

General Discussion / DEC2750 firmware upgrade stuck (current firmware newer)

« on: March 09, 2023, 08:39:06 am »

Hi all

I just wanted to update my DEC2750 with the latest firmware but didn't realize that the firmware on the board was newer than the one downloaded.

It seems that the firmware updater doesn't do anything. Is it safe to reboot?

*EDIT*
Nevermind, I just rebooted and everything is fine.

Out of curiosity: Why isn't this firmware version online available?
05.32.50.0014-A10.24

3

22.1 Legacy Series / Re: Is RC2 usable yet? Can I import 21.x series backup

« on: January 26, 2022, 03:25:50 pm »

@franco
Would you recommend to clean install when coming from 21.7 on ZFS?

4

21.7 Legacy Series / Re: Why is custom options for Unbound removed in 21.7 ?

« on: August 10, 2021, 04:42:28 pm »

Code: [Select]

server:
    private-domain: "plex.direct"

Private domain is supported, see Services: Unbound DNS: Blocklist.

Ah, thanks for the hint.

5

21.7 Legacy Series / Re: Why is custom options for Unbound removed in 21.7 ?

« on: August 09, 2021, 05:34:15 pm »

Is there a reason that the custom config files I create disappear from the folder after I restart unbound?

Are you creating them in /usr/local/etc/unbound.opnsense.d as documented?

Yeah, I think there was an issue related to the indentation. The config file seems to be persistent now.

6

21.7 Legacy Series / Re: Why is custom options for Unbound removed in 21.7 ?

« on: August 09, 2021, 05:06:19 pm »

Is there a reason that the custom config files I create disappear from the folder after I restart unbound?

To be more precise. Let's say I create a new config file /usr/local/etc/unbound.opnsense.d/plex.conf with the following content:

Code: [Select]

server:
    private-domain: "plex.direct"This config file disappears when I restart unbound.

*EDIT*
Nevermind, it seems to have been related to the indentation.

7

Tutorials and FAQs / Re: HOW TO - Configure OPNsense for TV7 (init7) Multicast Stream

« on: May 10, 2021, 09:20:18 pm »

Sorry for the delay in writing @hidalgo

For pfSense the "Floating step" shouldn't be necessary.
The linked articles from Philip Hofstetter and Philipp Häfelfinger should explain the pfSense configuration pretty well.

8

21.1 Legacy Series / Re: Issues after rebooting OPNsense

« on: April 26, 2021, 11:35:57 am »

Ok, after I removed os-wireguard (including all firewall rules) and os-api-backup everything is back to normal.

If I should guess what caused the issue I'd suspect os-wireguard.
Since I'm not actually using it I'll leave it uninstalled for now. Let's see how the kmod will perform when it's released.

9

21.1 Legacy Series / [SOLVED] Issues after rebooting OPNsense

« on: April 06, 2021, 05:25:47 pm »

Hi

I'm not quite sure since when I have the issue, might be since upgrading to 21.1, definitely since 21.1.3.
When I reboot my OPNsense (running on an PC Engines APU2) initially everything is working but after a couple of minutes everything stops responding.

The browser is reporting that there were invalid TLS information making it unable to access the Web UI at all, DHCP / DNS are also not working anymore.

Gladly I am able to access the APU through SSH. From there if I choose "Reload all services" everything works normally until the next reboot.

I tried to gather some logs but wasn't sure where to look for them (tried /var/log/).

Does anyone else experience the same issue? Any advice on how I can grab the relevant logs?

*EDIT*
Might this be RTC related? NTP log is reporting this:

Code: [Select]

Apr  6 17:04:28 OPNsense ntpdate[32553]: step time server offset -7200.589284 sec
Apr  6 17:04:29 OPNsense ntp[49450]: Successfully synced time after 1 attempts.
Apr  6 17:04:29 OPNsense ntp[51637]: Starting NTP Daemon.
Apr  6 17:04:29 OPNsense ntpd[64311]: ntpd 4.2.8p15@1.3728-o Mon Jan 25 04:33:48 UTC 2021 (1): Starting
Apr  6 17:04:29 OPNsense ntpd[64311]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Apr  6 17:04:29 OPNsense ntpd[64311]: ----------------------------------------------------
Apr  6 17:04:29 OPNsense ntpd[64311]: ntp-4 is maintained by Network Time Foundation,
Apr  6 17:04:29 OPNsense ntpd[64311]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
Apr  6 17:04:29 OPNsense ntpd[64311]: corporation.  Support and training for ntp-4 are
Apr  6 17:04:29 OPNsense ntpd[64311]: available at https://www.nwtime.org/support
Apr  6 17:04:29 OPNsense ntpd[64311]: ----------------------------------------------------
Apr  6 17:04:29 OPNsense ntpd[67577]: proto: precision = 0.415 usec (-21)
Apr  6 17:04:29 OPNsense ntpd[67577]: basedate set to 2021-01-13
Apr  6 17:04:29 OPNsense ntpd[67577]: gps base set to 2021-01-17 (week 2141)
Apr  6 17:04:29 OPNsense ntpd[67577]: restrict: 'monitor' cannot be disabled while 'limited' is enabled
[...]
Apr  6 17:04:29 OPNsense ntpd[67577]: Listening on routing socket on fd #33 for interface updates
Apr  6 17:04:29 OPNsense ntpd[67577]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Apr  6 17:04:29 OPNsense ntpd[67577]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Apr  6 17:10:10 OPNsense ntpd[67577]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized


10

21.1 Legacy Series / Re: webgui broken after upgrade to 21.1.4

« on: April 01, 2021, 10:34:14 am »

I had similar issues already with 21.1.3 and they are still present in 21.1.4.

The behavior is always the same. After I reboot the OPNsense the Web UI initially works but will eventually stop including unbound.

Luckily SSH is still working and the interfaces are reachable via IP. After I restart all services through the console everything is working as expected once again.

11

20.7 Legacy Series / Re: IPv6 problems with APU2 (possibly related to multicast MLDv2).

« on: October 15, 2020, 07:26:26 am »

Do you have to use PPPoE to connect to your ISP?

12

20.7 Legacy Series / Re: Slow WAN after upgrade

« on: August 21, 2020, 01:23:08 pm »

Looking at this patch... it is not present in 12.1 so there might be an issue there, but probably always has been.


Cheers,
Franco

The issue was introduced in 11.3 afaik. There might be a possibility that it is also present on 12.X but as I said I'm not sure if this was present at all in 12.X. It might very well be that 12.X was unaffected by this bug.

As far as I can tell I neither had such an issue with OPNsense 20.7 BETA nor with some other fw brand based on FreeBSD 12.0.

13

20.7 Legacy Series / Re: Slow WAN after upgrade

« on: August 21, 2020, 07:34:08 am »

For what it's worth when I recall this correct support for i210AT / i211AT was merged into the em driver starting from FreeBSD 12 while when using FreeBSD 11 the driver for those NICs was the igb one.

What would be interesting to know is if you see any spikes in CPU usage.
There is / was a bug inside pf which caused high CPU utilization. With the CPU at its limit the throughput of course went down from what it originally was.
Not sure if this bug was present in FreeBSD 12 though: https://reviews.freebsd.org/D24803

14

German - Deutsch / Re: [GELÖST] TV7 (init7) Multicast funktioniert nicht

« on: June 28, 2020, 09:20:09 pm »

Hab hier mal was zusammengeschieben: https://forum.opnsense.org/index.php?topic=17865.0

15

Tutorials and FAQs / HOW TO - Configure OPNsense for TV7 (init7) Multicast Stream

« on: June 28, 2020, 08:23:31 pm »

I had a hard time figuring out that the Multicast IP to Multicast MAC translation doesn't properly work.
The issue itself is described here: https://github.com/opnsense/core/issues/3629

Therefore I decided to write a quick tutorial for init7 customers to properly configure Multicast on OPNsense for TV7.

Credits:

• Philip Hofstetter: https://blog.pilif.me/2018/05/22/fiber7-tv-behind-pfsense/
• Philipp Häfelfinger: https://haefelfinger.ch/posts/2018/2018-10-18-fiber7-tv7-pfsense/

Note: the following step-by-step guide applies to init7's TV7 Multicast stream. The configuration might differ if you use this guide to achieve similar results for other Multicast streams.

1. Install plugin
To get Multicast to work on OPNsense we are going to use os-igmp-proxy.

2. Configure IGMP Proxy
To get started we need to configure IGMP Proxy.

• Navigate to Services -> IGMP Proxy
• Click Add+ and use the following config:
  
  • Interface: WAN
  • Description: WAN_UP
  • Type: Upstream Interface
  • Threshold: 1
  • Option 1: Networks (single entry): 77.109.129.0/25
  • Option 2: Networks (multiple entries, single hosts):
    
    • 77.109.129.16/32
    • 77.109.129.17/32
    • 77.109.129.18/32
    • 77.109.129.19/32
• Click Save
• Once again click Add+ and use the following config:
  
  • Interface: LAN
  • Description: LAN_DOWN
  • Type: Downstream Interface
  • Threshold: 1
  • Networks: Enter your local network here (e.g. 192.168.1.0/24)
• Click Save once again

This will do it for the IGMP Proxy config.
We will now move along to the Firewall Rules.

3. Firewall Rules

LAN
First we have to enable allow options on the default LAN rule Default allow LAN to any rule.

• Navigate to Firewall -> Rules -> LAN
• Edit the rule with the description "Default allow LAN to any rule" by clicking the pencil.
• Scroll down until you see Advanced Options: and click on Show/Hide
• Make sure that the allow options checkbox is checked
• Click Save
• Back on Overview click on Apply changes to enable the changed rule

WAN
Now we have to properly configure the WAN rules to allow IGMP and Multicast traffic.

• Navigate to Firewall -> Rules -> WAN
• Click Add+
• Apply the following config:
  
  • Protocol: IGMP
  • Source: WAN net
  • Destination: Single host or Network -> 224.0.0.0/4
  • Description: Allow IGMP Multicast Traffic
• Scroll down until you see Advanced Options: and click on Show/Hide
• Make sure that the allow options checkbox is checked
• Click Save
• Click once again Add+
• Apply the following config:
  
  • Protocol: PIM
  • Source: WAN net
  • Destination: Single host or Network -> 224.0.0.0/4
  • Description: Allow PIM Traffic
• Scroll down until you see Advanced Options: and click on Show/Hide
• Make sure that the allow options checkbox is checked
• Click Save
• Once again click Add+ and apply the following config:
  Option A (single Rule):
  
  • Apply the following config:
    
    • Protocol: UDP
    • Source: Single host or Network -> 77.109.129.0/25
    • Destination: Single host or Network -> 239.0.0.0/8
    • Destination port range: Other -> from: 5000 -> to: 5000
    • Description: init7: Allow Multicast Traffic
  • Scroll down until you see Advanced Options: and click on Show/Hide
  • Make sure that the allow options checkbox is checked
  • Click Save
  Option B (multiple rules, single host):
  
  • Apply the following config:
    
    • Protocol: UDP
    • Source: Single host or Network -> 77.109.129.16/32
    • Destination: Single host or Network -> 239.0.0.0/8
    • Destination port range: Other -> from: 5000 -> to: 5000
    • Description: init7: Allow Multicast Traffic
  • Scroll down until you see Advanced Options: and click on Show/Hide
  • Make sure that the allow options checkbox is checked
  • Click Save
  • Back on Overview clone the rule which has 77.109.129.16 as source
  • Change source to 77.109.129.17
  • Click Save
  • Back on Overview clone the rule which has 77.109.129.17 as source
  • Change source to 77.109.129.18
  • Click Save
  • Back on Overview clone the rule which has 77.109.129.18 as source
  • Change source to 77.109.129.19
  • Click Save
• Back on Overview click on Apply changes to enable the changed rule

With the firewall properly configured, everything should be running fine, right?

Yes, that's where this GitHub issue comes into play.
We actually need one more rule.

Floating
We need to add a floating rule to fix the Multicast MAC address issue.

Every Multicast IP address resolves into a predefined Multicast MAC address
Here are some information about it including a calculator: http://www.dqnetworks.ie/toolsinfo.d/multicastaddressing.html

If the Multicast MAC address does not match the Multicast IP address one can only guess what the gateway will do with it.
Therefore we have to add a new floating rule:

• Navigate to Firewall -> Rules -> Floating
• Click Add+
• Apply the following config:
  
  • Interface: WAN
  • Direction: out
  • Protocol: IGMP
  • Source: WAN address
  • Destination: Single host or Network -> 224.0.0.0/4
• Scroll down until you see Advanced Options: and click on Show/Hide
• Make sure that the allow options checkbox is checked
• Click Save
• Back on Overview click on Apply changes to enable the changed rule

With this rule in place we are able to properly receive the TV7 Multicast stream.