@mguarienti

This goes down to how IPv6 is provided. Most ISPs use DHCPv6-PD, as I mentioned. This is why I asked about your ISP, so we know. I'm with Rogers in Canada and they use DHCPv6-PD. I get a /56 from them, which pfsense can split into as many as 256 /64s. I also have a WAN address that's not from within my /56 prefix. They'd have their customers sharing a /64 for the WAN addresses. However, if you want help, you have to provide some info that we can work with. Just saying you have a /48 doesn't say much. We can only assume they are intelligent enough to use DHCPv6-PD and are not dumb enough to provide a /48 on a single network.

BTW, forget NAT with IPv6. It's a curse that was created only to get around the IPv4 address shortage.

For my site the issue has been resolved now. Been running smoothly for more than a week after increasing Router Lifetime in services_router_advertisements.php?if=lan

@ddbnj

Then I can only assume you didn't reboot pfsense. That's pretty much necessary to get the full sequence. Otherwise, you only get renewals.

Just in case someone finds this hack useful, the following is the patch I used on 2.5.0. It will only do what is intended (hardcode advertised MTU to 1480) if "Use same settings as DHCPv6 server" is unchecked under the Router Advertisements configuration settings.

src/etc/inc/services.inc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/etc/inc/services.inc b/src/etc/inc/services.inc index a3203aaaf7..1c63272ca1 100644 --- a/src/etc/inc/services.inc +++ b/src/etc/inc/services.inc @@ -130,7 +130,8 @@ function services_radvd_configure($blacklist = array()) { $radvdconf .= "\tAdvDefaultLifetime {$dhcpv6ifconf['raadvdefaultlifetime']};\n"; } - $mtu = get_interface_mtu($realif); + /*$mtu = get_interface_mtu($realif);*/ + $mtu = 1480; if (is_numeric($mtu)) { $radvdconf .= "\tAdvLinkMTU {$mtu};\n"; } else {

I don't think its really anything to do with the AP firmware.. So I don't think they will be able to fix it.. From what a few were saying has to do with the different auth that wpa3 uses..

Not sure - have not dug that deep into yet. I was really hoping to just have guest be limited to wpa3.. But I will live with this compromise.. Just thought give you a heads up if you were doing the same thing.. And you had friends come over - and you get hey this qr code thing isn't working ;)

@beremonavabi

I have never been able to understand the reasons for not supporting DHCPv6 on Android. The reasons I've read could equally apply to SLAAC.

@virgiliomi Thanks. That's a really helpful answer. I appreciate it.

I tested my IPv6 access :

I introduced a firewall rule on my HENET interface :

32f30acb-b7d8-476a-bfd3-d69a3821dc1a-image.png

I have a DNS record that point's to my WAN IPv4, not my WAN IPv6, so I had to use my IPv6 WAN IP to connect to the GUI.
I had a cert warning from my browser, of course.

But the access worked well :

63a2eab4-54c2-4efa-9ef7-04825ab0f777-image.png

"Well" means for me : knowing that my IPv6 is using a tunnel to tunnel.ne.net (Huricane IPv6 ISP) the speed was somewhat limited, about 10 Mbytes /sec.
I could browse the entire pfSense GUI very well, no hick-ups ....

edit : I'll leave the IPv6 access open for a while.
PM me, and I can even send you an 'access' so you can test drive yourself.
That is, if you promise not to change something, as this is a "live' environment ;)

@mickman99 Sorry mal wieder die späte Rückmeldung. Habe jetzt Urlaub und kann mich dem Thema wieder expliziter widmen.

Tatsächlich wird der Präfix einwandfrei auf die Interfaces verteilt und stimmen auch mit dem Präfix mit dem der FRITZ!Box überein. Laut Log der FRITZ!Box wird das verteilte Netz an das LAN Interface auch erkannt und als Exposed Host freigegeben.

Ich vertraue allerdings der Firewall der FRITZ!Box nicht so ganz. Ich richte parallel bei einem Nachbar einen OpenVPN Server über IPv6 ein. Auch dort wird der eingehender Verkehr trotz Exposed Host (natürlich nur zum Test so freigegeben) rejected. Sinn macht das nicht.

Zusätzlich ist bei meiner pfsense das Problem aufgetreten, wenn viele Daten auf einmal verarbeitet werden müssen, dass der interne DNS Server abschmiert. Da habe ich auch die Vermutung, dass es an der FRITZ!Box liegt. Der Log der Fritte verrät da allerdings nicht so viel...

@jan_berg This approach seemed to be working for me: https://wiki.cable-wiki.xyz/OPNsense

Caveats:

Can't be done through UI, needs to be executed in a shell. The tunnel will not be visible in the UI. Doesn't persist. Would need to re-execute every time the WAN comes up and has a global IPv6 assigned. Need to extract the AFTR name and its IPv6 address. In my case, the name comes through via DHCPv6 from the ISP as option 64. Could extract it via tcpdump. Then resolved it to an IP address and used that when setting up the tunnel. Breaks again if AFTR name/IP changes.

So, no real DS-Lite support in pfSense currently, but possible to set up manually.

Hmm, maybe adding a static route would solve this? If you go to System, Routes and Static routes.

Hey,

ich habs jetzt hinbekommen, also nicht selber :/. Mein Freund hat mir geholfen und es geht jetzt.
Vielen dank für die ganze Hilfe.

LG
Mathias

@Jxck

Well, it certainly won't work, without it being configured on the VPN.

@jimp If states are not to be preserved, then a disable/enable (via a heartbeat mechanism or otherwise) might do the trick.. of course with a disruption of the IPv6 connectivity while the tunnel is re-establishing itself.

@Overclock said in Non local gateway IPv6:

I let you inform about OVH response.

Ask them how SLAAC is supposed to work with a /56. You may be able to get a single /64 to work, but the other 255 will be unusable.

I suggest you post exactly what the ISP provided to you regarding how they provisioned IPv6 to you.

Salut ici !

J'ai un peu revu ma copie concernant l'utilisation du /56 fournis par Orange.

Je n'utilise plus le fichier de configuration /usr/local/etc/dhcp6c_wan_new.conf, je suis revenu à une configuration tel que décrite ici : https://wiki.virtit.fr/doku.php/kb:linux:pfsense:remplacer_sa_box_orange_par_un_pfsense

Au niveau de l'interface WAN j'ai juste ajouté DHCPv6 Prefix Delegation size = 56, voici la configuration de l'interface (seulement pour l'IPv6):

WAN

Le fait de déterminer le préfixe côté WAN permet d'avoir côté LAN (ou autres interfaces) la possibilité d'utiliser l'option Track Interface:

LAN: Track interface

Mais en l'état rien ne fonctionne, les clients n'obtiennent pas d'adresse IPv6 😧

Du coup côté LAN je me suis résigné à détermine l'adresse IPv6 de façon statique:

LAN: Static IPv6

Quelqu'un a déjà eu l'expérience d'utiliser l'option Track interface avec succès ?

J'imagine qu'on n'est vraiment pas loin du tout en terme de configuration mais j'ai beau tout retourner je n'y parviens pas.

Certes le fonctionnement actuel est correct, mais j'aurai souhaité atteindre la perfection en n'ayant pas à écrire le préfixe en dur dans les interfaces...

@JKnott
To be really honest...
A cosmic thing. Apparently not all VPN servers I've added (as client) are handing out ULA's. So on my dashboard it just looked sh*t.
Plus my OCD was hyping over this. ;-)

I just want one standard. So all three should give me an ULA or not.
Not just one.

I have pretty much the same kind of setup provided by a local ISP. I found out that ISP providing static IPs is not so common practice. At least among PFSense forum users.
I built up two different setup ("automatic" and "semi-automatic"). Not 100% sure those are according to best IPV6 practices, but I tried to do everything by the book. Not just something that happens to work.
Hoping you get your IPV6 network to work and/or people here are able to assist you on that.

Ax.

@gary201 The issue from July 2019 was resolved without them really going into detail about what was happening during their large maintenance/migration. When I got in touch with them they were still in the "putting out fires" mode. They made a note of my issue, emailed me a few days later when they had a fix in place for me to verify, and all was good.

Around December 2nd of 2020 I did have an IPv6 outage after a maintenance window. No IPv6 traffic was routing. I also tried different machines directly wired to the ONT at that time to verify it wasn't something on my end (not that I had changed anything). I reached out to them and they were able to in their words, "remove a filter" and it fixed my issue. I'm not sure how helpful that is, but it's all they told me.

@JeGr said in DNS hostname for dynamic IPv6 address:

Newer Hosts tend to use EUI-64 if implemented so are not "predictable" by their MAC address anymore

Actually, all IPv6 addresses are EUI-64. The host part can be either MAC based, random number or other. With IPv6, the EUI-48 MAC address is converted to EUI-64 by inserting FFFE in the middle and inverting bit 7.

@JKnott: you've got my requirement upside-down.

I want the pfSense firewalls, on their WAN interface, to accept RAs from the upstream routers.

This is the normal behaviour for RAs. In fact, pfSense supports it if the WAN interface is configured dynamically using DHCP6 or SLAAC. I want to know if it's possible when the WAN interface is configured with a static IPv6 address.

Downstream, everything is fine:

fw1 fw2 | | -+---+----+- | server I can configure pfSense to send RAs only (without offering SLAAC prefix or DHCP6) I can configure the server with a static IPv6 address I can configure the server to pick up its default route via RA (e.g. Linux: accept_ra=1)

That all works fine. Now I need to do the same upstream, where the pfSense WAN is the "client" and the upstream routers send RAs.

You are right that I could instead use VRRP or CARP. The reasons not to do this are partly philosophical (IPv6 already provides this facility, in the form of Router Advertisements), and partly practical: the Netgear M4300-24X24F I'm using has a bug where it drops more than 90% of IPv6 CARP packets, which results in devices switching into MASTER-MASTER mode. (Aside: it also doubles IPv4 CARP packets. Go figure). I do have a case open with Netgear for this.

I know how networks work, so I'm trying to ask a specific question about pfSense from pfSense experts. The question is: if I configure pfSense WAN interface with a static IPv6 address, can it also be configured to accept Router Advertisements? "Yes" or "no" from someone who knows the answer, please.

How about LAN to the IPv6 address on the pfSense WAN interface?

How about LAN to the very next IPv6 hop outside the WAN?

Packet capture on WAN. If the echo requests are being sent but no reply is being received, there's nothing pfSense can do about it. Complain to the ISP.

It is very possible they could have something different configured (perhaps unintentionally) for the interface address/prefix and the routed, delegated /60 prefix.

So looking at the new 5.11.10 release, looks like they have added ipv6?

from 5.11.5 in the release notes?
Add subnet for IPv6 networks in Networks Table.

I am currently running 5.10.21 which is not viable direct upgrade.. So can not test for sure until I get on 5.11.10, but you might want to try 5.11.10 if you want ipv6 with guest policy enable. But not captive portal.

@bigtfromaz said in DDNS pfSense to Windows AD DNS DHCPv6:

I am in the software and services business and we have begun running into situations where some client host machines only have IPv6 because their ISPs have run out of IPv4 addresses. That means the only way they can reach my servers is via IPv6. There aren't many and they are non-US but they are important.

It's probably time for the industry to switch to an IPv6-first stance (Apple and Google seem to be there already). Given the absence of vigorous competition in my area, the ISPs are putting themselves before their customers. I am betting it's a common theme.

Thanks for the heads-up regarding the lack of fair play by Netflix. It's probably due to the fact that they have restricted distribution rights for content and can't be sure of your location. You could probably work around that with a guest VLAN having no IPv6. Kids are really good at getting and spreading computer viruses. A guest VLAN would help you minimize your risk.

I am going to see if I can get the addresses registered in a DNS server on the pfSense and replicate to my Windows AD Server. If I write some code that turns out to be useful I'll put it on GitHub and share a link here.

Yeah, there are several avenues to deal with the IPv6 and Netflix thing, but the kids are only here rarely and I have plenty of IDS/IPS protections for critical stuff. Also, it's only a home network. There are no national defense secrets, Democratic National Committee emails, or documents relating to secret payoffs to porn stars stored here ... LOL.

And yes, Netflix blocks HE IPv6 blocks for precisely the reason you stated: users without strict morals use those to get around geoip blocks that Netflix has in place to enforce their distribution contracts with content owners.

I wish all the ISPs of the world would just start supporting IPv6. Unfortunately that appears to be a very slow process. Even some of those that are supporting it are doing so in strange ways. They seem to be doing their darndest to avoid giving out static IPv6 addresses, for instance.

Even if your ISP doesn't provide IPv6, you can still have it, using a tunnel from hurricane electric. They are free, they perform well, they are very reliable and they work. I used one for years before my ISP implemented IPv6. There are lots people here who can help you set it up.

Ok, so the final update, I have everything fixed now (at least till now)☺

So the final trick is to set my switch to tag port 5-8 which connect to my 4 APs

apparently the tp-link APs will receice packages on it's selected wirelss VLAN + anything that's untagged (without vlan header)

after change my switch to tag vlan1 on port 5-8 it ensures all the vlan1 tag won't be removed when outbound the port, which fixes the RA flood issue.

Thanks everyone for the help

Solved by enabling " Enable Forwarding Mode"

This seems connected to this issue
https://forum.netgate.com/topic/114786/pppoe-disconnects-requiring-reboot/2

Hi guys,

I've followed this conversation quite a while and run into the same issue.
For everyone who would like to have dynamic NPT address to solve this issue please find my repo here: https://github.com/gewuerzgurke84/pfSense-dynamicNptAddress
It's tested it with 1 NPT mapping and 1 "Tracking" Interface with pfSense 2.5.0 and it solves my issue so far. Nevertheless I'd prefer to have this feature as part of the distribution itsself as it is a requirement to get IPv6 running in a reasonable way (at least in Germany)...

Best Regards,
Alex

So what does the config on pfSense look like vs your external server config? There must be some difference in the formatting or naming of the option to explain what is happening.

Look in /var/dhcpd/etc/dhcpdv6.conf

You need to push the IPv6 /64 as a route. It needs to be distinct from the tunnel network. I assume you have more than a /64 to use? /48 or /56?

Similar to how HE's TunnelBroker provides IPs, Unfortunately TunnelBroker does not work in this case because they Block CloudFlare (YES THEY FREAKING BLOCK CLOUDFLARE!!!).

Based on my experiences with HE over the years, if they did in fact block these sources, they have a good reason for doing so.

Additional noteworthy observations.

There was one strange thing about GIF configuration on pfSense 2.4.3 (and before?). I had to disable Outer Source Filtering on gif0 for the traffic to flow — otherwise even gateway monitoring pings were discarded upon reception: that is, if I remember correctly, ping replies were received on parent interface but rejected at GIF level. Those ping replies had proper source and destination addresses for both IPv4 and IPv6 and came in via proper interface. Of course, the IPv6 network for GIF tunnel itself was not the same as for overlaid network — but that is the case for all tunnels of all brokers. In particular, gif2 to the same broker was functioning well with Outer Source Filtering enabled by default, as well as gif1 to another broker.

Right before upgrading from 2.4.3 to 2.4.4, I noticed that gif2 also needs disabling Outer Source Filtering. I had no idea on why this happened and how long ago — just switched the offending setting, and the tunnel became operational for about a couple of hours until the update took place. Same as earlier, however, gif1 to another broker was functioning with Outer Source Filtering enabled by default, and used proper parent interface even after upgrading to pfSense 2.4.4.

Now that pfSense 2.4.4 is installed, I tried switching Outer Source Filtering back on and then off again — just in case — but observed no effect. That was expected indeed, as the primary issue is not with ingress filtering on local side: outgoing traffic is filtered by remote end because of improper source addresses caused by improper parent interface being used.

I also tried Disable Gateway Monitoring for both gateways corresponding to gif0 and gif2. That allowed the traffic to flow out unconditionally, but only showed that any kind of traffic — not just ICMP pings — chose wrong parent interface. I once again tried changing default gateway settings, and the outcome was equally negligible. That is, sometimes I saw small bursts of legitimate traffic pass out and then in (such as my NTP server making a request and receiving a reply), but it is hard to correlate to settings change as those bursts stop soon. The other times I see legitimate inbound traffic entering proper parent interface, but somehow filtered on local side — such as incoming NTP and DNS requests with no reply from my home server [because pfSense filtered those requests out]. :puzzled:

@Norris : Pouvez vous cesser de poster ce type de message qui ne servent à rien ?

Yes, JKnott, I do have "do not allow PD Address release" checked. And you're right, there is no control over what the ISP will actually do. I think the addresses had been the same for about 2 months but it seems like a power cycle of the modem is what triggered the IP change. pfSense had little control over it.

I'm actually on the phone with Comcast Xfinity now, it's taken 1h22m to get to a supervisor. Seems I've been talking a foreign language to both reps I've talked to so far. How hard is it to get a static /60 - /48 on an account? :) I'm currently finding out. It's not like I'm asking for a static IPv4, I'm not even bothering with that.

...and after the call, Comcast Xfinity confirmed they still don't hand out/sell IPv6 blocks to Residential customers. So it is what it is.

Would it be a fair (acceptable?) compromise to only run DNS lookups over IPv4? It looks like if I reorder my IPv4 DNS servers System -> General to place my DCs IPv4 addresses at the top of the list (with no outside interface assigned to it), then remove the RA & DHCPv6 DNS servers - the pfSense DHCPv6 server will assign out its own IPv6 per-interface address as a DNS server, and proxy the replies from the servers, in sequence, from Settings -> General. Seems to do away with the need for a DNS forwarder, which also seems to be IPv6-dependent (i.e. only take IPv6 addresses).

It's also been in Linux for a while.

How many hours of work... Seems like quite a few to me.. So unless you get lucky and someone writes it up for their own use and shares it. You have to provide enough incentive for someone to do all the work.

$100 at best at best cover an hour worth of work - this is clearly more than 1 hour to implement, etc.

Just FYI: the issue https://redmine.pfsense.org/issues/2358 got that pull request #4405 so it should go into review now.