@tomeq82 well aware that interfaces may be set to prefixes longer than /64 in certain router-to-router links, etc. That is not what is being discussed here. Interfaces with hosts on them need to be /64.

Sounds to me like the ISP has implemented a brain-damaged provisioning. I'd tell them to fix it.

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.

@Derelict

You cannot SLAAC a routed prefix.

Ok, this is clear. There is nothing like that on the configuration page either.

You either set it statically or with DHCP6.

Yep, done that both ways. Both methods work without issues.

You also seem to be confusing assigning an address to a device out of that interface prefix

I think I understand that, but that could to be true. The configuration described earlier works and it does what I expect it to do. I don't think it differs much what johnpoz suggested.

Ax.

Answering my own question:

This post:
https://forum.netgate.com/topic/112802/disable-accepting-ra-advertisements-on-an-interface
has a suggestion to edit /etc/inc/interface.inc and add a minus ( - ) in front of the accept_rtadv for the WAN interface. This fixed the FC00:: problem. Had to uncheck the "Wait for RA" option in the DHCP6-PD section.

Telmex also requires the DHCP6-PD queries to happen over IPv4.

A side note: Telmex IPv6 uses a smaller MTU to stay stable. I used 1412 thought 1467 may work as well. Discovered this when ping -6 worked but TLS would have broken/missing packets in Wireshark.

The best thing to do is get information from your ISP. Perhaps they have a beta program or something that would result in more information.

You can see what PD you are getting by saving the DUID in System > Advanced, Networking

Screen Shot 2019-08-18 at 11.56.41 AM.png

Then enable the Debug mode on WAN in the DHCP6 Client Configuration area, setting whatever secret sauce your ISP requires. This is what I use for Cox Las Vegas:

Screen Shot 2019-08-18 at 11.59.41 AM.png

Your ISP might require something completely different.

Then look at Status > System Logs, DHCP and set the filter to process dhcp6c

You will see exactly what is happening.

My PD looks like this:

Sep 1 03:55:10 dhcp6c 44071 update an IA: PD-0 Sep 1 03:55:10 dhcp6c 44071 status code for PD-0: success Sep 1 03:55:10 dhcp6c 44071 update a prefix 2600:dabb:ad00:bc00::/56 pltime=34359824768, vltime=34359824768 Sep 1 03:55:10 dhcp6c 44071 executes /var/etc/dhcp6c_wan_script.sh Sep 1 03:55:10 dhcp6c dhcp6c renew, no change - bypassing update on igb0 Sep 1 03:55:10 dhcp6c 44071 script "/var/etc/dhcp6c_wan_script.sh" terminated

If you want to try new settings just increment the DUID-LLT, save, and Edit/Save WAN. That should result in a new renewal using a new DUID so it should all be fresh.

Your ISP might have settings that don't like changes like this. Only they know. Ask them. We cannot know what they require here. Again, only they know.

Are the addresses being assigned out of the same /64 or /64s from different VLANs?

Perfectly normal and expected for there to be multiple if not several IPv6 addresses on an interface, but they should all be inside the interface prefix.

We know pfSense is tagging the traffic properly. The problem is that switch doesn't properly isolate broadcast (multicast) domains or is misconfigured.

I would never use one of those switches in any network that mattered to me. I would use it for test stuff (like a tap, as mentioned) or throw it away.

@JKnott Hi, thanks for your response. I'm checking right now the issue with my ISP, seems there are some missing routes that are causing this behavior.

It itself isn't... but the fact is that they're providing a gateway, and unless you put it in Bridge mode, it's acting as a router rather than a modem. So pfSense is getting a single WAN address and no prefix because it's being treated as a client on the gateway's network.

@simonszu said in Firewall VM not reachable via IPv6 on Hetzner:

Where is my error? Has my interface config a mistake somewhere?

Yes.
Here :

@simonszu said in Firewall VM not reachable via IPv6 on Hetzner:

Currently i have a static IPv6 on my WAN interface, it has the first IP from the /64 subnet Hetzner gave me. On the LAN end i took another IP from this subnet

The first IP from the /64 could / should be used on the LAN NIC.
For the WAN, you should use some other IPv6 ... as is shown here :

@simonszu said in Firewall VM not reachable via IPv6 on Hetzner:

https://pratt.is/hetzner-und-proxmox-pfsense-als-gateway/

See the IPv6 page : the guy uses a DHCP6-client setup, certainly not a static WAN IPv6 setup.

@Napsterbater MS is so bad, they work on broken IPv4 too:

tbit from 130.217.250.115 to 52.113.64.150 server-mss 1460, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 44 seq = 0:0 b7ef [ 0.136] RX SYN/ACK 44 seq = 0:1 2774 [ 0.136] TX 40 seq = 1:1 b7f0 [ 0.136] TX 369 seq = 1:1(329) b7f1 DF [ 0.268] RX 1500 seq = 1:330(1460) 277b DF [ 0.268] RX 1500 seq = 1461:330(1460) 277c DF [ 0.268] RX 1460 seq = 2921:330(1420) 277d DF [ 0.268] TX PTB 56 mtu = 1280 [ 0.693] RX 1500 seq = 1:330(1460) 2780 DF [ 0.693] TX PTB 56 mtu = 1280 [ 1.443] RX 1500 seq = 1:330(1460) 279e DF [ 1.443] TX PTB 56 mtu = 1280 [ 2.927] RX 1500 seq = 1:330(1460) 27f7 DF [ 2.928] TX PTB 56 mtu = 1280 [ 5.896] RX 1500 seq = 1:330(1460) 2834 DF tbit from 2001:df0:4:4000::1:115 to 2603:1047:0:2::e server-mss 1440, result: pmtud-fail app: http, url: https://meet.lync.com/ [ 0.009] TX SYN 64 seq = 0:0 [ 0.232] RX SYN/ACK 64 seq = 0:1 [ 0.232] TX 60 seq = 1:1 [ 0.232] TX 389 seq = 1:1(329) [ 0.459] RX 1500 seq = 1:330(1440) [ 0.459] RX 1500 seq = 1441:330(1440) [ 0.459] RX 1500 seq = 2881:330(1440) [ 0.459] RX 80 seq = 4321:330(20) [ 0.459] TX PTB 1280 mtu = 1280 [ 0.470] TX 60 seq = 330:1 [ 1.178] RX 1500 seq = 1:330(1440) [ 1.178] TX PTB 1280 mtu = 1280 [ 2.489] RX 1500 seq = 1:330(1440) [ 2.490] TX PTB 1280 mtu = 1280 [ 5.083] RX 1500 seq = 1:330(1440) [ 5.084] TX PTB 1280 mtu = 1280 [ 10.302] RX 1500 seq = 1:330(1440)

afaik still not possible, openvpn guys are working on it and maybe it will be available for version 2.5 (of openvpn not of pfsense)

macOS, at least, seems to do the right thing:

nameserver[0] : fe80::1:1%vlan0

Not sure whether that was received from an RA or DHCP since I am running that segment in Assisted mode (both).

You will also have to specifically pass link-local traffic (fe80::/10) to fe00::1:1 tcp/udp port 53 and add fe80::/10 to an unbound access list.

Link-local is not considered to be LAN Net so none of it is added automatically when you pass from LAN Net.

@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.

@bagusf said in DHCPv6 response cannot go through the pfsense:

Is that true?

If have not tried that operation mode but as your linked document says: "It is normally best to avoid such configurations as they can be problematic, ..." There's a reason why network traffic is divided into layer two and three.

@bagusf said in DHCPv6 response cannot go through the pfsense:

And i follow this guide...

I still fail to understand why you would want to bridge but not to route. What advantages will you get from this?

@bagusf said in DHCPv6 response cannot go through the pfsense:

Hmm.. Lets just say, I have a PC with VMWare installed, connected to IPv6 Network. Inside the VMware I make several VM for different proposes. To improve the security, I want pfsense to act as bridge and firewall inside the VMWare.

You won't get increased security with bridging mode. I would consider a Router + Filtered network more secure. But if you think I'm wrong, please try to convince me.

In the end I think IPv6 has its strengths within routing since it's just large. Exploit that. This guide might give you more comfort idk but I doubt it will be security. Everything you filter in bridged mode you can also filter in routed mode, so.

@b3er said in pfSense as tunnel broker:

found interesting behavior, if no LAN interface/subnet exists in router setup,

Nothing interesting in that. Just read the documentation: If only a single interface exists, pfSense is not in firewalling/NAT mode (it even says so when installing it after adding the WAN). So without a second interface, you are not actually firewalling anything and adding the OPTx Interface from the GIF tunnel then adds the "second" interface and first LAN interface so automatically gets the default LAN setup and firewalling is engaged so WAN will be properly shielded.

@moorthyragav said in WAN IPv6 and LAN IPv4 is Possible to configure in PFSense 2.44 ?:

yes, we are using 30 public IPs 1:1 nat for our clients with old ISP.

So let me get this right - you have clients that currently have a public IPv4 address for their own use.. And now your plan is to move them only to ipv6..

Pretty sure many of them will just leave, if you do that. While ipv6 is the future and all.. If these clients are currently hosting services to their customers/clients via IPv4 and you take that away from them - they prob going to be pretty freaking pissed ;)

The whole internet is not all ipv6 capable - and they could loose many of their customers/clients if they can no longer provide their services via IPv4... Did you ok it with all your clients the removal of IPv4?