I am once again working toward getting DS-Lite operating.
(And I have acquired a second device so that I can test and roll-back much more easily than before).
As per the release note I saw for 23.7.6; that
Quote from: https://forum.opnsense.org/index.php?topic=36386.msg177536#msg177536This update is a maintenance release improving the DS-Lite use via separate
GIF tunnels on top of IPv6-only connectivity.
And the referral from https://twitter.com/opnsense/ that I should follow my previous work to get it happening.
https://twitter.com/opnsense/status/1739902581055377705
https://forum.opnsense.org/index.php?topic=27935.msg136305#msg136305
Following this through (testing on OPNsense 23.7.10_1-amd64), I have found that the DS-Lite GIF tunnel does not connect instantly.
And in my case it does not connect without disabling and re-enabling the DS-Lite GIF interface after the parent WAN IPv6 interface is established.
Disabling and re-enabling the DS-Lite GIF interface after the parent WAN IPv6 interface is established does seem to reliably establish DS-Lite connectivity.
(But requiring manual intervention to establish the connection - ie after a power failure is a not an option for me in production).
@opnsense on Twitter told me
QuoteYes it was missing an external connection trigger like a DHCPv6 renew. Now it should be up instantly (the IPv4 part).
Yet this does not seem to be the case.
Am I missing something or doing something wrong?
Is there a way I should be generating debugging or error data to diagnose this?
This currently works in my test environment, no intervention is required after a reboot. There have indeed been significant improvements since your last attempt.
You might want to share details about your configuration, maybe I can reproduce it.
Cheers
Maurice
Thanks Maurice.
I am testing on a fresh install of 23.7 updated to 23.7.10_1.
This is on a Celeron J4125 with 12 gb of RAM with four Intel I225-V NICs.
Connecting to an NTT GE-PON ONU.
(My working set up is the same, but that OPNsense is far more heavily configured for our LAN environment. And OPNsense connects DHCP to a FriendlyElec R4S running OpenWRT which maintains the DS-Lite connection through the NTT GE-PON ONU).
What specifically should I detail for you?
wan and gif interface settings, gif tunnel settings, gateway settings.
Here are screen captures of the WAN and GIF Interface settings
I don't know if there's a more concise way I could get this data from the CLI? I can't add all the screen captures together as the attachments are too large for the forum.
Here are the GIF Tunnel Settings and the GIF Gateway Settings.
The GIF Remote Address is the IPv6 address for the AFTR host for our ISP dgw.xpass.jp
I wonder, could you make the screenshots a bit bigger? Like, 8K or so at least. ::)
I have no idea what the forum is doing to these images. They're straight screen captures from Brave on MacOS.
Here they are again down sized.
Untick the block bogons/private networks and try again?
Your settings work fine in my test environment. The GIF tunnel gets configured automatically once the WAN is up.
The GIF interface reconfiguration is triggered by rc.newwanipv6 when the WAN interface gets a new IPv6 address. You might want to check the log for rc.newwanipv6. Do you get your WAN address via DHCPv6 or SLAAC?
System > Log Files > Backend, Boot, General have no mention of rc.newwanipv6
Do you want me to look elsewhere?
System > Log Files > General; filtering for 'wan' (showing a period when plugging in the ONT to OPNsense already running (DS-Lite did not connect), then manually disabling and re-enabling the GIF interface (which made the DS-Lite connection work), then a reboot afterwhich DS-Lite was down again)
2024-01-04T00:08:28 Notice kernel <118> WAN (igc1) -> v4: 127.0.0.2/32
2024-01-04T00:08:28 Notice kernel <118> DSLiteWAN (gif0) ->
2024-01-04T00:08:24 Notice kernel <118>>>> Invoking start script 'newwanip'
2024-01-04T00:08:20 Notice kernel <118>Configuring WAN interface...
2024-01-04T00:08:19 Notice kernel <118>Configuring DSLiteWAN interface...done.
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : webgui_configure_do(,opt1))
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : vxlan_configure_do())
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : unbound_configure_do(,opt1))
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : openssh_configure_do(,opt1))
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : opendns_configure_do())
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : ntpd_configure_do())
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : dnsmasq_configure_do())
2024-01-04T00:03:01 Notice opnsense /interfaces.php: plugins_configure newwanip (,opt1)
2024-01-04T00:03:00 Notice opnsense /interfaces.php: ROUTING: configuring inet6 default gateway on wan
2024-01-04T00:02:58 Notice opnsense /interfaces.php: plugins_configure monitor (execute task : dpinger_configure_do(,DS-WAN))
2024-01-04T00:02:58 Notice opnsense /interfaces.php: plugins_configure monitor (,DS-WAN)
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : webgui_configure_do(,opt1))
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : vxlan_configure_do())
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : unbound_configure_do(,opt1))
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : openssh_configure_do(,opt1))
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : opendns_configure_do())
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : ntpd_configure_do())
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (execute task : dnsmasq_configure_do())
2024-01-04T00:02:48 Notice opnsense /interfaces.php: plugins_configure newwanip (,opt1)
2024-01-04T00:02:48 Notice opnsense /interfaces.php: ROUTING: configuring inet6 default gateway on wan
It really seems like all the settings are as the need to be to connect but the GIF interface is not being brought up without manual intervention.
No rc.newwanipv6 in System: Log Files: General is really strange. You do get a /64 prefix delegation via DHCPv6? Your configuration implies that you also get the WAN address via DHCPv6; is that actually the case? Or is there SLAAC involved? What about IPv6 DNS servers?
You might want to post a screenshot of Interfaces: Overview: WAN with as little obfuscation as you feel comfortable with.
Sorry, late to the party. It looks like IPv6 is not kicking in when it should... which is strange for DS-Lite because it's required to establish any connectivity. ;)
But you're in good hands with Maurice on the job.
Cheers,
Franco
Thank you both.
Maurice, here's the details of the IPv6 connection from the OpenWRT shim I use upstream of my in-service OPNsense:
Protocol: DHCPv6 client
Address: 2001:XYY:ZXXX:ZYXX:ZXYZ:XZYY:XZYX:ZXYY/64
Gateway: fe80::225:84ff:fe11:dac1
DNS 1: 2001:a7ff:5f01::a
DNS 2: 2001:a7ff:5f01:1::a
(I think the public IPv6 is all I should be worried to redact. Is that correct?)
So it appears I am being served a DHCPv6 address and IPv6 DNS servers with a /64 prefix.
I can see anythiing regarding SLAAC being involved.
(As an aside; I am unclear as to whether the /64 means I should have over eighteen quintillion addresses I can use internally or that I have one address from an over eighteen quintillion address pool the ISP has. IPv6 is still frustratingly unclear to me).
I will reconnect the testing OPNsense and get that screenshot of Interfaces > Overview > WAN for you shortly.
Here's the Interfaces > Overview > WAN from the testing OPNsense connected directly to the ONT.
It is getting obscured by the small resolution on the machine I'm testing with and the header and footer being rendered into frame by the browser. Sorry I don't have an easy way to get all the data on screen at once yet. Do you need the In/out packets (block) details?
OPNsense has no delegated IPv6 prefix, no DNS servers and a SLAAC WAN address. Are you sure your ISP actually uses DHCPv6? You might want to check the log for dhcp6c.
Btw, the static IPv4 workaround is no longer required, DHCPv6-only WAN is now supported.
OK, I think you're on to something. Thanks again.
If I reconfigure WAN to have IPv4 set to none and IPv6 set to SLAAC we get DNS servers in the Interfaces > Overview > WAN
(Seems really weird though that OpenWRT is set to DHCPv6 and it brings up the IPv6 interface with DNS and the tunnel seemingly without hesitation)
Reconfiguring the interfaces seems to get DS-Lite to come up too.
But if I reboot with SLAAC configured, DS-Lite does not come up and we have no connection (I don't know why IPv6 on it's own doesn't work).
Ah... OpenWRT somehow includes SLAAC for interfaces set as DHCPv6
https://openwrt.org/docs/guide-user/network/ipv6/configuration
So I guess between that and what we saw from OPNsense with WAN set as SLAAC, that my ISP is actually using SLAAC.
Would you agree?
Some ISPs use SLAAC for letting the router autoconfigure a WAN address. This seems to be the case here. But DHCPv6 is still required for prefix delegation (and autoconfiguring DS-Lite on consumer routers). So it seems unlikely that your ISP doesn't use DHCPv6 at all. I'd increase the dhcp6c log level to see what's actually going on, and / or perform a packet capture.
With your current setup involving the OpenWrt "shim", how did you get IPv6 working in the OPNsense LAN(s)? Does OpenWrt acquire a prefix from your ISP and perform downstream prefix delegation to OPNsense?
Sorry I've been absent Maurice.
I don't use IPv6 inside my LAN so I'm not sure.
I updated my test device to 24.1.2 and while the failure to establish the DS-Lite connection continues resolving it now does not happen by disconnecting the WAN and reconnecting it. But rather by disconnecting the DS-Lite interface and reconnecting it.
I also noticed that there's something going on with the dhcp6 server seemingly in concert with the DS-Lite tunnel's connection.
I captured a slab of logs from boot through restarting the interfaces until DS-Lite was active in case they can be diagnostic. But this forum will not let me post that much text.
Adding to this thread since I am trying to do the same thing, but I have a somewhat different issue with the GIF tunnels. I am configuring the GIF tunnel using 192.0.0.1 as remote, 192.0.0.2 as local, but when I save, the logs get the following error:
<13>1 2024-04-23T21:19:35+09:00 opnSense.localdomain.com opnsense-devel 53233 - [meta sequenceId="43"] /usr/local/etc/rc.newwanipv6: Device gif0 missing required local address, skipping now.
Weirdly, if I set it manually using the info (https://forum.opnsense.org/index.php?topic=27935.msg136305#msg136305) from DanAnimal's thread from a couple of years ago,
- 2001:f74 is the IP that is allocated to opnSense by the NEC ONU device (from ifconfig)
- 2001:f60 is the AFTR address of dgw.xpass.jp - the ISP to whom the link goes
ifconfig gif0 inet6 tunnel 2001:f74:xxx:xxx:xxx:xxx:xxx:xxx 2001:f60:0:200::1:1 mtu 1460 -accept_rtadv ifdisabled
ifconfig gif0 inet 192.0.0.2 192.0.0.1 netmask 255.255.255.248
route add default -interface gif0
If I do this, it immediately begins working (but, of course, does not survive a reboot).
I did everything else as posted in the above post, but I think I am stuck on this "gif0 missing required local address". Would anyone know what's going on here, or what can I post?
I am on OPNsense 24.7.a_388-amd64.
As far as I remember, "gif0 missing required local address" means the interface you selected as the parent interface doesn't have a valid IPv6 address. How is 2001:f74:xxx:xxx:xxx:xxx:xxx:xxx assigned to the WAN interface? SLAAC? DHCPv6?
Ooh, that is interesting. Indeed, I don't have one assigned - the LAN side gets one via Track Interface (and it's actually the same IP that the _WAN_ side was getting when I was running OpenWRT), but for some reason WAN doesn't. It's supposed to be DHCPv6, but as DanAnimal found above, there's some weirdness about how the provider does it - there seems to be SLAAC involved but setting WAN interface to SLAAC makes connectivity fail completely. I currently have it set to DHCPv6, I do _not_ have "request prefix only" checked, and its working - WAN interface is unassigned, LAN interface has the correct IP.. It's almost as if the IP is being assigned to the LAN side _instead_ of WAN. How can I try to fix this?
DanAnimal did have a SLAAC WAN address, but you don't seem to have a WAN address at all. It's possible that your ISP supports DHCPv6 Prefix Delegation (which is used for the LANs), but doesn't assign a WAN address (no DHCPv6 IA_NA, no SLAAC). Unfortunately, OPNsense can't use the delegated prefix for creating a WAN address - the WAN interface can't track itself. OpenWrt might support this (not sure), this might be the reason why you had a WAN address there.
Does your delegated prefix change frequently? If not, you could add a virtual IP to the WAN interface. What prefix length do you get?
You'll really have to dig deeper there. Check the DHCPv6 logs, perform a packet capture, look at RAs. Very few people here (if any) will have a deeper understanding of how Japanese ISPs do things. You could try the Japanese forum (https://forum.opnsense.org/index.php?board=13.0), but it's essentially dead.
Sadly, you're quite right - nobody really knows how things are done in Japan (believe me, not just ISPs :D). My /56 never changes - I'm sure it's "dynamic" but it's quite sticky. I don't mind assigning an IP manually even if I have to put a PostIt note to "in case of outage, check subnet" - but is it a question of just setting to static IP from the same /56, or assigning a fake one, or what should I try?
Most ISPs require you to frequently renew your Prefix Delegation via DHCPv6, even if it rarely or never changes. If you don't, it eventually expires. So the WAN interface should be set to DHCPv6.
If you get a /56 which (almost) never changes, but don't get a WAN interface address at all, try this:
Let's say your delegated prefix is 2001:db8:abcd:ef00::/56.
Go to Interfaces: Virtual IPs: Settings, add an address, interface WAN, address 2001:db8:abcd:ef00::1/128.
If one of your LAN interfaces uses the IPv6 Prefix ID 0 and you don't want to change this, you can use a different one for the WAN, like 2001:db8:abcd:efff::1/128.
Thanks very much. Tried this, and it did configure an IP for my ix0 WAN side:
ix0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1460
description: WAN (wan)
options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,NOMAP>
ether ac:bd:ca:fe:de:ad
inet 127.0.0.2 netmask 0xffffffff broadcast 127.0.0.2
inet6 fe80::9e69:b4ff:fe63:6437%ix0 prefixlen 64 scopeid 0x2
inet6 2001:f74:xxxx:yyyy:zzzz:aaaa:dead:cafe prefixlen 128
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
But sadly, gif0 did not come up - even tried rebooting, but still got the same error about missing required local address. Went back to the settings and tried to save, and same error.
Is there any way to stuff the gif0 script into /usr/local/etc/rc.syshook.d/start/ or something? I don't mind hacking this in a less-than-beautiful way as long as it works (I do have an ipsec tunnel that needs to come up, though - and currently, because gif0 doesn't come up, ipsec is forever idle, so if I do a manual hack, it would need to be in the boot process after ix0 comes up but before ipsec does).
It's possible that we don't allow the gif source address to be an IP alias, not sure. I'll try to find out and will report back. If so, we might want to fix this.
But the best solution would still be to allow a WAN interface to track itself. This has been requested and discussed before, but turned out to be harder than expected (as far as I remember). Since "PD only" doesn't seem to be that rare and a WAN interface without a GUA is such a pita, this might deserve another attempt.
By the way, the dummy IPv4 address shouldn't be required anymore, "none" is fine. The bug that made this necessary has long been fixed.
Understood, thanks. I'm going to guess that with all the stuff yall have to do, pandering to weird Japanese setups isn't going to be _too_ high on the list, hehe ... Is there anything I can do in the meantime as far as a manual hack goes? I suppose I could write some kind of a script that runs as a cron job or something, but ideally I want to just patch into the boot process somewhere.
[edit] browsing through forums, I came across a, what I think, was a similar issue:
https://forum.opnsense.org/index.php?topic=35876.0
and there was a patch issued,
https://github.com/opnsense/core/commit/315153a07
Was this ever deployed into subsequent releases? I looked through src/etc/inc/interfaces.inc and I don't think I see the code referenced in that patch, and it's for an older version, so I don't know if I should risk it or not.
[edit] one more edit. i managed to make it come up on boot by editing 10-newwanip, adding a sleep timer of 30 seconds (to allow WAN to come up), doing the gif config, and then adding a new script all the way at the end of the boot, doing another 10 second sleep, and adding a configctl service restart strongswan to restart the IPSec tunnel. This survived the last two reboots, so it might be an OK hack at the moment. :)
The code on master branch was changed slightly, but 24.1.x still has the adjusted code from that commit. And the master branch changes are cosmetic just for the MVC/API conversion of the GUI parts of GIF and GRE.
I'll note again that SLAAC is problematic being stateless which also means nothing tracks its state in the system so addresses come and go at no notice and finding a trigger here is difficult. Netlink may provide help here but it would still require a daemon or cron job to be executed figuring all this out what to do (reload, flush stale addresses, which interfaces to look at even).
Cheers,
Franco
Quote from: Maurice on April 26, 2024, 03:20:38 AM
But the best solution would still be to allow a WAN interface to track itself. This has been requested and discussed before, but turned out to be harder than expected (as far as I remember).
The issue was dhcp6c refusing to do it even if configured. I can look at the code again just to be sure.
Cheers,
Franco
Aha, here is the rub-in:
https://github.com/opnsense/dhcp6c/blob/master/prefixconf.c#L204-L210
The requesting router MUST NOT assign any delegated
prefixes or subnets from the delegated prefix(es) to
the link through which it received the DHCP message
from the delegating router.
[RFC3633 Section 12.1]
Discuss!
Somehow the logging is off but in foreground mode you get the message...
Apr/26/2024 09:32:24: create a prefix 2003:xxxx:xxxx:xxxx::/61 pltime=3600, vltime=7200
Apr/26/2024 09:32:24: add an address 2003:xxxx:xxxx:xxxx::/64 on igb0
Apr/26/2024 09:32:24: skip igb1 as a prefix interface
No response, boring topic? ;)
"MUST NOT" is unambiguous - discussion over. ;)
But if we leave this as is, then (in the extreme) nobody in Japan can use Opnsense directly attached to an ONU device (and if behind an ISP-provided router, then you need to do IPv6 NAT, since only a /64 subnet is assigned to each device), so anything we can do to solve this?
I fixed my issue in the meantime with some really rough hacks (sleep()'ing on boot and bouncing the interface a few times), but this is a really lame hack, not to mention that I make the assumption my subnet won't change, so as soon as it does (and obviously I will happen to be away from my router RIGHT at that moment, lol) it will not come up. Would really love something more reliable as far as a solution goes.
Quote from: franco on April 26, 2024, 09:19:05 AM
Aha, here is the rub-in:
https://github.com/opnsense/dhcp6c/blob/master/prefixconf.c#L204-L210
The requesting router MUST NOT assign any delegated
prefixes or subnets from the delegated prefix(es) to
the link through which it received the DHCP message
from the delegating router.
[RFC3633 Section 12.1]
Discuss!
Somehow the logging is off but in foreground mode you get the message...
Apr/26/2024 09:32:24: create a prefix 2003:xxxx:xxxx:xxxx::/61 pltime=3600, vltime=7200
Apr/26/2024 09:32:24: add an address 2003:xxxx:xxxx:xxxx::/64 on igb0
Apr/26/2024 09:32:24: skip igb1 as a prefix interface
I remember the attempt to make that work (https://github.com/opnsense/core/issues/5630), because I have that type of ISP as well. I just use the LAN GUA to make IPv6 work on the OpnSense itself.
So it seems obvious why dhcpdc could not be convinced to use part of the PD prefix for the WAN interface itself. You cannot argue with an RFC, albeit it would be nice to ignore it like apparently AVM's Fritzboxen do...
;-)
Quote from: jbourne on May 06, 2024, 09:10:52 AM
But if we leave this as is, then (in the extreme) nobody in Japan can use Opnsense directly attached to an ONU device (and if behind an ISP-provided router, then you need to do IPv6 NAT, since only a /64 subnet is assigned to each device), so anything we can do to solve this?
You do not need a GUA on WAN. And you can NAT outbound packets on WAN to e.g. "LAN address" so the firewall itself can use IPv6.
Quote from: Patrick M. Hausen on May 06, 2024, 09:15:41 AM
You do not need a GUA on WAN. And you can NAT outbound packets on WAN to e.g. "LAN address" so the firewall itself can use IPv6.
Sure, but how to set that up? At the moment it does not seem like any way of configuring it makes it work other than manually configure the GIF interface like I posted above - and that doesn't work automatically. Sorry, I might also be a little slow as I'm not used to v6 networking. I miss the old days of plugging a wire into a wall port and just having DHCP give you an IP that never changed, with no ports blocked. sigh.
Quote from: Patrick M. Hausen on May 06, 2024, 09:15:41 AM
Quote from: jbourne on May 06, 2024, 09:10:52 AM
But if we leave this as is, then (in the extreme) nobody in Japan can use Opnsense directly attached to an ONU device (and if behind an ISP-provided router, then you need to do IPv6 NAT, since only a /64 subnet is assigned to each device), so anything we can do to solve this?
You do not need a GUA on WAN. And you can NAT outbound packets on WAN to e.g. "LAN address" so the firewall itself can use IPv6.
You do not need NAT for IPv6, just assign and use the LAN GUA. And in firewall rules, you can use "this firewall" or the dynamic IPv6 of the LAN interface. I do it since that discussion long ago. Not sure about GIF interfaces, though.
Quote from: Patrick M. Hausen on May 06, 2024, 09:03:15 AM
"MUST NOT" is unambiguous - discussion over. ;)
Yes, in the RFC3633 which got obsoleted by RFC8415 which doesn't have such a restriction as far as I could find.
I did test it without the code and it works... it would be optional anyway.. so I'm merely looking for an expert opinion WRT RFC8415.
Maurice, where are you? ;)
Cheers,
Franco
Quote from: meyergru on May 06, 2024, 09:21:31 AM
You do not need NAT for IPv6, just assign and use the LAN GUA. And in firewall rules, you can use "this firewall" or the dynamic IPv6 of the LAN interface. I do it since that discussion long ago. Not sure about GIF interfaces, though.
How do you make outbound traffic, e.g. NTP, DNS, download of updates ... from the firewall itself use that address? Will that happen automatically, i.e. will the services use the only GUA locally bound if there is only one?
Quote from: Patrick M. Hausen on May 06, 2024, 09:33:00 AM
Quote from: meyergru on May 06, 2024, 09:21:31 AM
You do not need NAT for IPv6, just assign and use the LAN GUA. And in firewall rules, you can use "this firewall" or the dynamic IPv6 of the LAN interface. I do it since that discussion long ago. Not sure about GIF interfaces, though.
How do you make outbound traffic, e.g. NTP, DNS, download of updates ... from the firewall itself use that address? Will that happen automatically, i.e. will the services use the only GUA locally bound if there is only one?
Yes, that happens automagically. However, you have no "direct" control over which interface is being used for outbound traffic if you have more than one (V)LAN GUA - it seems just arbitrary. Not that it matters much for outbound traffic, apart from dynamic DNS.
For that, I have my own dyndns service which mixes the received traffic with a configurable suffix and length. Aus such, it would not matter which of the interfaces gets used, since they all share the same (/56) prefix.
Quote from: franco on May 06, 2024, 09:25:52 AM
Quote from: Patrick M. Hausen on May 06, 2024, 09:03:15 AM
"MUST NOT" is unambiguous - discussion over. ;)
Yes, in the RFC3633 which got obsoleted by RFC8415 which doesn't have such a restriction as far as I could find.
I did test it without the code and it works... it would be optional anyway.. so I'm merely looking for an expert opinion WRT RFC8415.
Maurice, where are you? ;)
Cheers,
Franco
If the old RFC has been revised in that respect, and thinking about the restriction,
I fail to see why it exists in the first place (but I am by no means an expert). As I said, Fritzboxen did not care anyway which it probbaly why some german ISPs did not bother to hand out a IA_NA.
So if it is possible to implement it, you would probably have a checkbox to enable it anyway and you could add a warning in its help text, so I am all for it.
> If the old RFC has been revised in that respect, and thinking about the restriction, I fail to see why it exists in the first place (but I am by no means an expert). As I said, Fritzboxen did not care anyway which it probbaly why some german ISPs did not bother to hand out a IA_NA.
The point is probably not why the restriction existed, but rather if something similar or broader or narrower is still in place in the new RFC or if it does not care at all.
> So if it is possible to implement it, you would probably have a checkbox to enable it anyway and you could add a warning in its help text, so I am all for it.
The way the code back then worked is offer a prefix ID input which is optional. So we don't even start tampering with existing setups.
Cheers,
Franco
I have read RFC8415 and the referenced RFC7084. I understand it as follows...
RFC8415 Section 12.2 explicitely states that:
Quote
An IA_PD is different from an IA for address assignment in that it does not need to be associated with exactly one interface. One IA_PD can be associated with the client, with a set of interfaces, or with exactly one interface. A client configured to request delegated prefixes must create at least one distinct IA_PD.
It then talks about downstream interfaces, but never forbids to use IA_PD GUAs for the WAN interface.
But what is way more interesting is this part in RFC7084 (which, according to RFC8415 section 6.4 "describes requirements and network architecture for Customer Edge Routers"):
Quote
WAA-6: If the IPv6 CE router receives a Router Advertisement
message (described in [RFC4861]) with the M flag set to 1,
the IPv6 CE router MUST do DHCPv6 address assignment
(request an IA_NA option).
WAA-7: If the IPv6 CE router does not acquire a global IPv6
address(es) from either SLAAC or DHCPv6, then it MUST create
a global IPv6 address(es) from its delegated prefix(es) and
configure those on one of its internal virtual network
interfaces, unless configured to require a global IPv6
address on the WAN interface.
From my understanding, this not only
allows, but
requires ("MUST") the customer router to use one of the IA_PD prefixes for its WAN if none is give via IA_NA. This seems logical considering the fact that a combination where a IA_NA is not requested, but a IA_PD is (or if an ISP does not hand out IA_NA GUAs) is possible at all. So it seems, Fritzboxen are correct to use IA_PD instead of IA_NA if the latter is not provided.
That being said, the bit about RFC3633 Section 12.1 being abolished is not explicitely noted in RFC8415 section 25 "Obsoleted mechanisms".
Also, in RFC6603, in section 3, with reference to the now obsolete RFC3633, it says:
Quote
DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] has an explicit
limitation described in Section 12.1 of [RFC3633] that a prefix
delegated to a requesting router cannot be used by the delegating
router. This restriction implies that the delegating router will
have two (non-aggregatable) routes towards a customer: one for the
link between the requesting router and the delegating router, and one
for the customer site behind the requesting router.
There are architectures and link models where a host (e.g., a mobile
router, also acting as a requesting router) always has a single (/64)
prefix configured on its uplink interface and the delegating router
is also the requesting router's first-hop router. Furthermore, it
may be required that the prefix configured on the uplink interface
has to be aggregatable with the delegated prefixes. This introduces
a problem in how to use DHCPv6-PD together with stateless [RFC4862]
or stateful [RFC3315] address autoconfiguration on a link where the
/64 advertised is also part of the prefix delegated (e.g., /56) to
the requesting router.
So the limitation seems to originate in the ambiguity of "on-link" connections and "routed" connections sharing the same IPv6 PD prefix, which might cause routing problems with certain providers (however, I thought that only link-local IPs were used for on-link connections). Thus, if at all implemented, I would still not use this as a default.
Maybe someone more knowledgable than me might chime in?
Thanks, @meyergru! Also consider that an explicit assignment of a single address from a LAN /64 to a different interface is possible if a prefix length of /128 is used.
We use this for all our hosts at Hetzner who also give us a single /64 per server by default.
<prefix>::1/128 goes to the outside interface of the host (with a link-local default gateway, of course - fe80::1).
<prefix>::2/64 goes to "jail0" which is an isolated bridge interface without any external interface as a member. This address acts as the default gateway for all the VNET jails connected to that bridge.
<prefix>:<random address for jail>/64 goes to the individual jails.
So you could e.g. use the WAN MAC address to create a GUA from the prefix in SLAAC style and assign it as /128.
Kind regards,
Patrick
> So you could e.g. use the WAN MAC address to create a GUA from the prefix in SLAAC style and assign it as /128.
I was actually considering taking a /64 from the PD for WAN and only assigning a /128 instead of a /64 to work around this limitation, but the delegation in dhcp6c only works with prefixes as narrow as /64.
Thanks for your input so far. I also tend to agree that the limitation no longer applies and I'll consider patching dhcp6c for 24.7 and bringing back the WAN tracking code.
Cheers,
Franco
I'll be glad to test it. There will be a few hurdles (https://github.com/opnsense/core/issues/5630#issuecomment-1090815182), of course...
PPPoE specific fails are not on my panic list today ;)
Cheers,
Franco
FWIW I am happy to test as well in the weird environment that Japanese IPv6 is, if that is helpful. Especially since I'm the one who revived this thread ;D
Quote from: jbourne on April 26, 2024, 03:44:17 AM
Understood, thanks. I'm going to guess that with all the stuff yall have to do, pandering to weird Japanese setups isn't going to be _too_ high on the list, hehe ... Is there anything I can do in the meantime as far as a manual hack goes? I suppose I could write some kind of a script that runs as a cron job or something, but ideally I want to just patch into the boot process somewhere.
[edit] browsing through forums, I came across a, what I think, was a similar issue:
https://forum.opnsense.org/index.php?topic=35876.0
and there was a patch issued,
https://github.com/opnsense/core/commit/315153a07
Was this ever deployed into subsequent releases? I looked through src/etc/inc/interfaces.inc and I don't think I see the code referenced in that patch, and it's for an older version, so I don't know if I should risk it or not.
[edit] one more edit. i managed to make it come up on boot by editing 10-newwanip, adding a sleep timer of 30 seconds (to allow WAN to come up), doing the gif config, and then adding a new script all the way at the end of the boot, doing another 10 second sleep, and adding a configctl service restart strongswan to restart the IPSec tunnel. This survived the last two reboots, so it might be an OK hack at the moment. :)
Updating my own post. Adding it to 10-newwanip survived reboots, but didn't survive a firmware update (duh, I suppose), and I forgot that I did it, so everything fell apart again. Adding it to a _new_ script did not work, I have no idea why.
So I fortunately remembered to revisit this thread and see my notes on it, but I guess I will stop updating the firmware because it's just going to break everything again.
Quote from: jbourne on May 26, 2024, 04:57:04 AM
Adding it to a _new_ script did not work
No executable permission most likely.
Quote from: franco on May 26, 2024, 12:49:01 PM
Quote from: jbourne on May 26, 2024, 04:57:04 AM
Adding it to a _new_ script did not work
No executable permission most likely.
Haha. That would've been too easy. No, exec perms are on. I have the GIF tunnel as part of 10-newwanip and 93 for ipsec restart (I have an ipsec tunnel I absolutely must have on boot). If I put the gif code with a 30 sec sleep followed by strongswan restart into 93, it does not work. If I put the GIF config code into 10 with a 30 sec sleep and then separately leave the strongswan restart in 93, it works. No idea why.
https://github.com/opnsense/core/issues/5630
Revived this for 24.7... stay tuned.
Sweet! Thank you very much. I'll watch that thread and this one also for when it makes it into beta so I can switch branches and test.
Ah, another expected, but unwelcome, side effect of the status quo: WAN interface does not get a IPv6 IP, so if you want a dynamic IPv6 host alias for firewall rules, that does not work. Have to use LAN interface as "source" under Firewall > Aliases, and I don't know if that's safe to use or not, but it seems to work for now.
It's safe and relatively normal. But the code for a prefix subnet on WAN is tested and works. We even added a way to define the suffix part of the address statically instead of using the MAC/EUI-64 format.
The plan is to offer the GUI knobs for 24.7 but bring in the latest fixes for the dhcp6c client in 24.1.9.
Cheers,
Franco
Cool. That's good to hear. Can I deploy that via the beta tree or it's not published yet?
Command to test was posted here: https://github.com/opnsense/core/issues/5630#issuecomment-2154825737
Cheers,
Franco
Quote from: franco on June 10, 2024, 01:21:53 PM
Command to test was posted here: https://github.com/opnsense/core/issues/5630#issuecomment-2154825737
Cheers,
Franco
Oops I totally missed that thread. I will check it, patch, and see how it goes. Thanks!
Great, all feedback welcome. Maybe just as a reminder it needs a reboot to make use of the newer dhcp6c or you have to kill the previous one and then apply the interface configuration again.
# killall dhcp6c
Cheers,
Franco
Quote from: franco on June 10, 2024, 01:35:12 PM
Great, all feedback welcome. Maybe just as a reminder it needs a reboot to make use of the newer dhcp6c or you have to kill the previous one and then apply the interface configuration again.
# killall dhcp6c
Cheers,
Franco
Anything I should change about the GIF tunnel etc? I'm assuming I should undo the static config I put into 10-wanip but anything else I should change?
Entirely unsure. I cannot test this easily. Sorry.
Cheers,
Franco
Quote from: franco on June 10, 2024, 02:08:17 PM
Entirely unsure. I cannot test this easily. Sorry.
Cheers,
Franco
Hahaha no worries, I will revert back!
Did this break for anyone with the 24.7 update? It was working perfectly up till yesterday when I wanted to install tailscale, and was told that 24.1 is too old - so I ran the upgrade and everything broke. Now the GIF tunnel no longer auto starts and I have to go back to my manual hack solution. Did anything change?
The GIF integration was moved to MVC which also entailed a few changes in the backend code. I'm not sure what it could be. There is the likelihood of a gif-related error in the system log?
Cheers,
Franco
Hello everyone,
sorry for hijacking the post.
I'm trying to setup DS-Lite and even following all the guides and forums I found
I can't get it working.
As a background, I live in Japan and I'm using Excite Mec Hikari as a provider,
so DS-Lite is necessary.
I already have a Yamaha router, which I was able to setup without problems,
but since I want to learn OPNSense I decided to set it up as well.
Still an extreme noob tho, so please forgive me in advance.
So, looking at guides and here I did the followings:
Note: OPNSense is running on Proxmox, where I configured a bridge for the WAN and another one for the LAN
1. Created a GIF (gif0) with
[Local Address = WAN] ,
[Remote Address = 2404:8e01::feed:101],
[Tunnel Local Address = 192.0.0.2] ,
[Tunnel Remote Address = 192.0.0.1] and
[Disable Ingress filtering = ON]
2. Assigned gif0 to a new interface [DSLite1].
[Block private networks = ON] and
[Block bogon networks = ON] ,
the rest at default
3. On [WAN] interface, I set
[IPv4 Configuration Type = DHCP] and
[IPv6 Configuration Type = DHCPv6],
[Prefix Delegation Size = 64 (Default)]
the rest at default
4. On [DNS], I set
[8.8.8.8] with [Use gateway = None]
[2001:4860:4860::8888] with [Use gateway = None]
5. On [Gateways] I have the following
- DSLITE1_TUNNELV4
[Interface = DSLite1]
[Address Family = IPv4]
[IP Address = dynamic]
[Upstream Gateway = ON]
[Disable Gateway Monitoring = ON]
All else at default
- WAN_DHCP6
[Interface = WAN]
[Address Family = IPv6]
[IP Address = empty]
[Upstream Gateway = OFF]
[Disable Gateway Monitoring = ON]
All else at default
- WAN_GW
[Interface = WAN]
[Address Family = IPv4]
[IP Address = empty]
[Upstream Gateway = ON]
[Disable Gateway Monitoring = ON]
All else at default
No Firewall rules set up yet.
For the settings that's it.
From the console I see that the WAN gets an IPv6 address,
and if I try to ping google.com I get a reply, but if I try to ping 8.8.8.8
I get nothing, only 100% packet loss.
So from what I understand OPNSense gets an IPv6 from my provider, but fails to translate it to IPv4?
I tried to redo a checking all the settings, but I cannot understand where the issue could lie.
Is there something else I should do or check to solve it?
Thank you in advance for help!
@Agricolovo
I am still looking to configure DS-Lite via GUI for my German cable provider but no luck.
For now I have created a script which runs on opnsense start and it works fine.
to test it - connect via ssh to opnsense, enter shell and enter following commands:
ifconfig gif0 create
ifconfig gif0 inet6 tunnel <<LOCAL IPv6 ADDRESS>> <<AFTR ADDRESS>> mtu 1460 -accept_rtadv ifdisabled
ifconfig gif0 inet 192.0.0.2 192.0.0.1 netmask 255.255.255.248
route add default -interface gif0
Quote from: jbourne on August 05, 2024, 01:39:59 AM
Did this break for anyone with the 24.7 update? It was working perfectly up till yesterday when I wanted to install tailscale, and was told that 24.1 is too old - so I ran the upgrade and everything broke. Now the GIF tunnel no longer auto starts and I have to go back to my manual hack solution. Did anything change?
I'm new to the party. I also have a DS Lite IPv6 ISP and am trying to get OPNsense working, and am new to IPv6 networking to boot.
However, in my testing I don't think that this "broke" between 24.1 and 24.7 -- I have setup both in VMs on PVE and both have the same auto start issue. Specifically, I have one VM fully updated to 24.1.10_8 and the other sitting with a plain 24.7.0 install (am hesitant to update until 24.7.3 is released as I've seen there is still some trouble with IPv6).
This is what I'm experiencing:
I have GIF tunnel configured as an interface, and a gateway configured to use the GIF tunnel for IPv4 connections alongside a generic WAN IPv6 gateway which gets configured by my ISP via DHCP. When I first boot opnsense the GIF gateway is marked as defunct and IPv4 routing does not work (the WAN IPv6 gateway and routing works fine). In order to get GIF/IPv4 working I must change the GIF interface's (Interface:Other:Gif:Edit) "parent interface" (I believe this label changed in 24.7) from LAN to WAN and back to LAN before the GIF gateway comes up. At this point IPv4 routing works.
When I reboot I have to do this all over again.
The initial "parent interface" setting change from LAN to WAN is enough to get the interface to be marked as up in Interface:Overview, however it is necessary to change it back to LAN in order for the GIF gateway to function. I'm not sure why it must be set to LAN in order to function as I believe that WAN is the correct setting, however this behavior is the same in 24.1 and 24.7 and necessary to get GIF/IPv4 working.
Quote from: franco on August 07, 2024, 06:17:54 PM
The GIF integration was moved to MVC which also entailed a few changes in the backend code. I'm not sure what it could be. There is the likelihood of a gif-related error in the system log?
Cheers,
Franco
Franco, I do see the following issue in the logs during bootup on both VMs:
Warning config /interfaces_gif_edit.php: ROUTING: refusing to set interface route on addressless opt1(gif0)
Notice config /interfaces_gif_edit.php: ROUTING: entering configure using 'opt1'
Notice config /interfaces_gif_edit.php: Device gif0 missing required local address, skipping now.I've also noticed during bootup that the GIF interface gets configured before the LAN and WAN interfaces. I don't know if this is the problem, but if the GIF interface needs to inherit an IP from the WAN interface then perhaps the order needs to be changed so that GIF comes after WAN? Just an idea from a newbie.
I should also note that the WAN interface takes quite some time to configure in my case - a good 20 to 30 seconds.
Please let me know what additional information I can provide or tests I can run are. I'm happy to do all that I can to contribute and get this issue resolved because from my observation across several threads on various forums, this issue is affecting multiple people, not only me.
Do you think this is the same issue described here: https://github.com/opnsense/core/issues/7713 (https://github.com/opnsense/core/issues/7713), or shall I open a new bug?
Thank you.
Edit: the above was for my 24.1 VM. I have gone back to the 24.7 VM and noticed that the WAN configuration is much faster, and that the order of operations for switching the GIF interface's "parent interface" ("local address" in 24.7) and disabling/reenabling the interface seems indeterministic. Though the GIF gateway was reported as up, I had to toggle things a few times before I could actually ping an external IPv4 address from opnsense shell.
Perhaps it would be better to open a thread in the 24.7 subforum and focus on 24.7 behavior? I simply didn't want to fork this thread so kept my response here for now.