Menu

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.

Show posts Menu

Messages - i.schmidt

#1
Ah great! Thanks!

Thats really what I want to do. I have some services running, which are accessible to the world via IPv4, but i want to also make them available via IPv6.
I guess next, I will have to figure out, how to setup DDNS with IPv6 correctly on netcup.


Updating DynDNS seems to be somewhat straight forward, since the DDNS Service can build the new addresses automatically from the prefix.
But I can't quite wrap my head around on how to handle the dynamic addresses on my internal hosts. How to get a new IPv6 prefix on my VMs and Containers, when my public net changes? Is this done via DHCPv6, some neighbor discovery or something?
Are you aware of some good comprehensive documentation on this?
#2
Oh thats interesting. Thank you!

So if I understand you correctly: I get a GUA, which is part of my delegated prefix and i can derive my delegated prefix from my GUA?
And the DHCPv6 communication on dialup might then simply be missing, because no DHCPv6 is involved?

This is really confusing because that's almost too easy 😅, but alright. I will do some testing with this.

Just for some clarification:
Given my GUA might be 2003:db:477f:b4ff:::fe01:a3af/64
This would suggest, 2003:db:477f:b4 is my delegated prefix and i can use 2003:db:477f:b400... to 2003:db:477f:b4ff... for publicly accessible adresses?
Nice!

#3
Hi folks

Today i realized, my WAN connection does not get a prefix delegated from my ISP
I'm on 25.1.2 community and my WAN Setup works in principle.

Logical connection is like this: igc0 -> igc0_vlan7 -> pppoe0 -----> Telekom Deutschland Fibre

However, i noticed, i get a public IPv6 address, but no delegated prefix.
igc0 is not assigned, igc0_vlan 7 is not assigned, pppoe0 is, as WAN Interface with the typical config:
IPv4 -> pppoe
IPv6 -> DHCPv6
Prefix delegation size: 56
Request prefix only: true
Send prefix hint: true

On dialin i see the IPv4 Address, and an IPv6 Address, however DHCPv6 seems to fail. The log says:
<13>1 2025-05-23T18:01:13+02:00 OPNsense.localdomain dhcp6c 69030 - [meta sequenceId="8"] RTSOLD script - Sending SIGHUP to dhcp6c
<27>1 2025-05-23T18:01:13+02:00 OPNsense.localdomain dhcp6c 55977 - [meta sequenceId="9"] transmit failed: Can't assign requested address
<13>1 2025-05-23T18:01:13+02:00 OPNsense.localdomain dhcp6c 82153 - [meta sequenceId="11"] RTSOLD script - Sending SIGHUP to dhcp6c
<27>1 2025-05-23T18:01:13+02:00 OPNsense.localdomain dhcp6c 55977 - [meta sequenceId="14"] transmit failed: Can't assign requested address
<13>1 2025-05-23T18:01:15+02:00 OPNsense.localdomain dhcp6c 62732 - [meta sequenceId="47"] dhcp6c_script: REQUEST on pppoe0 executing
<13>1 2025-05-23T18:01:15+02:00 OPNsense.localdomain dhcp6c 66725 - [meta sequenceId="48"] dhcp6c_script: REQUEST on pppoe0 renewal

I found, that every interface that is involved, gets the same IPv6 link local address.
root@OPNsense:~ # ifconfig igc0
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4800028<VLAN_MTU,JUMBO_MTU,HWSTATS,MEXTPG>
        ether 00:d0:b4:01:a3:af
        inet6 fe80::2d0:b4ff:fe01:a3af%igc0 prefixlen 64 scopeid 0x1
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

root@OPNsense:~ # ifconfig igc0_vlan7
igc0_vlan7: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=4000000<MEXTPG>
        ether 00:d0:b4:01:a3:af
        inet6 fe80::2d0:b4ff:fe01:a3af%igc0_vlan7 prefixlen 64 scopeid 0x8
        groups: vlan
        vlan: 7 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

root@OPNsense:~ # ifconfig pppoe0
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: Telekom_WAN_VLAN7_pppoe (opt6)
        options=0
        inet 93.225.175.117 --> 62.155.243.104 netmask 0xffffffff
        inet6 fe80::2d0:b4ff:fe01:a3af%pppoe0 prefixlen 64 scopeid 0xf
        inet6 fe80::2d0:b4ff:fe01:a3b1%pppoe0 prefixlen 64 scopeid 0xf
        inet6 2003:db:xxxx:xxxx:xxxx:xxxx:fe01:a3af prefixlen 64 autoconf pltime 1800 vltime 14400
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

This might be, because all the interfaces share the same MAC address, so the algorithm for deriving the link local address might generate the same address for these interfaces. But, could it be, that this is a bug and having the same address on multiple interfaces prevents dhcp6c from sending the dhcpv6 requests?
I can't see ANY communication on port 547 or 546 happening on pppoe0 on dialin.

I tried to change the mac address of pppoe0 but then i get no connection established. I tried to remove the suspicious IPv6 link local address from pppoe0, but it gets reassigned as soon as i dailup the connection again, still no prefix delegation.

Is this known? Maybe I'm doing something wrong here?
Should I report this as a bug?

Any advice would be appreciated.
#4
Thanks for the instructions. I did some testing in the past with these settings and sadly i never found it working reliably. It almost never worked. Maybe this has to do with the PPPoE connection needing a VLAN tag.

I will change to letting the modems dial in and use a switch, CARP and 1:1 NAT to expose the Connection to the firewalls CARP IP.
But I need a lot of testing for that because double NAT (VOIP Server -> FW -> Modem) does not fare well with our VOIP Setup somehow. So it will take some time to do this.
#5
I found the cause of the issue.
There seems to be an issue with unreliable paket routing somewhere in the network stack of the virtualization Layer or somethin like that.
It seems like, sometimes VLAN Tags are not respected somewhere along the path between the client and the DHCP Server.
I fixed it by changing the way the DHCP Server is connected to the different VLANs. Now it has an Interface on every VLAN and we don't rely on relaying anymore. Works like a charm at the cost of some IP Addresses and configuring a bunch of interfaces.
#6
I would like to get back to this problem. I had a feeling this would bite me and I was right.

We use a HA setup. When we switch to the secondary node, we need to disable the PPPoE connection on the primary, in ordner for the secondary node to dial in. (I know this is not ideal and we are working on a solution for this)
In the past I could use the connect/disconnect buttons in the overview to do this. This had the effect, that the interface stayed up but was disconnected.
Now I need to use "disable" in the interface settings. This causes the Interface to be down. In this state the Interface cannot be used to configure e.g. an OpenVPN Server for it.

So if I am running on the secondary node and need to make a change to the config, I do this on the primary and then sync. This does not work anymore because now when I open e.g. OpenVPN configs, the binding Interface for the Service automatically jumps to the first available Interface because the PPPoE Interface isn't available anymore.

This really screws with the configuration of Services. I bet there might be some other things going wrong too.
Please consider reimplementation of "connect/disconnect" functionality for dialup Connections like PPPoE.
#7
I checked if the weird MAC address switches to the other FW by doing a manual Failover and yes, now the other FW answers with this MAC address.

Maybe CARP uses this range of MAC addresses for decoupling the CARP address from the physical interface to enable instant migration to another host?

If so, the question remains, why sometime (a lot of times) DHCPOFFER packets don't arrive at the client, when the DHCP Server clearly sends them out.
There are no blocked UDP packets on UDP Port 67/68 on the interfaces.
Additionally: Why can't I see that MAC address on any interface?
#8
So, this seems really weird and i hope it's just some misunderstanding on my side but here is the story:

For some time we had weird troubles with DHCP and DHCP relaying not working really well. Sometimes the replys didn't reach the requesting device. Very frustrating.
I started a little digging and found, that the dhcp replys were not directed at the relay server on the opnsense, but at an unknown MAC Address, 00:00:5E:00:01:0B
Digging further i found that MAC Address on the switchport that is connected to the opnsense FW, BUT none of the interfaces on the FW own that MAC Address.
When i list all MAC addresses on the FW, there is no match, see attachment 1
So I tested if i could "reach" that MAC address in the hopes that it was just some stuck address on the switches ARP Table. To my surprise something really weird came up. I used arping to send ARP requests for an IP address on the FW, on a Net that my PC is directly connected to. The firewall responded. The TCP Header in the response shows SRC MAC address is the correct interface on the FW, but the ARP reply part of that packet lists the wrong, offending MAC address as destination for that IP. See attachment 2

I have absolutely NO IDEA WTF is happening here. Rebooting the FW didn't help. Next i will try HA failover to the other FW, to see if that phenomenon persists. If not, it might be a faulty Adapter. If it persists i am truly lost.

For some more understanding of the architecture of our Network:
The FW is a virtualised system on Proxmox. The LAN facing interface is a Mellanox 10G Adapter, directly connected to the VM via PCI passthrough.
On this interface, every LAN is a VLAN interface as a child of that Mellanox Card.
We use a HA setup. Both FW consist of the same Hardware.
Every IP address on the FW is either a CARP address or a n IP Alias (if we need more than one adress on that interface) except for the IP by which we reach the Web GUI, which is a fixed address, one for master, one for slave.

Please feel free to ask any questions if something is unclear.
#9
Thanks for clarification, I thought I was missing something.
Will it come back?
It was a very nice function to easily stop and start connections when troubleshooting. Enabling and disabling the interface works, but it's less convenient.
#10
Hi

We recently upgraded from a 23 version of opnSense to the latest 24.4_5 business version. Before the update, there was an Option under "Interfaces - Overview" right of the <PPPoE IF> entry, called disconnect. Since the overview was heavily overhauled, this option seems to be gone.
Has it moved somewhere else, or do i really need to disable the pppoe interface in the interface settings?

Sometimes i just need a quick disconnect and reconnect the interface, so this is somewhat annoying.
Any tips are appreciated.
thanks!
#11
Hi all

I recently set up a single IPSec Tunnel, but when i look at the Status Overview Page, I see two Tunnels, of which one is offline. The blanked out addresses are the same on both connections. Screenshots attached.

I don't understand why that is.
Can anyone help me out?

Thanks!
#12
I have successfully reconfigured all the interfaces via the config file.
It looks like, now the states are synced properly.

Thanks!
#13
I think I found the issue.

When we first set up the HA pair, opnsense was on version 21.x something, or even version 20.
We updated, as versions rolled along and at some point I fiddled too much with the secondary device. I had to set it up entirely new.
Somewhere between major updates, the naming scheme for devices seems to have changed. So our primary device has interfaces with the old naming scheme, while the secondary device has these network devices set up with the new names.
pfsync is clearly unable to assign the synced connections to the appropriate interfaces.

So, how can i change the names of the interfaces? Do I have to delete every interface, create a new one and reassign it? Will I be able to keep all the firewall rules?

Thats really nasty  :'(
#14
True, but only if the dialup connection is handled by another router instead of the opnsense firewall.
If opnsense does the dialup, the provider will see the MAC of that interface on their endpoint.
#15
Yep, opnsense runs in a VM on that machine. Proxmox is the host OS. This makes it a heck of a lot easier to backup, restore, update and handle it.

It's the only VM on that host, because this machine is dedicated for firewall for obvious reasons.

Sadly, i can't pass-through this interface directly into the VM, because it is one port of two onboard network ports. I would loose access to the Host, if i did this.
The Onboard Controller is a Broadcom NetXtreme BCM5720 2-port Gigabit Ethernet

The other network ports for WAN an VLAN are dedicated hardware and passed through.
For completeness: There are no firewall rules applied to the VM on the host system (service deactivated. Proxmox supports firewalling)

Is it likely that the visualization layer is the culprit though?

I'm currently thinking about how i can test this... live... without making a mess during office hours ::)
LOL i could put a USB network adapter and passthrough that and see what happens.  :o ;D