Recent posts

#91

25.1, 25.4 Production Series / Re: WAN pppoe IP address diffe...

Last post by frozen - May 11, 2025, 07:04:22 AM

Okay and just to follow up, after more testing, so on OPNsense itself if I spawn a shell and 'curl ipinfo.io' it reports the 142.x.x.x address which does report as my correct city and all other details, but then if I simply receive a DHCP address and do a 'curl ipinfo.io' on the client -- it reports the actual correct 78.x.x.x IP!  The one that I need to be passed to my Dynamic DNS monitor.

Thanks again, sorry for the triple post

#92

25.1, 25.4 Production Series / Re: WAN pppoe IP address diffe...

Last post by hharry - May 11, 2025, 07:00:45 AM

It's more likely the pppoe interface is displaying the correct ip address as negotiated from IPCP, and that your ISP has another layer of SNAT'ing your PPPoE address to another address.

#93

25.1, 25.4 Production Series / Re: WAN pppoe IP address diffe...

Last post by frozen - May 11, 2025, 06:56:47 AM

I've even tried different check IP methods like 'icanhazip' and it STILL is reporting the 142.x.x.x IP instead of the 78.x.x.x one

So confused!

#94

25.1, 25.4 Production Series / WAN pppoe IP address different...

Last post by frozen - May 11, 2025, 06:45:18 AM

Hello, novice user here, using Bell Fiber internet in Canada.  I use OPNsense of course, completely up to date, and have think I've narrowed down my Dynamic DNS updating woes to the fact OPNsense is detecting the wrong IP address as my WAN IP!

What I mean is this

You cannot view this attachment.

If you see here, the IP is being reported as a 142.x.x.x address, which is being passed on to my Dynamic DNS client, and is unconnectable.
But when I open a terminal and do a 'curl ipinfo.io' for example, it displays my true IP which is a 78.x.x.x IP address

So I guess my question is, why?  And how do I fix it?

I need to pass on the 78.x.x.x IP to the Dynamic DNS updater, and simply choosing WAN isn't working

Thanks so much!

#95

General Discussion / IPV6 in DUAL WAN config

Last post by opensensical - May 11, 2025, 04:26:01 AM

Currently I cannot set up IPV6 because I have a DUAL WAN config because the LAN can only track one interface.
Is there a plan to enable the LAN to track the ACTIVE interface at some point?

#96

25.1, 25.4 Production Series / Re: HA The backup firewall is ...

Last post by Igor - May 11, 2025, 03:58:43 AM

Hi.
(Following this thread), to fix this here I reconfigured:

On Master:
- System > High Availability > Settings = Synchronize Config = 10.0.0.2:443  # added the :443, 10.0.0.2 = backup
- System > Settings > Administration = Listen Interfaces: All (recommended)

On Backup:
- System > Settings > Administration = Listen Interfaces: All (recommended)

#97

General Discussion / Re: Redirect DNS to pi-hole

Last post by louis_nichols - May 11, 2025, 03:00:10 AM

Thank you both for the help. I had a crazy week and only managed to try this stuff today.

Indeed, the suggestion from @viragomann did the trick. I wish I understood better why, but sometimes it's like this. :)

@ricardolanes  Indeed, that doesn't apply to me because I run dhcp from pihole, not opnsense. But I truly appreciate your support regardless.

#98

25.1, 25.4 Production Series / ISC DHCPv6 bug?

Last post by Mpegger - May 11, 2025, 02:47:32 AM

I've come across a possible bug in DNS resolution of a local LAN FQDN address using ISC DHCPv6 static assignment.

My ISP issues dynamic IPv6 GUA prefixes in the /56 range. LAN is set to Tracking, RA is set to assisted, and I have Unbound setup as the main DNS server, and ISC handling DHCP for both v4 and v6 addresses, as well as passing both dynamic and static assignment DNS information to Unbound.

I normally have IPv6 addresses given out in a certain range (isp:isp:isp:isp::xxxx) via ISC DHCPv6, but am attempting to give out a Static IPv6 address to a single server for access outside my LAN. I configured this Static setting in ISC DHCPv6 by using the 'DUID Identifier', assigning a 'IPv6 address' in the form of (::1.2.3.4) since I have a dynamic IPv6 prefix, and used the same 'Hostname' for the client that I use in the DHCPv4 configuration. The client gets both the correct IPv4 and IPv6 addresses and I am able the forward traffic from the WAN side to the server in my network using its GUA IPv6 address that I assigned it.

The problem (bug?) comes when I try to access that server in my LAN using the FQDN (not IP). I noticed it would take some seconds (sometimes well over 30 seconds) before the server would respond when I tried to connect to it. Seeing as how I had made that ISC DHCPv6 entry just before the issue started happening I ran a simple 'ping server.lan.internal', and it was trying to ping the Static IPv6 portion of the address assigned to that server, *without* the ISP assigned prefix.

Code Select Expand

ping server.lan.internal

Pinging server.lan.internal [::1.2.3.4] with 32 bytes of data:
Running a nslookup resulted in the same portion of the IPv6 being reported without the ISP assigned GUA prefix.

Removing the 'Hostname' in the ISC DHCPv6 entry, restarting ISC DHCPv6 *and* Unbound services, did not clear the DNS responce. I had to reboot Opnsense in order to clear that responce. Once rebooted I was no longer getting any IPv6 address in nslookup, but this means that if I was trying to connect to the server on my LAN using only IPv6, I'd have to use the actual IP, and wouldn't be able to use a FQDN.

TL:DR -  It seems that ISC DHCPv6 is passing a incomplete IPv6 address to Unbound when using a dynamic IPv6 entry (::a.b.c.d) along with it's 'Hostname', and it won't clear without rebooting Unbound.

#99

25.1, 25.4 Production Series / Re: 25.1.6 dnsmasq failure wg0...

Last post by peterdeg - May 11, 2025, 01:41:32 AM

Solved.
Thank you.

#100

25.1, 25.4 Production Series / Re: Floating rules for grouped...

Last post by OPNenthu - May 11, 2025, 01:37:53 AM

How are the floating allow rules supposed to work if the they are processed after the auto-generated ones (and specifically the ones that blocks everything)?

It has to do with non-Quick vs. Quick rule types, indicated by the lightning bolt.  Keep in mind the "Default deny" rule is non-Quick.

The Quick rules are evaluated first, top to bottom, and in order of precedence by their priority levels (System/auto rules -> Floating -> Group -> Interface).

If, and only if, no Quick rule was matched in any of the sections, then the non-Quick ones are evaluated (again top to bottom).  The difference is that non-Quick rules are also last-match meaning later rules overrule earlier ones.  If you have a non-Quick rule in your Interface section that matches, it will take effect even if the system level "Default deny" rule was also matched.  Last one wins.

(This is the logical behavior at least; the rules might be processed differently in code.  You could imagine that they are all processed in a single pass and exits immediately on any Quick rule match, otherwise the last matched non-Quick rule action gets applied.)

The end result is that the system level "Default deny" rule action is only ever applied if there are no other rules (Quick or non-Quick) that are matched, anywhere in the hierarchy.

If you're hitting the Default deny then it's likely you have a misconfiguration in your rules.  Can you post them here?

EDIT: Do I also need to add rules for DNS and DHCP for each zone?

If you're using ISC, it registers automatic DHCP rules.  Kea and Dnsmasq do it by default unless you disable the option in the service settings.  I think there might be a nuance with Dnsmasq where it only auto-registers the DHCP rules if you select specific listen interfaces, but won't do it if you leave it on 'All' interfaces.

DNS rules may or may not be needed, depending on how you set up your access rules and where your DNS server is.  If you have a typical "Allow any" rule and your DNS isn't on a blocked network, then probably not needed.