@jknott No - that setting is not required. But, I tested it extensively with both modes, it made no difference. VZ ignores the ia-na request completely. It only supplies the delegated prefix.

Dpinger will ping the default gateway if monitor IP is left blank. This has always been the case. The problem there is, very often an ISP outage will not be detected because the first or 2nd hop continue to be "up" even though nothing gets beyond that. So it's generally more useful to specify a public IP farther upstream so outages are detected properly.

What is really needed to fix this is one or both of:

Verizon deciding to respect dhcp6c's ia-na request in the solicit Upstream code change to dhcp6c to allow it to assign an IP from one of the ia-pd (delegated prefix) subnets to the parent interface itself. Currently, putting that in /var/etc/dhcp6c.conf is rejected as invalid—even though manually assigning the IP with ifconfig works fine.

I realized the problem was my bridge so I am in the middle of a complete redesign of my network. Will post back when I know more. Hopefully the family wont object too much to the down time.

@johnpoz said in odd ipv6 routing issue:

Been in the business for some 30 years, before there was even switches.

So, you're a newcomer. I've been in the LAN business since early 1978, before there was Ethernet or IP. It was on the Air Canada reservation system, where the LAN used time division multiplexing over coax @ 2 Mb or triaxial cable @ 8 Mb. I started in telecom in May 1972.

@roycethebiker

Did you select 56 for the prefix size?

@ttmcmurry @lilchancep

I have a pfSense CE router now and find your guide to prefix delegation works great. Thank you. I discovered that any Save/Apply to the Interfaces / LAN tab must be followed by a Save on the Router Advertisements tab to correctly define the radvd.conf file. The pfSense system seems to default the radvd.conf file after a Save/Apply on the Interfaces tab ignoring the Router Advertisements configuration until a Save is done on that page. You might want to note that in Step Six of your guide.

Looks like a bug has been filed by the dev team.

It is set on for me per my above post. But, I am on 2.6.0 (which is 22.2 config rev).

@pfadmin

Assuming you want access from elsewhere, how would that help? You still have to allow the outside world to know what the address is.

@jagdtigger

You said an ordinary computer doesn't work. Try complaining about and see what they say. I know it can sometimes be difficult to get through support.

@jknott works like a charm now! thanks!

@ddbnj said in Site to Site ipv6 best practice GUA vs ULA:

I'm still using IPv4 tunnels but am transmitting IPv6 packets across.

I do the same. I don't run the tunnel over IPv6 due to DNS issues. My IPv4 address is an alias that points to the ISP provided host name. Using the alias prevents the DNS server from returning the IPv6 address, which is a regular AAAA record. However, pfSense is configured to allow either IPv4 or IPv6.

@jarhead said in xfinity/comcast ipv6 issue:

But the CGNAT issue I agree with and is valid. Other than that, no reason for IPv6.

When NAT first came out, it broke FTP clients.
It breaks VoIP and some games, requiring STUN to get around it.
It breaks IPSec authentication headers.
It adds work load to routers.
IPv6 provides far more than enough addresses.
IPv6 adds security features.
IPv6 improves router performance.
Etc..

@jknott

The packet capture via mac address is a good idea. If I decide to create an IPv6 table for my local devices, I'll use it.

Regarding routing, I realized that I have to add a route for ULA devices if I don't create an address for the interface itself. It's for devices on a different VLAN to reach ULA devices (admin to IOT).

Anyway, thanks for your insights. Learning and deploying IPv6 has been pretty time consuming, I got to catch up with my real life!

Thanks,

Devan

@jknott Thank you. That makes setting up HAProxy to handle inbound internet traffic interesting (or not possible).

@jknott said in reaching firewall itself via ipv6:

@mikev7896 said in reaching firewall itself via ipv6:

On their own routers, they use the "ff" prefix ID and assign a global address from that prefix to the WAN interface (usually ::1).

ff00/8 is a multicast address and certainly not global, which starts with 2 or 3. Perhaps you meant fc or fd, which are unique local addresses and entirely suitable for network management.

I mean that they use prefix ID "ff" out of the /56 that was delegated... that would be xxxx:xxxx:xxxx:xxFF::

@mloiterman Make a /128 Virtual IP address on your WAN in on of the /64s you want to route downstream. Make a WAN rule passing ICMP6 to that address. Ping it from the outside. Until that works you're not going to be able to route it downstream.

pfSense is doing what it's supposed to be doing with the /64s on a tracked inside interface. That doesn't mean it's a new delegation. Just that dhcpd is adding that prefix to that interface from the delegation.

Go to System > Advanced, Networking and enable the debug on dhcp6c. Then edit/save WAN. Then go to Status > System Logs, DHCP and filter on Process: dhcp6c. See what is there. That should show you the prefix that was assigned.

I have found another approach, but first be sure that it applies to your situation. As others have pointed out, it is not essential that the WAN interface be configured with a Global Unicast Address (GUA). Most installations work fine without it, and its absence has not affected routing at all i.e. the clients all have full IPv6 connectivity.

Prerequisites:

Prefix Delegation (PD) e.g. 2001:A:B:C00::/56 from your ISP At least one address from PD assigned to any interface other than WAN e.g. 2001:A:B:C00::1 on LAN At least one GUA which is NOT in PD, assigned to any interface other than WAN e.g. 2600:X:Y::2 on OPT1.

Symptom:
ping6 from pfSense to internet fails e.g.

$ ping6 -c4 google.com PING6(56=40+8+8 bytes) 2600:X:Y::2 --> 2607:f8b0:400a:807::200e --- google.com ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss

forcing LAN GUA as the source address succeeds

$ ping6 -c4 -S 2001:A:B:C00::1 google.com PING6(56=40+8+8 bytes) 2001:A:B:C00::1 --> 2607:f8b0:400a:807::200e 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=0 hlim=120 time=21.028 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=1 hlim=120 time=25.185 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=2 hlim=120 time=20.654 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=3 hlim=120 time=20.645 ms --- google.com ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 20.645/21.878/25.185/1.915 ms

If this is the case, you can assign a unique label to each offending network in the address selection policy table

$ ip6addrctl Prefix Prec Label Use ::1/128 50 0 12 ::/0 40 1 23716 ::ffff:0.0.0.0/96 35 4 0 2002::/16 30 2 0 2001::/32 5 5 0 fc00::/7 3 13 0 ::/96 1 3 0 fec0::/10 1 11 0 3ffe::/16 1 12 0 $ sudo ip6addrctl add 2600:X:Y::/48 45 6 $ ip6addrctl Prefix Prec Label Use ::1/128 50 0 15 ::/0 40 1 29076 ::ffff:0.0.0.0/96 35 4 0 2002::/16 30 2 0 2001::/32 5 5 0 fc00::/7 3 13 0 ::/96 1 3 0 fec0::/10 1 11 0 3ffe::/16 1 12 0 2600:X:Y::/48 45 6 10 $ ping6 -c4 google.com PING6(56=40+8+8 bytes) 2001:A:B:C00::1 --> 2607:f8b0:400a:807::200e 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=0 hlim=119 time=26.779 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=1 hlim=119 time=22.534 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=2 hlim=119 time=20.708 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=3 hlim=119 time=20.716 ms --- google.com ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 20.708/22.684/26.779/2.478 ms

Because we only reference the networks we are trying to keep away from the default route, source address selection will still be correct should the PD change.

I don't yet know how to make this persistent across reboots or updates. One thing I have tried is putting the table in /etc/ip6addrctl.conf using the filer package, but after rebooting, the ip6addrctl service still needs to be manually restarted.

2c9312f5-1be0-42f0-82b9-37c99c93416b-image.png

I only keep zipping files since this webpage doesn't accept my native uploads. The screenshots have to be less than 2MB or they get rejected. The only way I could get the screenshot that small was to make it a PDF file which isn't accepted. Saving it as a .BMP or .JPG the file was just over 2MB and wasn't accepted.

Frank

So, I found a GUI "bug". I had correctly set the prefix ID's in the "Tracked Interface" for each VLAN, but at the RA page, I mistakenly reinserted the prefix ID in the fields that are for static (full, not delegated) prefixes. Removed the static prefixes and everything now works. GUI should not let you enter static prefixes on a tracked interface, aside from fc00 or fd. And if it does, it should check if they are correct. One of the prefixes was ::1/64.

@gertjan said in If internet goes down, IPV6 won't work until reboot:

@jackthesmack

Try this : when you go to System > Routing > Gateways, hit

105c3cbe-5c59-43dc-99e5-0bc4d268302a-image.png

and then

3d1739b2-31a1-4b34-8a36-63d35051adb5-image.png

does IPv6 comes back ?

Didn't work.

One thing I should clarify is I ran some tests after I made this thread, where I power cycled the modem and also unplugged and plugged in the ethernet cable. IPV6 still works when doing that.

What doesn't work is if I change my spoofed MAC address, and then reboot my modem. This forces an IP address change from the ISP. That's when I need to reboot my router.

This issue will also happen if the internet goes down for some time, which probably causes the same effect as my public IP address being reset.

@bob-dig said in If internet goes down, IPV6 won't work until reboot:

@jackthesmack It is normal behavior of pfSense. Probably because the leases haven't expired and there is no solution for changing prefixes in this time frame, is my guess.

That makes sense. I have had this issue for years.

@noviceiii

Here's an example of what I'm looking for in the captures. This is just part of one packet of 8.

5494ae04-4151-4fb1-a332-0dd7a0ea02a9-image.png

@cyth I did a clean installation of pFSense out of the box provided IPV6, without changing any settings. Looks like they just started rolling dual stack so it will be some issues until they figure it out and finish the implementation. So far my pFSense is working, no issues with internet IPV6 traffic. From Verizon Automatic provide to pFSense address size.

Then I upgraded to pFSense plus, no issues working our of the box.

I spend a lot of time tried to figure it out, and looks like all this time was Verizon implementation issues.

I found out I started getting IPV6 because, some of my devices stop working, the reason was because those devices tried to communicate only using IPV6, they were giving priority over IPv4.

@zennb1

Clients rely on router advertisements to learn the LAN prefix and they append the suffix to it. Run Packet Capture, filtering on icmpv6, to see if you have them. You could also run Wireshark on a computer to do the same thing.

@mikev7896 My problem is that my ISP sends multiple /64 IP prefixes with its RAs although DHCPV6 is used
Pfsense than takes these Prefixes and configures multiple wan addresses. The problem is now that not all of these addresses work
My idea was then to switch off the Address Auto configuration on WAN, but I don't know exactly how I can do that

@steveits
Hey there and thanks for your reply.
That is what I thought.
So, there must have been some rule responsible for this issue. Since the Screenshots of wan and lan did not show any such rule, I figured there must have been other rules...
Just uninstalling pfblockerng solving the problem seems strange otherwise.
Just trying to understand this issue.

@vortex21

Hi, I reconfigured my network yesterday to eliminate the pfSense WAN connection being on a VLAN on the external network port. The WAN interface is now the physical interface card my problem of IPv6 WAN Gateway monitoring reporting 100% loss no longer occurs.
So it appears the problem was related to the use of a VLAN.

Oof, maybe I am just an idiot. I finally looked at /var/etc/radvd.conf:

interface igc0 { AdvSendAdvert on; MinRtrAdvInterval 200; MaxRtrAdvInterval 600; AdvDefaultLifetime 1800; AdvLinkMTU 1500; AdvDefaultPreference medium; AdvManagedFlag on; AdvOtherConfigFlag on; prefix [COMCAST-PREFIX]::/64 { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; AdvValidLifetime 86400; AdvPreferredLifetime 14400; }; prefix fd0f:f5b9:d3f9:3068::/64 { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; }; route ::/0 { AdvRoutePreference medium; RemoveRoute on; }; RDNSS fd0f:f5b9:d3f9:3068::1 { AdvRDNSSLifetime 1800; }; DNSSL [DOMAIN] { AdvDNSSLLifetime 1800; };

Sorry for wasting your time! It looks like pfsense's configuration "does the right thing" in radvd.

@jimp I get it, sorry for the misunderstanding

@dvonhand

Once again, you need packet captures, to see what's happening.

@jknott

Yeah after doing a bunch of research and reading some IPv6 RFC's I decided to just use unmanaged. Everything is working good and I got to turn off the DHCPv6 server. One less thing I have to deal with.

@bob-dig said in After IPv6 prefix change no IPv6 connectivity on Windows host:

Maybe the default lease times for IPv6 should be drastically shortened on any interface which uses "track".

Another way to tackle that would be to use NPt I guess. So it would be great for that, if pfSense allows to use Track Interface in the NPt options directly instead of only using it for "physical" interfaces.

Capture.PNG

@skilledinept

If you want to connect to the firewall with a VPN, etc., you can use another interface address, such as the LAN.

Perhaps if you mentioned your ISP, someone else might be able to help.

@coolspot

I'm still using those settings with the Ignite modem, whatever that model is.
Maybe if you post the settings you're using and what's happening.

Update: I did some more reading on these forums and found this discussion from a few months ago that contained the solution.

I need to specify the whole prefix delegation range allocated to me by the ISP:
screenshot_dhcpv6_working.png

As far as I know it's not possible to automatically update this prefix delegation range if the ISP decides to change it; I'll have to update it manually if that ever happens. Please correct me if this statement is wrong...

Consider this question answered. Will leave the post up in the hopes that it will serve as a template / tutorial for others trying to do the same thing in the future.