Blocking access to internal nets
-
If you're requesting a /60 from Comcast… they should give you something like...
2601:aaaa:bbbb:ccc0::/60
for you to use on your various internal networks.
In pfSense, on the interfaces for your various internal networks, you'll select Track Interface for your IPv6 setting, then select WAN and a prefix ID. If you select prefix ID 5, your address block for that interface would be 2601:aaaa:bbbb:ccc5::/64
A /60 gets you 16 prefix ID's (0-F), giving you up to 16 internal networks that can each have a /64.
What you then do is create IPv4/IPv6 rules on the visitor network blocking access to Workstations Network, Servers network, etc. Don't worry about the addresses, as there's a good likelihood that they'll change over time. Select the pre-defined options and let pfSense do the work for you.
-
I'm having this same issue. My IPV6 addresses are assigned over DHCPv6, however, meaning it can technically change at any time. Thus I don't want to create rules or aliases containing the current network addresses. I'd also like to avoid having to create multiple rules at the top of every interface page blocking access to every other interface's network, and I don't see a way to block them all in one rule since I can't select "NOT <multiple networks="">" in the destination for a rule or add dynamically assigned networks to an alias.
I used to do this the same way the OP does, with an alias pointing to 10/8, 172.16/12, 192.168/16. Now I have no idea how to keep track.</multiple>
-
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.
