I have version 24.7_5 running on a Qotom Intel processor hardware. It has connected to the Internet via an Huawei HG612 modem using PPPoE VDSL. The connection itself works fine however:
The Dashboard shows the public IP address as 195.166.130.254 which is incorrect.
Please could this issue be corrected. The router responds to pings to the correct public IP address assigned by the ISP which happens to be fixed.
Is PPPoE being done by opnsense or Huawei? If Huawei is doing it, and NAT, opnsense's "WAN" IP address will not be your public one (which you might want to verify by visiting something like https://ip4.me/).
Without knowing more about your configuration, and what address you expect to see, it's hard to say, beyond guessing...
The PPPoE is done by Opnsense. The Huawei is just a modem that connects home ethernet network to a VDSL telephone line.
Opnsense dashboard showed the correct public IP address before the upgrade to 24.7
The IP address is now shown as 195.166.130.254 which does not respond to pings from a device connected to my home network.
If I ping the correct public IP address I get a reply.
displayed WAN IP is broken in general for me. I have a full native dual-stack WAN interface, and my WAN shows a link-local IPv6 address instead of my actual public IPv6 WAN IP.
It seems like the new widget is just guessing at random which IP address to list.
First things first someone needs to tell me which widget we are talking about? Not to nitpick, but without a picture or precise reports this feels more like a rant than someone wanting to help get this fixed :)
Cheers,
Franco
Quote from: machare on July 31, 2024, 11:47:32 PM
If I ping the correct public IP address I get a reply.
How do you know that the reply is coming from your router and not someone else's? What do you get if you visit https://ip4.me/ ?
For me the widget is titled "Interfaces" and is one of the default widgets on the Lobby/Dashboard page.
I'm on 24.7_9 and can confirm that the widget only displays the link-local IPv6 addresses, though via command line I can see that public IPv6 addresses are assigned to devices, which is confirmed by https://ip6only.me.
This is what the widget looks like on all of my firewalls, so we probably need some more specifics like e.g. the details of the WAN interface configuration in the UI, to have any idea what might be going wrong.
Here's my config.
Been using OPNSense for years and can confirm that I too have the same issue which appeared with the upgrade to 24.7.
Thankfully it is only a nuisance and does not appear to break DDNS (the actual public WAN IP is still picked up by os-ddclient).
I will be on the road today and test that my WireGuard connection is not affected (but since DDNS is reporting properly I suspect no issues).
Update: This does not affect my WireGuard road warrior setup thank goodness.
With "request prefix only" to my knowledge you do not get a GUA on WAN.
I think we might be conflating issues here. The OP claims that they have a static *IPv4* address assigned by PPPoE, and that the WebUI is showing a different *IPv4* address. This seems quite different from seeing only a link-local IPv6 addresses (which may be a separate issue).
Quote from: Patrick M. Hausen on August 01, 2024, 08:13:35 PM
With "request prefix only" to my knowledge you do not get a GUA on WAN.
This is correct. And this hasn't changed in ages. You might still get a SLAAC address, but it's not very trustworthy.
Cheers,
Franco
I see what the issue is. It prints the first address, but not necessarily the primary address. Although the concept is a bit difficult especially with PPPoE. For IPv6 the widget is definitely inaccurate.
Can I get an ifconfig with the right and wrong address included?
Cheers,
Franco
Quote from: dseven on August 01, 2024, 09:19:49 PM
I think we might be conflating issues here. The OP claims that they have a static *IPv4* address assigned by PPPoE, and that the WebUI is showing a different *IPv4* address. This seems quite different from seeing only a link-local IPv6 addresses (which may be a separate issue).
Yes, sorry - wrong thread. There was another issue with someone seeing only a link-local address in the dashboard widget.
> Can I get an ifconfig with the right and wrong address included?
Nevermind, it eventually reads ifconfig which is wrong in numerous edge cases.
I'll put this on my list.
Cheers,
Franco
FYI https://github.com/opnsense/core/issues/7707
Quote from: dseven on August 01, 2024, 02:27:39 PM
Quote from: machare on July 31, 2024, 11:47:32 PM
If I ping the correct public IP address I get a reply.
How do you know that the reply is coming from your router and not someone else's? What do you get if you visit https://ip4.me/ ?
One reason is that it is a fixed IP address. It has been the same address for a few years.
Quote from: Patrick M. Hausen on August 01, 2024, 09:56:52 PM
Quote from: dseven on August 01, 2024, 09:19:49 PM
I think we might be conflating issues here. The OP claims that they have a static *IPv4* address assigned by PPPoE, and that the WebUI is showing a different *IPv4* address. This seems quite different from seeing only a link-local IPv6 addresses (which may be a separate issue).
Yes, sorry - wrong thread. There was another issue with someone seeing only a link-local address in the dashboard widget.
Does this help:
492
description: OPT1 (opt1)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a2:04:40
inet6 fe80::227c:14ff:fea2:440%igb0 prefixlen 64 scopeid 0x1
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAN (lan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a2:04:41
inet 10.0.1.139 netmask 0xffffff00 broadcast 10.0.1.255
inet6 fe80::227c:14ff:fea2:441%igb1 prefixlen 64 scopeid 0x2
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: OPT2 (opt2)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a2:04:42
inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::227c:14ff:fea2:442%igb2 prefixlen 64 scopeid 0x3
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a2:04:43
media: Ethernet autoselect
status: no carrier
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
pfsync0: flags=0 metric 0 mtu 1500
options=0
maxupd: 128 defer: off version: 1400
syncok: 1
groups: pfsync
pflog0: flags=20100<PROMISC,PPROMISC> metric 0 mtu 33152
options=0
groups: pflog
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1484
description: WAN (wan)
options=0
inet 80.229.30.223 --> 195.166.130.254 netmask 0xffffffff
inet6 fe80::227c:14ff:fea2:440%pppoe0 prefixlen 64 scopeid 0x9
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ovpnc1: flags=1008051<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 10.0.8.2 --> 10.0.8.1 netmask 0xffffffff
inet6 fe80::227c:14ff:fea2:440%ovpnc1 prefixlen 64 scopeid 0xa
groups: tun openvpn
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
Opened by PID 41940
wg1: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 10.0.7.2 netmask 0xfffffff0
groups: wg wireguard
nd6 options=103<PERFORMNUD,ACCEPT_RTADV,NO_DAD>
wg2: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 10.0.9.1 netmask 0xfffffff0
groups: wg wireguard
nd6 options=103<PERFORMNUD,ACCEPT_RTADV,NO_DAD>
machare@OPNsense:~ $
Thanks. The issue seems clear now. It's fixed in the development version but I can't provide an easy fix as this required a number of commits, backend command restart and JS update in order to work as expected. It will be shipped in 24.7.1.
Cheers,
Franco
@franco
Thank you, it is only a cosmetic issue. I am glad that the PPPoE itself still works as it was quite difficult to do this originally. :)
True. PPPoE has never been easy. ;)
Cheers,
Franco
So while I figured this was an issue for me as well it turns out it may just be a misunderstanding.
The default widget showing the WAN interface is called Gateways.
What I needed to see my ISP supplied public address was the Interfaces widget.
Once I loaded that widget it showed the proper WAN address on my PPPoE connection.
That raises the question on choice of default widgets...doesn't interfaces seem more appropriate for most users than Gateways?