Blocking access to internal nets
-
Tell Comcast to assign IPv6 properly.
Cox has been pretty good about honoring the DUID and giving the same /56 every time despite a couple gear changes and a few IPv4 reassigned addresses.
My experience helping people with Comcast has not been so steady.
This is ultimately not between you and pfSense, but between you and your ISP.
You might get some joy using LAN net, SERVERS net, WIRELESSINTERNAL net, etc in your firewall rules.
-
Given making my ISP act differently is not practically feasible, it would seem using the "net" options is the way to go. However, these can not be combined in aliases, as far as I know.
On IPv4, I have have an alias called "private" which covers 10/8, 172.16/12, and 192.168/16, and I can add outbound rules allowing port 80 and 443 to "NOT private".
Great. One rule allows outbound traffic, and I can add additional rules for any internal pinholes. Great.With IPv6, I don't see a way to do this. I'd apparently need a setup like the following for each interface:
1. A couple of pinhole rules for internal servers I want to be accessible cross-interface
2. General blocking rules for traffic to the "net" of every other internal interface
3. An allow rule generally allowing port 80 and 443 to anywhere, which includes any interface I forgot to block, or moved around or whatnotThis is not a pretty solution.
-
Get a prettier ISP.
-
This is why customization exists. We don't ask people who's hardware doesn't do hardware TCP segmentation to "get a better NIC". We don't ask people who's ISP's require a certain mac address (presumably from their shitty provided router) to get one that doesn't require that, and we don't ask people who wish to communicate with a weird IPSec router that insists on acting as the initiator to get a less weird router at the remote site. pfSense will work with and around all of those restrictions, and plenty of others.
Your insistence that this particular issue must be resolved at the ISP level is really not helpful, and I don't understand what makes this case stand out as one that couldn't be handled by pfSense. After all, there's nothing about DHCP that allows you to expect your lease to remain valid outside of your given lease time. The whole point is that it's not static.
-
I ended up writing a script that regularly polls the IPv6 IP's and masks of every interface that has a private IPv4 address. I output that along with my previous list of RFC1918 addresses and put it all in a file for pfSense to read. If the file changes, I trigger an alias update via PHP. Seems to work quite well :)
-
For reference :P
https://redmine.pfsense.org/issues/96
-
Nobody would dream of getting an IPv4 /19 routed for use on internal networks that the ISP could just change on a whim any time they felt like it.
Until the ISPs get a clue, people will come to the conclusion, like you, that it is STILL better to just use IPv4 and NAT.
-
Does any of you have any sort of feedback from your ISP why they keep doing that? I hope it's not the usual ignorance of "it's safer for the client". It really boggles my mind because the IPv6 address space is so large that you could assign a personal /48 to every single person who has every lived on earth, that's a hell a lot /48s.
-
My most recent reply was that my ISP is still rolling out the IPv6 infrastructure, so they'll be changing things from time to time. Also, non-static DHCP is just how they do things, because static IP's are for business connections, and those cost like 10x the price for the same speed. :-\
-
So until they get their crap together get a /48 from HE.net and use a tunnel. They manage to statically assign /48s to people all over the world - free - and manage to stay in business.
-
What sort of bandwidth do you get on those?
-
Works fine. I never thought about it. I am native now and not really in a position to test it.
What I get won't matter to you. It's what you get that will matter.
Try it and see. It's free.
