pfSense stops routing IPv6 after a few days
-
@ijeff I'm not sure if not route to host means anything or not. Hopefully someone more knowledgeable than me can comment.
You may want to capture more than ICMP - I'm thinking DHCPv6 queries at minimum. Might be best to capture everything but TCP for instance.
That said, if you're not downloading anything there is not much harm in running a full capture for a few minutes.
-
Interestingly, it dropped again today. I've dropped the results below in a format which I hope is easy to read.
Looks like you were right @msmith100, the pings are going out on the WAN interface but the ISP is not sending anything back in return. I guess pfSense is doing its job.
If I contact the ISP's first level support, all I will get is questions as to why I'm not using their prescribed modem, so I'm not going to even bother. I know someone who works for the ISP but I'm not sure if they will know anyone in the technical departments who would be responsible for this.
If there is any other advice I'll be happy to take it, but am I right to understand that pfSense is doing its job here and the ISP is the one dropping the ball?
Is there another setting I can use? Is there another way to distribute IPv6 addresses on my LAN which can get things working? I wouldn't mind only having local addresses on my LAN (those fe80:: ones) if pfSense was able to route out with them, so if that is a quick and dirty option to have IPv6 internet then I would be keen on trying that, but may need to be pointed in the right direction.
Any additional advice is appreciated.
Pinging from LAN
PING6(56=40+8+8 bytes) 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy --> 2620:119:35::35 --- 2620:119:35::35 ping6 statistics --- 10 packets transmitted, 0 packets received, 100.0% packet loss
16:53:48.188300 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 0, length 16 16:53:49.206391 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 1, length 16 16:53:50.236773 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 2, length 16 16:53:51.298848 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 3, length 16 16:53:52.315938 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 4, length 16 16:53:53.343213 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 5, length 16 16:53:54.392126 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 6, length 16 16:53:55.430711 IP6 2001:8003:cd01:yyy:yyy:yyyy:yyyy:yyyy > 2620:119:35::35: ICMP6, echo request, seq 7, length 16
<Pinging from WAN
PING6(56=40+8+8 bytes) 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx --> 2620:119:35::35 16 bytes from 2620:119:35::35, icmp_seq=0 hlim=59 time=3.953 ms 16 bytes from 2620:119:35::35, icmp_seq=1 hlim=59 time=3.586 ms 16 bytes from 2620:119:35::35, icmp_seq=2 hlim=59 time=3.729 ms 16 bytes from 2620:119:35::35, icmp_seq=3 hlim=59 time=3.901 ms 16 bytes from 2620:119:35::35, icmp_seq=4 hlim=59 time=3.411 ms 16 bytes from 2620:119:35::35, icmp_seq=5 hlim=59 time=3.690 ms 16 bytes from 2620:119:35::35, icmp_seq=6 hlim=59 time=3.920 ms 16 bytes from 2620:119:35::35, icmp_seq=7 hlim=59 time=3.070 ms 16 bytes from 2620:119:35::35, icmp_seq=8 hlim=59 time=3.741 ms 16 bytes from 2620:119:35::35, icmp_seq=9 hlim=59 time=3.423 ms --- 2620:119:35::35 ping6 statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 3.070/3.642/3.953/0.263 ms
16:55:03.237296 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 0, length 16 16:55:03.241141 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 0, length 16 16:55:04.254633 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 1, length 16 16:55:04.258155 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 1, length 16 16:55:05.281568 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 2, length 16 16:55:05.285203 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 2, length 16 16:55:06.345437 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 3, length 16 16:55:06.349222 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 3, length 16 16:55:07.408905 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 4, length 16 16:55:07.412162 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 4, length 16 16:55:08.445631 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 5, length 16 16:55:08.449137 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 5, length 16 16:55:09.456343 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 6, length 16 16:55:09.460179 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 6, length 16 16:55:10.508092 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 7, length 16 16:55:10.511094 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 7, length 16 16:55:11.545480 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 8, length 16 16:55:11.549159 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 8, length 16 16:55:12.617936 IP6 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx > 2620:119:35::35: ICMP6, echo request, seq 9, length 16 16:55:12.621150 IP6 2620:119:35::35 > 2001:8003:f00:xxxx:xxxx:xxxx:xxxx:xxxx: ICMP6, echo reply, seq 9, length 16
< -
- My understanding is that if the packets are going out and nothing is coming back, then yes it's the ISP's problem, as long as they are correct - i.e. the source IP is in fact one of yours on the LAN, and hasn't mysteriously been mangled or set to some bad value in some way.
- If your WAN has a /64, I don't think you can distribute that to LAN clients. I might be wrong though
- Best solution might be doing IPv6 NAT with private addresses to the WAN or a He.net tunnel
-
My WAN is definitely /56, and the /64 was assigned by RA to the LAN, so I think that part is fine.
I’m leaning towards IPv6 NAT, but will need to do some reading up on that.
-
-
@msmith100 said in pfSense stops routing IPv6 after a few days:
a /64 for the WAN, /56 for the LAN and other networks behind the router.
????
I think you have that reversed. The LAN side is always /64 and the WAN is whatever the ISP provides.
-
It’s definitely /56 for WAN and /64 for LAN. I’ve confirmed this on the ISP issued router.
-
This post is deleted! -
@jknott Oops I think I should have been more clear. I mean a /64 for the WAN, and a /56 delegated to 1+ LAN networks, each of which is assigned 1 of 256 /64's from that /56 by pfsense per your configuration.
My current config, masked for privacy:WAN (wan) -> pppoe0 -> v4/PPPoE: 104.163.xxx.xxx/32 v6/DHCP6: 2606:6d00:1234:1234:1234:1234:1234:1234/64 LAN (lan) -> bge0 -> v4: 192.168.0.100/24 v6: 2606:6d00:8888:1111::1/64 ..... VLAN4(opt4) -> bge0.3 -> v4: 192.168.11.100/24 v6: 2606:6d00:8888:1112::1/64
As I understand it, I could even not have a globally routable address on the WAN, and it would have no effect. I've seen some other people setup pfsense in that manner, actually - I think on Teksavvy?
@ijeff As long as your config matches what the ISP provides, then there should be no issue and it's their problem. I have heard of cases on various forums though of some ISPs with really strange configs (e.g. Telus on the west coast), including requiring non-standard (i.e. modifying config files manually) behavior w.r.t. DHCP renewing and such. That might be the case in your situation - pfsense is following standard RFCs, and your ISP is not. Further complicating manners, there are also some ISP-grade routers out there with known issues that had to be patched to fix weird IPv6 behavior in the last few years.
Wish I could help further...
-
So would it in theory be possible to use fe80:: addresses on the LAN side and have the router use NAT to pass everything through the single IPv6 address?
-
@msmith100 said in pfSense stops routing IPv6 after a few days:
As I understand it, I could even not have a globally routable address on the WAN, and it would have no effect. I've seen some other people setup pfsense in that manner, actually - I think on Teksavvy?
Quite possibly your WAN address is not used for routing. Check your default route with the netstat -r command. Don't be surprised if you see a link local address.
-
Why on earth would you want to do that? NAT was created to get around the IPv4 address shortage. On IPv6, a single /64 contains 18.4 billion, billion addresses.
-
Seemed like a quick and dirty way of getting IPv6 if my ISP has a non-compliant setup? If it’s not the way to do it then that’s fine.
Someone elsewhere has mentioned that I should investigate enabling large ICMP and ICMP v6 since that’s not allowed on the WAN side of the firewall, but I’m not on site at the moment.
-
What do you mean by "large ICMP"? That would tend to indicate an attack.
-
They specifically mentioned to make sure the following was enabled:
- Allowing large ICMP
- Allowing v6 ICMP across the network
-
@jknott No it's not. Still useful to have for pfsense itself as a pseudo-privacy layer e.g. for DNS requests, and I assume there is at least some good if non-essential reason it's part of an RFC and done by default by my ISP.
-
@ijeff I have no idea how that would help you. AFAIK by default pfsense has rules that allow the bare minimum essential IPv6 ICMP traffic, so that shouldn't be the cause of your issue.
-
I think you're right, it looks like pfSense is doing everything it needs to by default.
I've been referred to this bug which seems to explain the exact issue I'm having. My ISP and the ISP mentioned in the bug actually use very similar network hardware (Cisco Nexus) so it may be completely related to that...
I might wait until 2.5.0 is released with this bug fixed before trying further troubleshooting...
-
I've upgraded to 2.5.0 today and will monitor and report back.
-
No further issues since upgrading to 2.5.0. Looks like the bugs have been squashed!