I created ipv6.getmyip.com to test my IPv6 connectivity.
It only has an AAAA record and it only returns your IPv6 address if your IPv6 stack is working properly (otherwise it doesn't return anything).
It works great with curl (which is the main reason I built it).
@heper said in Hetzner & pfSense:
try to get the /56 anyways ... sometimes isp's say they only supply the /64 but in reality they'll route /56 prefix for each customer if you setup the dhcp-client to get a /56, it might just work
or get another isp or spend the €50
I won't get any IPv6 prefix from DHCPv6 as it's static only configuration, so your idea does not apply.
Since no one is answering, I did a little research.
This appears to be a valid DHCP server/relay solicitation. It doesn't go anywhere because there's no DHCP server/relay on the subnet, because in turn the subnet has been delegated to us from the ISP. radvd is running but we're using stateless autoconfiguration to allocate addresses.
Should I be running a DHCPv6 relay in this situation? Or is stateless autoconfiguration enough? It seems to be working fine at the moment.
Just to let anyone with the same problem know, for a few days now, the problem suddenly occured again.
2a01:111:f307:1790::f001:7a5 and 2a01:111:f335:1792::f001:7a5 exist and both have an AAAA record but they seem to not react on IPv6 connections.
I have 3 machines here which are not updating for a few days now except I disable IPv6 for a second, so that they can reach the update server by IPv4.
I'm now trying suggested solutions above.
Kind of a weird issue.
Edit: Rejecting IPv6 packets to sls.update.microsoft.com servers seems to be a workaround.
The ISP is Spectrum/TimeWarner. I'll call them tomorrow, but you don't get to talk to engineers, just call center people. Most of them can't even spell IPv6, much less tell you anything about it.
Another odd thing, I rebooted pfSense and then checked the DHCP logs to see if I could confirm the /56 that was being handed out. I didn't see anything in the log at all for dhcp6 (yes, there was stuff in there before...) :
# clog /var/log/dhcpd.log | grep dhcp6
# <------ ¯\_(ツ)_/¯
radvdump shows that the /64s being offered there have valid lifetimes of infinity :
AdvValidLifetime infinity; # (0xffffffff)
AdvPreferredLifetime infinity; # (0xffffffff)
}; # End of prefix definition
So maybe pfSense is caching this and just re-using it without triggering dhcp6c at all? I know it's not in config.xml so maybe on the filesystem somewhere? I have to look at the code to see if this is what's actually happening.
I'll try to do some more packet captures as well.
Long story short, I managed to brick my Netgate / pfSsense router (while trying to setup ntopng, no idea why it bricked). So, I reset the router, and started a fresh configuration, with the WAN interface connected to the Comcast modem. And lo and behold, IPv6 kicked in automatically, without me doing anything ... I know it's not a great solution for others, but if you end up like me, and IPv6 refuses to work, doing a hard reset of the configuration might be worth it. :).
@maxxer said in DHCPv6 not sharing IPs on the LAN:
Our LAN is a bridge between wifi and lan port.
Use a wired IPv6 device to test directly a LAN interface.
(Your Wifi AP, if reset, could have ditched IPv6 support)
@gertjan said in IPv6 Network details from ISP:
Ah, yeah ! Can we have FTP back ?? Please ? ^^
How about VoIP or some games, where you need to use an STUN server to tell the devices what the real world address is for something hidden behind NAT. There's also IPSec authentication headers, which are broken by NAT. What if you want to run two servers, running the same protocal, behind NAT? Then you need to do remap some port numbers.
@msf2000 : for what it's worth : my settings and yours (see your image) are the same.
I have an only-win7 network (9 PC's) and a 2008R2 : never had anything to do so IPv6 work on LAN. for all my PC's and devices
IPv6 DHCP settings :
Btw : For most devices I set DHCPv6 Static Mappings :
Btw : Using Win7 for a company. I ruled out Windows 8.x for a company, and, my opinion, Windows 10 isn't still ready yet, I guess I'll be using it in a year or so ...
A "route print" on a Win7 PC :
10...b8 ac 6f 47 2c 77 ......Broadcom NetLink (TM) Gigabit Ethernet
1...........................Software Loopback Interface 1
IPv4 Table de routage
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.6 200
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.6 356
192.168.1.6 255.255.255.255 On-link 192.168.1.6 356
192.168.1.255 255.255.255.255 On-link 192.168.1.6 356
184.108.40.206 240.0.0.0 On-link 127.0.0.1 306
220.127.116.11 240.0.0.0 On-link 192.168.1.6 356
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.6 356
Itinéraires persistants :
IPv6 Table de routage
Itinéraires actifs :
If Metric Network Destination Gateway
10 266 ::/0 fe80::212:3fff:feb3:5875
1 306 ::1/128 On-link
10 18 2001:470:1f13:5c0::/64 On-link
10 266 2001:470:1f13:5c0:2::c6/128
10 266 fe80::/64 On-link
10 266 fe80::75cd:7073:d0a4:bc7c/128
1 306 ff00::/8 On-link
10 266 ff00::/8 On-link
Itinéraires persistants :
@isaacfl said in Cannot route IPv6 - Frustrated:
HILARIOUS! That was is! The rule change fixed it. I used LAN NET because it was set up that way for the IPv4 rule.
Thanks for walking through this mess with me. I Learned a lot.
The maximum working MSS is 1440 in my LAN interface setup in pfSense.
1280 also works.
(the tracepath result gave me the same result as for you)
As I said, I used 1220 because I found that post https://forum.netgate.com/topic/73573/massive-http-ipv6-connectivity-issues/8 where the solution was to set the MSS to 1220.
I’m setting IPv6 in my « home » LAN, to learn more about IPv6 but also to have a fully functional IPv6 connection. I hope that’s the only problem I’ll find about my IPv6 setup.
Again, thanks for all the resource you shared.
@isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:
So it is a router solicitation without updating the neighbor cache on the router.
The question is why is that TV doing that? It should not be using the unspecified address for router solicitations. The reason why the cache is not updated is because that RS does not contain a valid address.
Can you upload a Wireshark, not Packet Capture, capture from boot up to after it stabilizes? I'd like to examine the entire sequence. If it's as bad as it sounds, you should be complaining to Samsung about their defective gear. This sounds about as brilliant as my Samsung Blu-ray player that no longer connects to the Internet.
I cannot imagine that a bridge like that is necessary.
That is really ugly.
They should route the /56 to an address on the WAN interface. That address can be obtained in multiple different ways. It can even be link-local. It is really up to them to tell you, in general terms, how to provision your router interface. For anyone else it would just be a guessing game.
This is an example of instructions for a static /48 from a popular IPv6 transit + colo provider:
::1 is ISP
::2 is Customer
They route 2001:xxx:xxx::/48 to 2001:xx:x:xx::2
It's as simple as that. Interface network + routed subnet.
In that case you would set pfSense WAN to Static 2001:xx:x:xx::2/64 with a gateway of 2001:xx:x:xx::1 and use 2001:xxx:xxx::/48 on the inside however you want.
to the interfaces.inc file:
The specific parts of the script just checks for link local and an interface ipv6, but since IPv6 knows more than one type of an interface IP (GUA and ULA handled by a single function and stops if an matching IP is found)
This could be the reason for the behavior i ve seen for my problem and at the end for ur's too.
For me an ifconfig in a console, i ll get all IPv6 IP's of an specific interface...if i do same in the gui i ll just only get two IP's
So u get for example in GUI an LL+GUA or an LL+ULA, but NOT ULA+GUA+LL
Since most configs generate from the pfsense scripts, the underlying "real" IP's are ignored in this case.
At the end u have missing routes, cause the routes are build from only the half of informations needed
But my programming skills are not so deep to evaluate my thinking, im an hardware guy. :/
Status of 2.4.4...
I still loose routes when combining 2.4.3 with 2.4.4 and Cisco.
But the good news is that it's not the case anymore with the following configurations:
1-pfSense 2.4.4 (priority 0), pfSense 2.4.4 (priority 0), DR Cisco (priority 1)
2-pfSense 2.4.4 (priority 0), BDR pfSense 2.4.4 (priority 1), DR Cisco (priority 1)
In addition, both pfSense devices have the following setting: redistribute connected route-map DNR6
1-After the upgrade to 2.4.4, connected interfaces are not redistributed anymore. As a workaround, disabling/enabling the interface sometimes works! And when not, it has to be re-created!
2-In order to have pfSense act as the BDR (the way we typically need it), it has to redistribute a default route to other routers in the area. At a minimum, the option "default-information originate" should be available on the UI with ideally the possibility to also select "always". When configured this way for both the DR and BDR, 2 default routes will end up on all the routers.
@slampman said in ipv6 client routing issue:
It looks like it is doing RA's but I dont know enough about v6 to tell if they are correct?
That looks like Packet Capture. I much prefer Wireshark, as it provides much more info. However, you can download the capture and open the file with Wireshark.
There is a router advertisement there:
21:57:02.548979 IP6 fe80::250:56ff:fe9c:8801 > ff02::1: ICMP6, router advertisement, length 152
But since I can't see it in Wireshark, I can't tell you much about it, other than the router link local address and it's an unsolicited multicast, rather than a response to a request. If I could view it in Wireshark, I'd be able to determine the prefix used for the network and some other things.
I have exactly the same problem.
My setup is slightly different.
My WAN is set to DHCP and DHCP6. My assigned prefix doesn't normally change that often, but from time to time it does. (For example after a power outage that take a while to solve; or after network maintenance by our ISP)
Anyhow, I too have track interface on my LAN (and VLAN) interfaces, and had added Virtual IPs to those interfaces as well. Those Virtual IPs were ULA addresses, where the intention was that I could always reach the firewall by its virtual IP.
In my case I do not have to wait for a ppoe reconnect or a DHCP renewal on the WAN interface, it is enough that I reboot my pfSense to reproduce it.
When that happens the GUA address on the LAN or VLAN interface is replaced by the Virtual IP and the RA stops 'distributing' the GUA adresses to the clients.
I too have no solution for that, so I have removed the Virtual IPs to get the GUA anouncements working again.
@derelict said in Prefix Delegation to subrouter requires hard-coding subnets when Track Interface enabled:
Even better would be a static assignment from the ISP.
That is common for larger businesses, but small business and home users generally don't get it. For them, the ISP generally wants something that's just plug 'n go. Assigning static addresses requires configuration on their part. Also, when I first started using pfSense, my prefix could change for something as minor as disconnecting/reconnecting the Ethernet cable.
If you use SLAAC the host should establish a "permanent" address based on the MAC address but randomly generate temporary addresses.
In general the "permanent" address can be used for connections to the host, while the random address is used for connections from the host.
This is all controlled by settings on the host itself, not the routers or firewalls.
Did the ISP mention a ND & PD prefix, I recieved the following from my ISP:-
ND Prefix: 2a02:xxxx:xxxx:xx::/64
PD Prefix: 2a02:xxxx:xxxx::/48
The ND prefix is for the WAN interface and the PD prefix for the LAN, I split my PD into /64 chunks.