"Recent posts
#21
General Discussion / Re: Specific website cannot be...
Last post by OPNenthu - Today at 08:22:18 AM... annnnd, scratch my theory. I missed that you said you have DNS over TLS, lol.
#22
German - Deutsch / Re: Anbindung an die Telematik...
Last post by RES217AIII - Today at 08:12:07 AMGuten Morgen,
meiner Erfahrung konnte ich erst KIM+ und KVsafenet nach Integration und Aktivierung der SMC B erreichen, anders als in der Dokumentation meines Serviceanbieters (Tomedo von Zollsoft) angegeben. Was mich nebenbei in den Wahnsinn getrieben hat, als ich vor dem geplanten Installationstermin durch Zollsoft soweit alles vorbereiten wollte.
Einstellung "skip firewall rules" wie auf dem screenshot anbei.
meiner Erfahrung konnte ich erst KIM+ und KVsafenet nach Integration und Aktivierung der SMC B erreichen, anders als in der Dokumentation meines Serviceanbieters (Tomedo von Zollsoft) angegeben. Was mich nebenbei in den Wahnsinn getrieben hat, als ich vor dem geplanten Installationstermin durch Zollsoft soweit alles vorbereiten wollte.
Einstellung "skip firewall rules" wie auf dem screenshot anbei.
#23
General Discussion / Re: ECS and DNSSEC Setup
Last post by OPNenthu - Today at 08:10:10 AMECS or not makes no difference in how you configure Quad9 for Unbound. It's just a forwarding address with a different IP than the non-ECS version: 9.9.9.11 vs. 9.9.9.9. Unbound doesn't care :)
Quad9's TLS forwarding guide for OPNsense: https://docs.quad9.net/Setup_Guides/Open-Source_Routers/OPNsense_%28Encrypted%29/
Curious- why do you prefer the ECS version? Do you get an appreciable performance boost from CDNs?
If Unbound is doing your DNS resolution then Dnsmasq should not be reached by your clients. You need to configure it as per the examples in https://docs.opnsense.org/manual/dnsmasq.html#configuration-examples and make sure Unbound is forwarding to Dnsmasq for your internal domains. Dnsmasq doesn't need to know anything about Quad9 in this case. It should never be answering queries for any domain except those configured on your network.
Quad9's TLS forwarding guide for OPNsense: https://docs.quad9.net/Setup_Guides/Open-Source_Routers/OPNsense_%28Encrypted%29/
Curious- why do you prefer the ECS version? Do you get an appreciable performance boost from CDNs?
If Unbound is doing your DNS resolution then Dnsmasq should not be reached by your clients. You need to configure it as per the examples in https://docs.opnsense.org/manual/dnsmasq.html#configuration-examples and make sure Unbound is forwarding to Dnsmasq for your internal domains. Dnsmasq doesn't need to know anything about Quad9 in this case. It should never be answering queries for any domain except those configured on your network.
#24
General Discussion / Re: Specific website cannot be...
Last post by OPNenthu - Today at 07:13:09 AMSince this isn't getting replies I'll take a shot. The only reason I'm hesitant is because you're getting cert errors from Firefox too, so I might be wrong about the cause.
I *think* the Unbound log could be due to a DNSSEC validation error. The fact that it works on VPN could be due to a different DNS server being used by the VPN client which is maybe ignoring or hiding the DNSSEC failure, as those don't get passed back to Unbound in that case.
When I used to use Ubound in recursive mode I would encounter websites that I could not access, sometimes important ones like government sites that do not set up DNSSEC properly. It's hard to know if the issue is due to misconfiguration or a genuine case of DNS cache poisoning / spoofing.
These days I use Unbound in forwarding mode and I trust the upstream resolver to do validation checks. It's not perfect but I encounter the issue less often now, and at least trusting a 3rd party to validate is better than me disabling it completely out of frustration or having to toggle it.
Why has the frequency reduced? I don't really know. It could be that validation fails at the upstream resolver as well but they have additional intelligence to pass the domain as safe anyway. It could be that they're lying and exposing me to potential harm. It could also be that site operators have largely fixed the misconfigurations.
I hope this offered something useful.
I *think* the Unbound log could be due to a DNSSEC validation error. The fact that it works on VPN could be due to a different DNS server being used by the VPN client which is maybe ignoring or hiding the DNSSEC failure, as those don't get passed back to Unbound in that case.
When I used to use Ubound in recursive mode I would encounter websites that I could not access, sometimes important ones like government sites that do not set up DNSSEC properly. It's hard to know if the issue is due to misconfiguration or a genuine case of DNS cache poisoning / spoofing.
These days I use Unbound in forwarding mode and I trust the upstream resolver to do validation checks. It's not perfect but I encounter the issue less often now, and at least trusting a 3rd party to validate is better than me disabling it completely out of frustration or having to toggle it.
Why has the frequency reduced? I don't really know. It could be that validation fails at the upstream resolver as well but they have additional intelligence to pass the domain as safe anyway. It could be that they're lying and exposing me to potential harm. It could also be that site operators have largely fixed the misconfigurations.
I hope this offered something useful.
#25
25.7, 25.10 Series / NAXSI Archived
Last post by utahbmxer - Today at 07:12:58 AMWhile tuning some rules for a new site, I went to look at the default core.rules and noticed that the original NAXSI repo is archived and they direct users to https://github.com/wargio/naxsi.
Has this been reflected in OPNsense? Maybe it already is, but thought I would ask. Really love the WAF, and wanted to make sure it wasn't running some unmaintained plugin. Thank you!
Has this been reflected in OPNsense? Maybe it already is, but thought I would ask. Really love the WAF, and wanted to make sure it wasn't running some unmaintained plugin. Thank you!
#26
25.7, 25.10 Series / Re: dnsmasq and ipv6 config
Last post by Maurice - Today at 04:59:56 AMQuote from: muchacha_grande on Today at 12:18:01 AMI understand that when you say that I could chose any unused /48, you are talking about ULAs. Are you?No, I'm talking about GUAs. ULAs are not recommended for the NAT use case.
You can use any unassigned prefix. It's a little ugly, but less ugly than using /80.
#27
Hardware and Performance / Re: [solved] Intel i226 Firmwa...
Last post by BrandyWine - Today at 03:08:38 AMQuote from: mpoldphone191 on December 23, 2025, 01:50:53 AMJust one question when I ran "dmesg | grep IGC" I am seeing some references to the older version? I am assuming that this is a cumulative log that doesn't clear on reboot?
Welcome to freeBSD. You are seeing old boot info. You can change that behavior.
Use the flash utility to get info on all the nics it can address.
#28
25.7, 25.10 Series / Re: dnsmasq and ipv6 config
Last post by muchacha_grande - Today at 02:32:38 AMQuote from: Patrick M. Hausen on Today at 12:28:32 AMYou could write to LACNIC asking if there is any way to exert some pressure on ISPs who do not follow proper conventions.
I will pass from that for now.
Quote from: Patrick M. Hausen on Today at 12:28:32 AMYes, for NAT66 you could use some GUA that you know are unused. ULA is not recommended, because happy eyeballs prioritises it after IPv4.
That's ok. It is possible because NAT66 do the translation into a routable IP. Will do that.
Thank you.
#29
Spanish - Español / Re: OPNsense + Orange FTTH (Es...
Last post by kabuto - Today at 01:45:03 AMNo me ha dejado meter más imágenes, quizás tenga que subirlas a un sitio online para que no ocupen en el post
#30
Spanish - Español / OPNsense + Orange FTTH (España...
Last post by kabuto - Today at 01:42:49 AMOs dejo por aquí también las instrucciones para poder configurar Orange, tanto tv como internet (el telefono lo tenia anteriormente, pero ya no utilizo el fijo, si alguien lo utiliza, tiene que saber que tiene que comprarse un aparato aparte para darle las credenciales SIP y poder tener llamadas por el fijo, en bandaancha ya lo puse hace años como se hacia.
Internet OK (VLAN 832) + IPTV OK (VLAN 838) sin IGMP Proxy, usando Bridge
Esta guía resuelve el problema de utilizar la mierda de routers que te dan capados y sobre todo con poca actualización
Internet por VLAN 832 funciona perfecto.
IPTV por VLAN 838 no funciona con IGMP Proxy (no llega el multicast).
Con un bridge entre el puerto del desco y la VLAN 838, la TV funciona (fútbol, directos, etc).
Los pasos clave son 2, yo estaba enfrascado con el IGMP Proxy y no hace falta para nada.
El descodificador de Orange tiene que tener una IP privada interna (la da OPNsense por DHCP, en mi caso puse la 192.168.4.1 para esa red y el DHCP dede la 10 hasta la 20, con 1 sobraba, pero bueno por poner algo).
El tráfico multicast de TV va por VLAN 838 a nivel 2 (bridge), como si fuera el router de Orange.
0) Requisitos y ejemplo de hardware
ONT: Zte F601 (o similar), la podeis encontar muy barata de segunda mano, o podeis utilizar el Livebox o lo que tengais en modo ONT, yo utilizo esa ONT por se muy pequeña y poderse esconder en cualquier sitio.
Como configurar todo con OPNsense.
Un puerto físico dedicado para el desco (ejemplo: igb1).
Mi router (mini PC tiene 5 puertos dedicados, lo que me permite poder manejar la LAN por un lado, el wifi por otro y el desco en otro y todavía me sobran 2 para futuras actualizaciones
La ONT conectada al puerto WAN físico de OPNsense (en mi caso igb5).
Ejemplo de interfaces:
igb5 → hacia ONT (tráfico etiquetado con VLAN 832 y 838). Esto para que lo entendáis es el cable que os llega de la ONT y se suele llamar WAN
igb1 → hacia el decodificador.
1) Configura Internet (VLAN 832)
Interfaces → Devices → VLAN
Crea VLAN 832 sobre igb5.
Interfaces - Assignments
Asigna esa VLAN a WAN.
You cannot view this attachment.
WAN:
IPv4: DHCP
(Opcional recomendado) Clona la MAC del Livebox si tu línea lo necesita.
Consejo: si puedes, pon la MAC clonada en el padre igb5 o al menos en la interfaz WAN.
Comprueba que Internet funciona antes de tocar IPTV.
Importante marca las opciones para bloquear la redes privadas y los bogon
2) Crea la interfaz IPTV (VLAN 838) sin IP
Interfaces - Devices - VLAN
Crea VLAN 838 sobre igb5 (recuerda tu interfaz WAN la que llega el cable de la ONT).
Interfaces - Assignments
Asigna esa VLAN a una interfaz (ejemplo IPTV_ORANGE).
IPTV_ORANGE:
IPv4: None (sin IP)
No DHCP client.
Prioridad 802.1p (PCP): 4 (Video), si tu OPNsense lo permite en la VLAN.
Nota:
En este método NO necesitas que VLAN 838 coja IP por DHCP de Orange.
NO uses IGMP Proxy.
3) Prepara el puerto del deco (sin IP)
Interfaces - Assignments
Asigna el puerto físico del deco (ej. igb1) como interfaz DECO_TV.
DECO_TV:
IPv4: None (sin IP)
No DHCP server aquí (luego irá en el bridge).
4) Crea el bridge entre el deco y la VLAN 838
Interfaces - Devices - Bridge
Añade un bridge:
Members: igb1 (DESCO) + vlan838 (IPTV_ORANGE) en mi caso, revisa el puerto que tengas asignado al deco
Interfaces - Assignments
Asigna el bridge como una nueva interfaz. Ejemplo: BRIDGE_TV.
BRIDGE_TV:
IPv4: Static
IP: 192.168.4.1/24 (o la red privada que quieras para el deco)
Importante:
La IP privada del deco debe vivir en BRIDGE_TV, no en igb1.
5) DHCP para el deco en el bridge
Services - DHCPv4 - BRIDGE_TV (yo por ejemplo utilizo KEA
Enable DHCP server
Range: por ejemplo 192.168.4.10 - 192.168.4.20
Gateway: 192.168.4.1
DNS:
Opción A (normal): tu DNS habitual (o el propio OPNsense).
Opción B (si notas cosas raras en EPG/apps): DNS de Orange que tengo yo (podéis mirar los que os sale en vuestro router antes de quitarlo y tomar nota de DNS y mac, viene todo en las pantallas del router, al menos en el Livebox)
62.36.225.150
62.37.228.20
(Opcional) NTP si quieres probar:
95.39.224.42
5.56.160.3
kea DHCP
kea dhcp datos
Services - DHCPv4 - DECO_TV (igb1)
Asegúrate de que está desactivado (no debe haber DHCP aquí).
6) NAT para que el deco tenga Internet por la WAN (VLAN 832)
Si el deco ya no tiene Internet, normalmente es por esto.
Firewall - NAT - Outbound
Modo: Hybrid (recomendado) o Manual.
Crea una regla NAT (Solamente si no ves la interfaz en las reglas automáticas):
Interface: WAN (VLAN 832)
Source: 192.168.4.0/24
Translation: WAN address
7) Reglas de firewall en BRIDGE_TV (imprescindible)
Este es el fallo típico al mover la IP al bridge: te quedas sin Internet en el desco hasta que añades regla.
Firewall - Rules - BRIDGE_TV
Regla básica para que el desco tenga Internet:
Action: Pass
IPv4
Source: BRIDGE_TV net (192.168.4.0/24)
Destination: any
Reglas multicast recomendadas:
Pass IPv4 IGMP
Source: 192.168.4.0/24
Destination: any
State type: none
Pass IPv4 UDP
Destination: 224.0.0.0/4
State type: none
Consejo de seguridad (opcional):
Bloquea acceso del desco a tu LAN (192.168.1.0/24 por ejemplo) si no lo necesitas.
Permite solo Internet y lo necesario.
8) Desactiva IGMP Proxy
Services - IGMP Proxy: Stop y deshabilitar.
Con bridge no hace falta y a veces estorba.
9) Ajustes de offload (recomendado)
Interfaces - Settings:
Disable hardware checksum offload
Disable hardware TSO
Disable hardware LRO
VLAN hardware filtering: desactivar
No siempre es obligatorio, pero ayuda mucho y evita comportamientos raros.
Verificación rápida
1) El deco debe tener IP privada
En Leases de DHCP (BRIDGE_TV) debe aparecer algo tipo:
Deco: 192.168.4.11
2) Multicast entrando (cuando cambias de canal)
En consola:
tcpdump -eni igb1 'udp and dst net 224.0.0.0/4'
Si salen paquetes, la TV está llegando.
3) Ver IGMP con VLAN 838 y prioridad 4 (opcional)
tcpdump -eni igb5 -vv 'VLAN 838 and IGMP'
Deberías ver VLAN 838, p 4.
Problemas típicos y solución
"Veo canales pero el desco no tiene Internet"
Falta regla en BRIDGE_TV (permitir 192.168.4.0/24 a any).
Falta NAT outbound para 192.168.4.0/24 por WAN 832.
"Tengo Internet en el deco pero no tengo TV"
El bridge no está bien (miembros incorrectos).
VLAN 838 no está en el bridge.
El deco no está en el puerto dedicado.
PCP/prioridad no aplicada (menos común si ya te funcionaba).
"Me da miedo tocarlo"
Haz snapshot o backup de configuración antes.
Si algo falla, restauras snapshot y vuelves al estado bueno.
Resumen final
Internet: VLAN 832 en WAN (DHCP).
IPTV: VLAN 838 sin IP, solo para bridge.
Deco: puerto dedicado en bridge con VLAN 838.
IP interna del deco: en el bridge (ej. 192.168.4.1/24).
DHCP para el deco: en el bridge.
NAT + regla firewall en el bridge: imprescindible para Internet del deco.
IGMP Proxy: desactivado.
Podeis trastear ahora que no hay fútbol como hice yo, no me hago responsable si haceis algo y os quedais sin internet :)
Cualquier duda es mejor preguntar para seguir sin problemas.
Internet OK (VLAN 832) + IPTV OK (VLAN 838) sin IGMP Proxy, usando Bridge
Esta guía resuelve el problema de utilizar la mierda de routers que te dan capados y sobre todo con poca actualización
Internet por VLAN 832 funciona perfecto.
IPTV por VLAN 838 no funciona con IGMP Proxy (no llega el multicast).
Con un bridge entre el puerto del desco y la VLAN 838, la TV funciona (fútbol, directos, etc).
Los pasos clave son 2, yo estaba enfrascado con el IGMP Proxy y no hace falta para nada.
El descodificador de Orange tiene que tener una IP privada interna (la da OPNsense por DHCP, en mi caso puse la 192.168.4.1 para esa red y el DHCP dede la 10 hasta la 20, con 1 sobraba, pero bueno por poner algo).
El tráfico multicast de TV va por VLAN 838 a nivel 2 (bridge), como si fuera el router de Orange.
0) Requisitos y ejemplo de hardware
ONT: Zte F601 (o similar), la podeis encontar muy barata de segunda mano, o podeis utilizar el Livebox o lo que tengais en modo ONT, yo utilizo esa ONT por se muy pequeña y poderse esconder en cualquier sitio.
Como configurar todo con OPNsense.
Un puerto físico dedicado para el desco (ejemplo: igb1).
Mi router (mini PC tiene 5 puertos dedicados, lo que me permite poder manejar la LAN por un lado, el wifi por otro y el desco en otro y todavía me sobran 2 para futuras actualizaciones
La ONT conectada al puerto WAN físico de OPNsense (en mi caso igb5).
Ejemplo de interfaces:
igb5 → hacia ONT (tráfico etiquetado con VLAN 832 y 838). Esto para que lo entendáis es el cable que os llega de la ONT y se suele llamar WAN
igb1 → hacia el decodificador.
1) Configura Internet (VLAN 832)
Interfaces → Devices → VLAN
Crea VLAN 832 sobre igb5.
Interfaces - Assignments
Asigna esa VLAN a WAN.
You cannot view this attachment.
WAN:
IPv4: DHCP
(Opcional recomendado) Clona la MAC del Livebox si tu línea lo necesita.
Consejo: si puedes, pon la MAC clonada en el padre igb5 o al menos en la interfaz WAN.
Comprueba que Internet funciona antes de tocar IPTV.
Importante marca las opciones para bloquear la redes privadas y los bogon
2) Crea la interfaz IPTV (VLAN 838) sin IP
Interfaces - Devices - VLAN
Crea VLAN 838 sobre igb5 (recuerda tu interfaz WAN la que llega el cable de la ONT).
Interfaces - Assignments
Asigna esa VLAN a una interfaz (ejemplo IPTV_ORANGE).
IPTV_ORANGE:
IPv4: None (sin IP)
No DHCP client.
Prioridad 802.1p (PCP): 4 (Video), si tu OPNsense lo permite en la VLAN.
Nota:
En este método NO necesitas que VLAN 838 coja IP por DHCP de Orange.
NO uses IGMP Proxy.
3) Prepara el puerto del deco (sin IP)
Interfaces - Assignments
Asigna el puerto físico del deco (ej. igb1) como interfaz DECO_TV.
DECO_TV:
IPv4: None (sin IP)
No DHCP server aquí (luego irá en el bridge).
4) Crea el bridge entre el deco y la VLAN 838
Interfaces - Devices - Bridge
Añade un bridge:
Members: igb1 (DESCO) + vlan838 (IPTV_ORANGE) en mi caso, revisa el puerto que tengas asignado al deco
Interfaces - Assignments
Asigna el bridge como una nueva interfaz. Ejemplo: BRIDGE_TV.
BRIDGE_TV:
IPv4: Static
IP: 192.168.4.1/24 (o la red privada que quieras para el deco)
Importante:
La IP privada del deco debe vivir en BRIDGE_TV, no en igb1.
5) DHCP para el deco en el bridge
Services - DHCPv4 - BRIDGE_TV (yo por ejemplo utilizo KEA
Enable DHCP server
Range: por ejemplo 192.168.4.10 - 192.168.4.20
Gateway: 192.168.4.1
DNS:
Opción A (normal): tu DNS habitual (o el propio OPNsense).
Opción B (si notas cosas raras en EPG/apps): DNS de Orange que tengo yo (podéis mirar los que os sale en vuestro router antes de quitarlo y tomar nota de DNS y mac, viene todo en las pantallas del router, al menos en el Livebox)
62.36.225.150
62.37.228.20
(Opcional) NTP si quieres probar:
95.39.224.42
5.56.160.3
kea DHCP
kea dhcp datos
Services - DHCPv4 - DECO_TV (igb1)
Asegúrate de que está desactivado (no debe haber DHCP aquí).
6) NAT para que el deco tenga Internet por la WAN (VLAN 832)
Si el deco ya no tiene Internet, normalmente es por esto.
Firewall - NAT - Outbound
Modo: Hybrid (recomendado) o Manual.
Crea una regla NAT (Solamente si no ves la interfaz en las reglas automáticas):
Interface: WAN (VLAN 832)
Source: 192.168.4.0/24
Translation: WAN address
7) Reglas de firewall en BRIDGE_TV (imprescindible)
Este es el fallo típico al mover la IP al bridge: te quedas sin Internet en el desco hasta que añades regla.
Firewall - Rules - BRIDGE_TV
Regla básica para que el desco tenga Internet:
Action: Pass
IPv4
Source: BRIDGE_TV net (192.168.4.0/24)
Destination: any
Reglas multicast recomendadas:
Pass IPv4 IGMP
Source: 192.168.4.0/24
Destination: any
State type: none
Pass IPv4 UDP
Destination: 224.0.0.0/4
State type: none
Consejo de seguridad (opcional):
Bloquea acceso del desco a tu LAN (192.168.1.0/24 por ejemplo) si no lo necesitas.
Permite solo Internet y lo necesario.
8) Desactiva IGMP Proxy
Services - IGMP Proxy: Stop y deshabilitar.
Con bridge no hace falta y a veces estorba.
9) Ajustes de offload (recomendado)
Interfaces - Settings:
Disable hardware checksum offload
Disable hardware TSO
Disable hardware LRO
VLAN hardware filtering: desactivar
No siempre es obligatorio, pero ayuda mucho y evita comportamientos raros.
Verificación rápida
1) El deco debe tener IP privada
En Leases de DHCP (BRIDGE_TV) debe aparecer algo tipo:
Deco: 192.168.4.11
2) Multicast entrando (cuando cambias de canal)
En consola:
tcpdump -eni igb1 'udp and dst net 224.0.0.0/4'
Si salen paquetes, la TV está llegando.
3) Ver IGMP con VLAN 838 y prioridad 4 (opcional)
tcpdump -eni igb5 -vv 'VLAN 838 and IGMP'
Deberías ver VLAN 838, p 4.
Problemas típicos y solución
"Veo canales pero el desco no tiene Internet"
Falta regla en BRIDGE_TV (permitir 192.168.4.0/24 a any).
Falta NAT outbound para 192.168.4.0/24 por WAN 832.
"Tengo Internet en el deco pero no tengo TV"
El bridge no está bien (miembros incorrectos).
VLAN 838 no está en el bridge.
El deco no está en el puerto dedicado.
PCP/prioridad no aplicada (menos común si ya te funcionaba).
"Me da miedo tocarlo"
Haz snapshot o backup de configuración antes.
Si algo falla, restauras snapshot y vuelves al estado bueno.
Resumen final
Internet: VLAN 832 en WAN (DHCP).
IPTV: VLAN 838 sin IP, solo para bridge.
Deco: puerto dedicado en bridge con VLAN 838.
IP interna del deco: en el bridge (ej. 192.168.4.1/24).
DHCP para el deco: en el bridge.
NAT + regla firewall en el bridge: imprescindible para Internet del deco.
IGMP Proxy: desactivado.
Podeis trastear ahora que no hay fútbol como hice yo, no me hago responsable si haceis algo y os quedais sin internet :)
Cualquier duda es mejor preguntar para seguir sin problemas.
