Hi, I'm kinda new to OPNSense but I think I know few things about networking ;) So far I was using Mikrotik router but my old friend RB2011 has poor performance (+/- 150Mbps routing performance in IPv6 - probably due to lack of Fasttrack support on IPv6, IPv4 performance was OK-ish). At this point I want to give OPNSense a try and learn few thing along the way ;D
I'm trying to setup OPNSense as a gateway for FTTH connection from Orange in Poland. With some reading, knowledge from RouterOS setup and "sniffing around" between Livebox 6 and ONT. I try to more or less replicate ISP setup wich includes:
- VLAN id 35 on WAN interface
- PPPoE connection on top of VLAN35 interface - this gives me link-local connection (FE80::/10) between my box and ISP router.
- DHCPv6 on top of PPPoE interface to get public IPv6 prefix (/56) for my subnets and also dhcpv6.aftr-name (option-64) to use in DS-lite tunnell
And this is the point where I'm kinda stuck. My current setup looks like this: I got VLAN, I got PPPoE on it, assigned PPPoE as WAN interface, in WAN interface IPv4 configuration set to PPPoE and IPv6 configuration set to DHCPv6.
The problem is I don't recive public IPv6 prefix from DHCPv6. I turned on debug log for DHCP and it looks like DHCP6c is sending solicit messages on VLAN interface instead od PPPoE interface so there is no response.
It acts the same way whenever the "Use IPv4 connectivity" setting is set or not set.
Any ideas what is wrong with my setup?
Sidenote: PPPoE does not provide any IPv4 connectivity. It provides IPv6 Link-local and gateway adresses only.
Did you tick "Use IPv4 connectivity" for WAN?
Cheers,
Franco
They wrote:
QuoteIt acts the same way whenever the "Use IPv4 connectivity" setting is set or not set.
HTH,
Patrick
Yes.
And also no.
I tried how dhcp6c will behave on both settings and it acts exactly the same. Solicit messages are sent to correct multicast address but through VLAN interface in both cases (FF02::1:2%vlan1).
The WAN interface device is pppoeX? or still vlanXZY?
Cheers,
Franco
It's pppoe0.
EDIT:
Can you, perhaps, point me to the place in source where configuration for dhcp6c is generated? I'm interested in how the correct interface and configuration for dhcp6c is determined and how dhcp6c process is started. I'm a newbie with OPNSense and can't find it myself (I just used pfSense for some time 10+ years ago so it doesn't count ;) )
So far I just found the config file for dhcp6c in /var/etc but in my case it is empty. Is this correct?
Sidenote: I tried to start dhcp6c on pppoe0 manually form the shell (with -fD options) and I saw it got response from ISP DHCP server but failed to set the address of the interface and jumped into loop. But I would leave this thing for later :)
BR,
Carbas
Firstly, check /var/etc/dhcp6c.conf -- the first line is the interface it uses.
Cheers,
Franco
The file is empty.
root@router:~ # cat /var/etc/dhcp6c.conf
root@router:~ # ls -la /var/etc/dhcp6c.conf
-rw-r--r-- 1 root wheel 0 Aug 5 23:57 /var/etc/dhcp6c.conf
Then DHCPv6 WAN connectivity is not really possible. ;)
Yea, I figured it out ;D
Question remains why is it empty :o
Not sure, but smells like a configuration issue.
Cheers,
Franco
This is my config, maybe someone can spot something...
(https://i.imgur.com/s409fbx.png)
(https://i.imgur.com/cjzLSSS.png)
(https://i.imgur.com/jGLkFtv.png)
Maybe this is too easy but did you Apply the changes after saving them?
Yes, of course.
Update:
I've been wrong about /var/etc/dhcp6c.conf content. The file is empty when the "Use IPv4 connectivity" is checked. And then there is no trace of dhcp6c in syslog.
If the "Use IPv4 connectivity" is unchecked then the content changes to:
interface vlan01 {
send ia-pd 6; # request prefix delegation
request domain-name-servers;
request domain-name;
script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 6 {
prefix ::/56 infinity;
prefix-interface bridge0 {
sla-id 0;
sla-len 8;
};
};
and in syslog it spits:
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="97"] Sending Solicit
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="98"] set client ID (len 14)
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="99"] set elapsed time (len 2)
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="100"] set option request (len 4)
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="101"] set IA_PD prefix
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="102"] set IA_PD
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="103"] send solicit to ff02::1:2%vlan01
<29>1 2024-08-06T17:53:03+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="104"] reset a timer on vlan01, state=SOLICIT, timeo=1, retrans=2083
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="105"] Sending Solicit
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="106"] set client ID (len 14)
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="107"] set elapsed time (len 2)
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="108"] set option request (len 4)
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="109"] set IA_PD prefix
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="110"] set IA_PD
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="111"] send solicit to ff02::1:2%vlan01
<29>1 2024-08-06T17:53:05+02:00 router.home.local dhcp6c 17117 - [meta sequenceId="112"] reset a timer on vlan01, state=SOLICIT, timeo=2, retrans=3982
Ok first things first...
# pgrep mpd5
One instance should be running.
# grep pppoe.iface /var/etc/mpd_wan.conf
Should find the correct VLAN.
Then mpd5/PPPoE is in charge of connecting to the ISP.
If that doesn't happen, use IPv4 connectivity will not start running DHCPv6 because IPv4 from the PPPoE point of view is not up!
You can check the PPPoE logs:
# opnsense-log ppps
Then also Orange is a PITA as we know from France where they want very very specific sending options and perhaps even VLAN priority. You need to emulate all of this in order to get full connectivity and my guess is you're not there yet.
Cheers,
Franco
Quote# pgrep mpd5
One instance should be running.
It is.
Quote# grep pppoe.iface /var/etc/mpd_wan.conf
Should find the correct VLAN.
LGTM
QuoteYou can check the PPPoE logs:
# opnsense-log ppps
It looks that connection is established, but only IPv6 config recived. This is expected behaviour.
QuoteThen also Orange is a PITA as we know from France where they want very very specific sending options and perhaps even VLAN priority. You need to emulate all of this in order to get full connectivity and my guess is you're not there yet.
Fortunately polish HQ is not as much PITA as french. They don't stack problems for people wanting use own HW.
Here is full PPPoE log for reference. I think the "LCP: protocol IPCP was rejected" is the important one, but still, IMHO this is expected as I we want to establish IPv6-only connection.
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="37"] process 53486 started, version 5.9
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="38"] web: web is not running
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="39"] [wan] Bundle: Interface ng0 created
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="40"] [wan_link0] Link: OPEN event
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="41"] [wan_link0] LCP: Open event
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="42"] [wan_link0] LCP: state change Initial --> Starting
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="43"] [wan_link0] LCP: LayerStart
<30>1 2024-08-06T21:37:08+02:00 router.home.local ppp 53486 - [meta sequenceId="44"] [wan_link0] PPPoE: Connecting to ''
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="45"] PPPoE: rec'd ACNAME "wro_bng1_re0"
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="46"] [wan_link0] PPPoE: connection successful
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="47"] [wan_link0] Link: UP event
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="48"] [wan_link0] LCP: Up event
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="49"] [wan_link0] LCP: state change Starting --> Req-Sent
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="50"] [wan_link0] LCP: SendConfigReq #1
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="51"] [wan_link0] PROTOCOMP
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="52"] [wan_link0] MRU 1492
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="53"] [wan_link0] MAGICNUM 0x03551bda
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="54"] [wan_link0] LCP: rec'd Configure Request #201 (Req-Sent)
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="55"] [wan_link0] MRU 1540
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="56"] [wan_link0] AUTHPROTO CHAP MD5
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="57"] [wan_link0] MAGICNUM 0x18516f9f
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="58"] [wan_link0] LCP: SendConfigAck #201
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="59"] [wan_link0] MRU 1540
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="60"] [wan_link0] AUTHPROTO CHAP MD5
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="61"] [wan_link0] MAGICNUM 0x18516f9f
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="62"] [wan_link0] LCP: state change Req-Sent --> Ack-Sent
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="63"] [wan_link0] LCP: rec'd Configure Ack #1 (Ack-Sent)
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="64"] [wan_link0] PROTOCOMP
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="65"] [wan_link0] MRU 1492
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="66"] [wan_link0] MAGICNUM 0x03551bda
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="67"] [wan_link0] LCP: state change Ack-Sent --> Opened
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="68"] [wan_link0] LCP: auth: peer wants CHAP, I want nothing
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="69"] [wan_link0] LCP: LayerUp
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="70"] [wan_link0] CHAP: rec'd CHALLENGE #162 len: 32
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="71"] [wan_link0] Name: "JUNOS"
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="72"] [wan_link0] CHAP: Using authname "XXXXXXX@neostrada.pl/ipv6"
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="73"] [wan_link0] CHAP: sending RESPONSE #162 len: 46
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="74"] [wan_link0] CHAP: rec'd SUCCESS #162 len: 49
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="75"] [wan_link0] MESG: session created in USS with key in new format
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="76"] [wan_link0] LCP: authorization successful
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="77"] [wan_link0] Link: Matched action 'bundle "wan" ""'
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="78"] [wan_link0] Link: Join bundle "wan"
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="79"] [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="80"] [wan] IPCP: Open event
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="81"] [wan] IPCP: state change Initial --> Starting
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="82"] [wan] IPCP: LayerStart
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="83"] [wan] IPV6CP: Open event
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="84"] [wan] IPV6CP: state change Initial --> Starting
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="85"] [wan] IPV6CP: LayerStart
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="86"] [wan] IPCP: Up event
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="87"] [wan] IPCP: state change Starting --> Req-Sent
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="88"] [wan] IPCP: SendConfigReq #1
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="89"] [wan] IPADDR 0.0.0.0
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="90"] [wan] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="91"] [wan] IPV6CP: Up event
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="92"] [wan] IPV6CP: state change Starting --> Req-Sent
<30>1 2024-08-06T21:37:09+02:00 router.home.local ppp 53486 - [meta sequenceId="93"] [wan] IPV6CP: SendConfigReq #1
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="94"] [wan] IPV6CP: rec'd Configure Request #244 (Req-Sent)
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="95"] [wan] IPV6CP: SendConfigAck #244
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="96"] [wan] IPV6CP: state change Req-Sent --> Ack-Sent
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="97"] [wan_link0] LCP: rec'd Protocol Reject #202 (Opened)
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="98"] [wan_link0] LCP: protocol IPCP was rejected
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="99"] [wan] IPCP: protocol was rejected by peer
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="100"] [wan] IPCP: state change Req-Sent --> Stopped
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="101"] [wan] IPCP: LayerFinish
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="102"] [wan] IPV6CP: rec'd Configure Ack #1 (Ack-Sent)
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="103"] [wan] IPV6CP: state change Ack-Sent --> Opened
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="104"] [wan] IPV6CP: LayerUp
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="105"] [wan] 5a9c:fcff:fe00:0c17 -> 2a8a:1cff:fea1:dfc3
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="106"] [wan] IFACE: Up event
<30>1 2024-08-06T21:37:10+02:00 router.home.local ppp 53486 - [meta sequenceId="107"] [wan] IFACE: Rename interface ng0 to pppoe0
> IPCP: protocol was rejected by peer
Well, unfortunately this is the problem with PPPoE in the mix, because once the IPv4 connectivity is up the rc.newwanip script takes care of starting the DHCPv6 (because it doesn't make sense before PPPoE device is created). Since there is no IPv4 the PPPoE linkup script is not called so rc.newwanip is not called either.
Call this a shortcoming of the code. I'm not sure how to solve this gracefully (i.e. without stuffing new settings that nobody understands into the PPPoE WAN IPv6 mode).
We could add the same start code to IPv6 equivalent rc.newwanipv6 (or the PPPoE linkup script) but I'm entirely unsure what the best approach is to avoid race conditions by doing it which could break IPv6 for a lot of people with PPPoE at the moment.
Cheers,
Franco
PS: This is more or less part of https://github.com/opnsense/core/issues/7446 although it would make the cleanup a feature by adding more modes. ;(
I've got this setup working with OPNsense, including GIF tunnel for ipv4. It works, until OPNSense reboot, and then I have to manually change LAN settings from track interface to slaac and track interface again, in order to bring back ipv6 connectivity.
Check your LAN settings and try the above trick. This should give you ipv6 there.
P.S. How did you figure out AFTR?
QuoteP.S. How did you figure out AFTR?
Its is provided by DHCPv6 server. Option 64.
So does the LAN config change trick work for you?
Also, I noticed that your dhcp6c.conf is pointing to vlan rather than pppoe interface. Are you confident about PPPoE configuration? I Did you create the PPPoE interface yourself, or was it created during WAN setup?
> Also, I noticed that your dhcp6c.conf is pointing to vlan rather than pppoe interface. Are you confident about PPPoE configuration? I Did you create the PPPoE interface yourself, or was it created during WAN setup?
Well, it was explained.
Cheers,
Franco
No it doesn't and, I guess, it can't work as I do not recive IPv6 prefix at all from DHCPv6 so there is nothing to track for LAN interface.
I don't get anything from DHCPv6 because DHCP6c isn't configured and started for PPPoE interface.
As I understand it happens because IPv4 configuration is not set by PPPoE as this is IPv6-only connection from ISP perspective (I have two separate PPPoE credentials from ISP - one is IPv4-only, second is IPv6-only + DS-lite).
But DSlite does give you an IPv4 address. A CGNAT one, but an address.
QuoteWell, unfortunately this is the problem with PPPoE in the mix, because once the IPv4 connectivity is up the rc.newwanip script takes care of starting the DHCPv6 (because it doesn't make sense before PPPoE device is created). Since there is no IPv4 the PPPoE linkup script is not called so rc.newwanip is not called either.
Call this a shortcoming of the code. I'm not sure how to solve this gracefully (i.e. without stuffing new settings that nobody understands into the PPPoE WAN IPv6 mode).
We could add the same start code to IPv6 equivalent rc.newwanipv6 (or the PPPoE linkup script) but I'm entirely unsure what the best approach is to avoid race conditions by doing it which could break IPv6 for a lot of people with PPPoE at the moment.
So in simple words I understand it would require breaking changes in interface configuration logic, something like:
- "IPv4 Configuration type" set as disabled
- New option for "IPv6 Configuration type" like "PPPoEv6 + DHCPv6" available if the former one is disabled
Do I understand it correctly?
In this case apparently not, which is fatal for acquiring DHCPv6 through PPPoE.
Cheers,
Franco
Well... I might be OPNsense noob myself, but as I said I managed to get this working for Orange PL. with Use IPv4 connectivity" selected on WAN. This leads me to conclusion that there is some other configuration difference that breaks it.
Quote from: carbas on August 07, 2024, 10:01:49 AM
- "IPv4 Configuration type" set as disabled
- New option for "IPv6 Configuration type" like "PPPoEv6 + DHCPv6" available if the former one is disabled
Do I understand it correctly?
Correct, but the implications of further complicating IPv4/IPv6 mode interaction isn't something we should aim for.
PPPoEv6 is in fact
ipv6cp set, just as DHCPv6 and SLAAC do. PPPoE is
ipcp but also the base of what PPPoE needs in order to generate a configuration at all. You can clearly see IPv6 was added later but never really restructured PPPoE and now the point of breakage is here.
Maybe we can get away with latching on to PPPoEv6 (with IPv4 mode set to anything other than PPPoE) for mpd5 configuration and activate IPv6 when the PPPoE IPv6 comes in instead.
It will still require a cleanup of "IPv4 connectivity" behaviour but it sounds like the most elegant way forward.
Cheers,
Franco
QuoteBut DSlite does give you an IPv4 address. A CGNAT one, but an address.
Not from the router perspective. In DS-lite there is GIF tunnel with IPv6 endpoints and then router encapsulates IPv4 traffic into it. The GIF tunnel has the well-known IPv4 address (usually 192.0.0.2 and 192.0.0.1 on AFTR side) and IPv4 traffic is routed through it from LAN without NAT (AFTR does the NAT ).
At least if I understood correctly RFC6333 ;)
@pataps
Which PPPoE username are you using in your setup? The one with "/ipv6" suffix or without one?
If the one without suffix then does the PPPoE connection provide IPV6CP layer to you?
Quote from: carbas on August 07, 2024, 10:28:57 AM
@pataps
Which PPPoE username are you using in your setup? The one with "/ipv6" suffix or without one?
If the one without suffix then does the PPPoE connection provide IPV6CP layer to you?
The /ipv6 one. How else would I get DSLite to work? ;D
@pataps
Ok, my brain just exploded. HOW??? :o ;D
Which version of OPNsense do you have in your setup? For me it sounds like a bug that just became a feature :P
Quote from: carbas on August 07, 2024, 10:37:40 AM
@pataps
Ok, my brain just exploded. HOW??? :o ;D
Which version of OPNsense do you have in your setup? For me it sounds like a bug that just became a feature :P
¯\_(ツ)_/¯
I made it working on one of the 24.1 builds and have it ever since. Now I'm on latest version.
My WAN setup is the same, excluding blocking bosons and private networks. LAN is static ipv4/ track interface ipv6 (WAN, default RA settings) I managed to screw the up at some point and couldn't rebuild it, so I suspect OPNsense is a little picky about this configuration (at some point...).
I attached my configuration. Nothing fancy really. It does work until reboot, so there is some issue with this setup, but redoing ipv6 setup on one of the vlans triggers dhcp6c to start and it's smooth sailing after that. Maybe try to redo the wan vlan and pppoe interfaces?
(https://i.postimg.cc/QBThPjbH/temp-Image6wh-Td6.avif) (https://postimg.cc/QBThPjbH)
(https://i.postimg.cc/7fHP68xW/temp-Imagec-A215-R.avif) (https://postimg.cc/7fHP68xW)
(https://i.postimg.cc/sM1VYYGP/temp-Image-Xg-Pm-LZ.avif) (https://postimg.cc/sM1VYYGP)
Suppose now is as good as ever to work on this while there are testers? :)
DISCLAIMER: I have worked on PPPoE for many years with users, but I do not have a setup to test. I can verify the config looks correct and mpd5 starts, but that's about it.
https://github.com/opnsense/core/commit/84a6d3ad
What I did:
Decouple IP modes from the decision that mpd5 daemon is going to be used. It's now possible to set IPv4 None and IPv6 DHCPv6 and still run in PPPoE mode if the PPPoE device is assigned to WAN.
What I didn't do yet:
Wire DHCPv6 to the IPv6 event in case PPPoE only runs on IPv6. I'm not sure which way to go. It also requires "IPv4 connectivity" changes that I wanted to do anyway because this doesn't make any sense when only IPv6 is acquired. But in the end only the user knows if we should trigger further connectivity on IPv4 or IPv6 tunnel establishment.
Feel free to try and tell me how it goes:
# opnsense-patch 84a6d3ad
(This is especially helpful with people already using PPPoE successfully.)
Cheers,
Franco
Quote from: franco on August 07, 2024, 01:04:31 PM
Suppose now is as good as ever to work on this while there are testers? :)
DISCLAIMER: I have worked on PPPoE for many years with users, but I do not have a setup to test. I can verify the config looks correct and mpd5 starts, but that's about it.
https://github.com/opnsense/core/commit/84a6d3ad
What I did:
Decouple IP modes from the decision that mpd5 daemon is going to be used. It's now possible to set IPv4 None and IPv6 DHCPv6 and still run in PPPoE mode if the PPPoE device is assigned to WAN.
What I didn't do yet:
Wire DHCPv6 to the IPv6 event in case PPPoE only runs on IPv6. I'm not sure which way to go. It also requires "IPv4 connectivity" changes that I wanted to do anyway because this doesn't make any sense when only IPv6 is acquired. But in the end only the user knows if we should trigger further connectivity on IPv4 or IPv6 tunnel establishment.
Feel free to try and tell me how it goes:
# opnsense-patch 84a6d3ad
(This is especially helpful with people already using PPPoE successfully.)
Cheers,
Franco
This is awesome! I can confirm after brief testing, that after changing ipv4 configuration type to none and unchecking use ipv4 connectivity my connection works great. I still need to manually start dhcp6c for some reason, but that is another story.
Ok, so far so good. :)
Finished the POC: https://github.com/opnsense/core/commit/e6f0ac158dc
# opnsense-revert opnsense && opnsense-patch e6f0ac158dc
If all goes well it should start dhcp6c automatically now in the latest config you mentioned.
IPv4 connectivity setting is gone now and the default. You need it anyway since you want DHCPv6 over PPPoE.
Cheers,
Franco
PS: I should note that DHCPv6 over PPPoE didn't work before some late 24.1.x anyway. This is all pretty new territory... https://github.com/opnsense/dhcp6c/commit/f5422a8eb4
Quote from: franco on August 07, 2024, 04:28:34 PM
Ok, so far so good. :)
Finished the POC: https://github.com/opnsense/core/commit/e6f0ac158dc
# opnsense-revert opnsense && opnsense-patch e6f0ac158dc
If all goes well it should start dhcp6c automatically now in the latest config you mentioned.
IPv4 connectivity setting is gone now and the default. You need it anyway since you want DHCPv6 over PPPoE.
Cheers,
Franco
Wow, amazing! Can confirm dhcp6c starts automatically now :D Thank you Franco :)
Good. Do you get your PD?
I'll trickle the relevant commits into the development version after 24.7.1 is out tomorrow.
I don't want to squash the full history yet the back-and-forth code changes can probably be removed.
Cheers,
Franco
Quote from: franco on August 07, 2024, 05:38:56 PM
Good. Do you get your PD?
I'll trickle the relevant commits into the development version after 24.7.1 is out tomorrow.
I don't want to squash the full history yet the back-and-forth code changes can probably be removed.
Cheers,
Franco
Yes I did! Now after every boot my VLANs get propped IPv6. It works great :)
If I understand correctly, in order to preserve this improved functionality I should NOT update to 24.7.1 and wait for 24.7.2?
Quote from: franco on August 07, 2024, 04:28:34 PM
Ok, so far so good. :)
Finished the POC: https://github.com/opnsense/core/commit/e6f0ac158dc
# opnsense-revert opnsense && opnsense-patch e6f0ac158dc
If all goes well it should start dhcp6c automatically now in the latest config you mentioned.
IPv4 connectivity setting is gone now and the default. You need it anyway since you want DHCPv6 over PPPoE.
Cheers,
Franco
Tested this and it seems to continue working as normal with my UK PPPoEv4 and DHCPv6 setup.
I still have the gateway monitor issue that started with 24.7 where the ipv6 gateway monitor won't start with a public ipv6 monitor IP set. It works fine with nothing set and using the default gateway IP as the monitor. WAN & gateway are fe80 link local addresses with my public prefix on LAN which may be relevant.
Neat, thanks for confirming.
Yes, correct. The patch should apply to 24.7.1 as well, but the reboot might get in the way.
Since this code is a change of behaviour in some ways most of it needs to be locked away for 25.1 I'm afraid. We could hook you up on the development version which would do what you need without patching once 24.7.2 hits.
I'm aware of what I'm suggesting but I also don't want to surprise other PPPoE users right now and those that don't have issues right now will need to test this too, which could introduce other problems for you so the development version would give us a quick feedback from you over time as well.
Cheers,
Franco
@csutcliff did you use IPv4 connectivity setting? It's gone from the GUI but I suppose you did because you said it keeps working.
Since when did you start using this anyway? 24.1.9?
Cheers,
Franco
Quote from: franco on August 07, 2024, 05:57:40 PM
Neat, thanks for confirming.
Yes, correct. The patch should apply to 24.7.1 as well, but the reboot might get in the way.
Since this code is a change of behaviour in some ways most of it needs to be locked away for 25.1 I'm afraid. We could hook you up on the development version which would do what you need without patching once 24.7.2 hits.
I'm aware of what I'm suggesting but I also don't want to surprise other PPPoE users right now and those that don't have issues right now will need to test this too, which could introduce other problems for you so the development version would give us a quick feedback from you over time as well.
Cheers,
Franco
I understand. I would appreciate some more info on hooking up to development version in advance :)
Also, worth asking I guess - Am I correct thinking that I cannot simply apply same patch as above after each update until 25.1?
In general the development version is reached by switching the "release type" in the system: firmware: settings tab. After saving all you need to do is check and install the updates. Doing this after 24.7.1 is out will allow you to reapply the POC patch and on the next development update (which is always coupled with 24.7.x, sparsely out of sync for valid reasons).
I plan to merge a couple of things to subsequent 24.7.x releases related to these changes which will break the full patch apply. This is to ensure the compatible bits are not breaking and the final difference will be as minimal as it can be (still larger perhaps but for audits that's better than larger than large).
Cheers,
Franco
Hah, I haven't thought it's going to be that easy! I'll be careful with patching from now on, I suppose :) I will definitely test out the development version.
I appreciate your effort Franco, best of luck!
Quote from: franco on August 07, 2024, 06:00:03 PM
@csutcliff did you use IPv4 connectivity setting? It's gone from the GUI but I suppose you did because you said it keeps working.
Since when did you start using this anyway? 24.1.9?
Cheers,
Franco
Yes I was previously using this setting, I think since March 2021 when I first got ipv6 enabled with a previous ISP. At least
<dhcp6usev4iface>1</dhcp6usev4iface> is present in my oldest backup from June 2022.
Quote from: franco on August 07, 2024, 05:57:40 PM
The patch should apply to 24.7.1 as well, but the reboot might get in the way.
Sort of missing ability to automatically attempt to apply locally saved patches...
Something could be scripted with opnsense-patch -N and rc.syshook but there is no sense of ordering in commit hashes and the local cache is probably polluted with all sorts of old cruft that stops applying sooner than later when lines overlap.
I also don't know what the correct patch point is... boot is silly because the patches may already be applied, older patches will fail for the right reasons. Firmware updates kind of, but we don't know which component got updated so we don't know which patches need to be reapplied.
Most patches are moved quickly to stable releases. For me personally opnsense-patch works within the same boundaries as opnsense-update in the sense that the next update will undo patches/custom packages which are mostly for testing anyway.
Cheers,
Franco
Quote from: franco on August 08, 2024, 07:10:30 AM
I also don't know what the correct patch point is... boot is silly because the patches may already be applied, older patches will fail for the right reasons. Firmware updates kind of, but we don't know which component got updated so we don't know which patches need to be reapplied.
In XigmaNAS you can run a custom script on updates just before system the system is rebooted after upgrade, that's a more generic hack (but the update process is completely different there, not really applicable here).
The syshooks - any hint how to run some custom code
before the networking stuff gets started (and fails to do its job in this case)? I.e. - not
rc.local style as that runs too late... some early boot phase. 🤔
There is https://docs.opnsense.org/development/backend/autorun.html with early (before network and PHP), update (post-update minor version) and upgrade (pre-upgrade major version).
Cheers,
Franco
Quote from: franco on August 08, 2024, 08:25:15 AM
There is https://docs.opnsense.org/development/backend/autorun.html with early (before network and PHP), update (post-update minor version) and upgrade (pre-upgrade major version).
Nice, thanks! 8)
Hi,
Sorry for going silent yesterday.
I'm happy to report that your changes worked for me flawlessly. I got the prefix from DHCPv6 over PPPoE connection.
After that I was able to setup GIF tunnel with AFTR and make IPv4 traffic going through it.
What I noticed, DHCP6c doesn't support aftr-name (option 64) defined in RFC 6334 and doesn't know what to do with it when recived from server ;)
Thank you, Franco, for all your great work ;D
> What I noticed, DHCP6c doesn't support aftr-name (option 64) defined in RFC 6334 and doesn't know what to do with it when recived from server ;)
Can you create a ticket for me? https://github.com/opnsense/dhcp6c
Cheers,
Franco
Quote from: franco on August 08, 2024, 11:42:43 AM
Can you create a ticket for me? https://github.com/opnsense/dhcp6c
Sure: https://github.com/opnsense/dhcp6c/issues/38 (https://github.com/opnsense/dhcp6c/issues/38)
I hope it's good-enough :D
Looks good, thanks. For now we should try to allow this to be exported into the environment and/or add a log message for it with the value. About further integration I'm not sure as this gets way more tricky.
Cheers,
Franco
Quote from: franco on August 08, 2024, 12:19:45 PM
Looks good, thanks. For now we should try to allow this to be exported into the environment and/or add a log message for it with the value. About further integration I'm not sure as this gets way more tricky.
Sure, no hurry. I got around it by manually creating the GIF tunnel. For now i got the AFTR name by intercepting communication between my ONT and CPE i got from ISP :P And AFAIK my ISP does not change the AFTR adresses so I'm good with manual setup (however there are different AFTR's for every region of the country, if you know the address you can make yourself a poor-man's VPN service for IPv4 out of it - ISP does not prevent you from tunneling to other AFTR's 8) )