pfSense stops routing IPv6 after a few days
-
Is there a method I could use to verify this? My ISP’s network is great but their support is woeful, so I’d like to keep that as a final resort.
-
@ijeff I did a packet capture on my WAN interface, and I could see that pings went out from pfsense but nothing came back. The only case in which that happening wouldn't be their problem is if your side was somehow misconfigured and is using IP addresses that it shouldn't.
Re-reading your post, it kind of sounds to me as if the lease/delegation for your LAN addresses is expiring, and either pfsense is renewing it but their end is ignoring the renewal, or pfsense is not renewing it.
Luckily, my provider has a direct forum on dslreports.com where I so far have been able to quickly handle this kind of weird technical issue...I would not want to try the same with Level 1 phone support from them or really any ISP.
Either way, your best bet is packet capture to see what is going on back and forth between pfsense and the ISP. Good luck!
-
@ijeff said in pfSense stops routing IPv6 after a few days:
Is there a method I could use to verify this? My ISP’s network is great but their support is woeful, so I’d like to keep that as a final resort.
I had a problem with my ISP a couple of years ago. I did a lot of testing with Wireshark and Packet Capture, between my notebook computer and pfsense firewall. My ISP provides two connections, so I was able to connect my notebook to the Internet, without passing through pfsense. In my testing, I found pings to my WAN address worked, but those to behind it never arrived. This indicated a routing problem somewhere. Further investigation turned up problems at my ISP's local head end and I was able to identify the failing system by host name. Then the hard part began, where I struggled to get the network guys to get off their butts and do something, as they didn't want to work on it, since I had my own router. However, I was able to demonstrate the problem to a senior tech. He then went to the head end and tested with 4 different CMTS and only the one I was connected to and had identified failed. That was enough to convince the network guys to do something.
-
Thanks for the pointers. I do recall receiving 'no route to host' when I was attempting to ping an IPv6 address from a LAN device, hence my original assumption about it being pfSense.
I will wait for IPv6 to drop again (probably will take 3-8 days before it will happen again) and perform the captures.
I am assuming that selecting Interface WAN & Protocol ICMPv6 would be sufficient to get the data I'm looking for here?
-
@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.