OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of sToRmInG »
  • Show Posts »
  • Topics
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Topics - sToRmInG

Pages: [1]
1
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

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

3
German - Deutsch / [GELÖST] TV7 (init7) Multicast funktioniert nicht
« on: June 28, 2020, 07:24:01 am »
Hallo zusammen

Ich versuche gerade TV7 per Multicast (Provider: init7.net) zum Laufen zu bringen.
Allerdings läuft der Stream nur, wenn ich das gesamte Packet Filtering deaktiviere.

Was mich etwas erstaunt ist, dass die gleiche Konfiguration auf pfSense einwandfrei läuft.

Das Setup sieht wie folgt aus:
  • Getestet sowohl auf 20.1.7 als auch auf 20.7b3
  • os-igmp-proxy bzw os-igmp-proxy-devel installiert
IGMP Proxy Config:
Code: [Select]
##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint igb0 upstream ratelimit 0 threshold 1
altnet 224.0.0.0/4
altnet 77.109.129.16/32
altnet 77.109.129.17/32
altnet 77.109.129.18/32
altnet 77.109.129.19/32

phyint igb1 downstream ratelimit 0 threshold 1
altnet 192.168.1.0/24

WAN FW-Regeln:
DirectionProtocolSourcePortDestinationPortGatewayScheduleDescription
inIPv4 IGMP******Allow IGMP
inIPv4 PIM******Allow PIM
inIPv4 UDP77.109.129.16*239.0.0.0/85000**Allow Multicast Traffic from init7
inIPv4 UDP77.109.129.17*239.0.0.0/85000**Allow Multicast Traffic from init7
inIPv4 UDP77.109.129.18*239.0.0.0/85000**Allow Multicast Traffic from init7
inIPv4 UDP77.109.129.19*239.0.0.0/85000**Allow Multicast Traffic from init7

Bei allen Regeln wurden die allow options aktiviert (inkl. Default IPv4 LAN Regel).

Diese Konfigration funktioniert auf der pfSense einwandfrei.
Hat jemand eine Idee, wieso dies auf der OPNsense nicht funktioniert?

Die Firewall Logs waren leider wenig aufschlussreich, ich sehe nicht, dass irgendetwas Relevantes geblockt würde.
Der Hauptunterschied im IGMPProxy Log ist jedoch, dass bei aktivierter FW der Eintrag für den Multicast Forwarding Cache von 77.109.129.16/17/18/19 auf die jeweilige Multicastadresse fehlt .

Die verwendete Senderliste ist hier zu finden: https://www.init7.net/de/support/faq/TV-andere-Geraete/

Pages: [1]
OPNsense is an OSS project © Deciso B.V. 2015 - 2023 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2