LAN: Track WAN Interface (for GLA) and Static IPv6 (for ULA) at the same time?



  • I am using pfSense 2.1.4. I have delegation of my /64 from Comcast working fine, but I'd also like to assign ULAs to the devices on my LAN, as recommended by RFC 7368. Ideally, I'd like to hand out IPv6 ULAs via DHCPv6, so I can assign easy-to-remember static IPs for internal use.

    I can only access the DHCPv6 server page if I set a Static IPv6 address for my LAN interface. Fine, but then I lose my Prefix Delegation from the WAN interface. I want both.

    My question is: Is there any way to set two IPs for the LAN address? One via Track WAN Interface and the other static? It doesn't seem to be possible through the web UI, but perhaps I can do this with a boot script or by editing a config file? Have anyone done this?

    Thanks!
    -sam



  • This can be helpful.

    https://forum.pfsense.org/index.php?topic=83576.msg458478#msg458478

    Let us know if it was and how.



  • Did anyone find a solution to this? I need to do the same in order to keep static ULA addresses on a few internal resources, and would sove that most easily with having both a ULA and a GLA address on the same internal interface…



  • Hello,

    you have some options:

    1. If your prefix is static, you can assign one easy  remembered address to your LAN interface. Then you can use DHCPv6.

    If 1) is not true, set the LAN interface to 'track' and head to the router announcement (RA) tap in in the DHCPv6 options, witch is availabe and working even without DHCPv6. Set it to 'unmanaged', this way you get your public prefix. Also, you can add additional prefixes blow (+ button). There, you can set up your ULA prefix, witch is announced along with the GA prefix.

    The third option, if you really want to use DHCPv6, is a static ULA address on LAN. Enable DHCPv6 and set all the options. I never tested it, but you should still get the public prefix from RA. If not, NPt can help (but I consider this a very bad option)
    Just check it with wireshark or tcdump



  • Hi helge000!

    I think your second option sounds like the good way of doing it. The only problem is that when running "track interface" (and not having a static ip), I don't have access to the DHCPv6 or RA options…



  • @pii77:

    Hi helge000!

    I think your second option sounds like the good way of doing it. The only problem is that when running "track interface" (and not having a static ip), I don't have access to the DHCPv6 or RA options…

    Which is something we keep hoping will get added, but never seems to…

    #3029 - DHCPv6 Server/RA page should list interfaces that are configured to track DHCP-PD



  • @virgiliomi:

    @pii77:

    Hi helge000!

    I think your second option sounds like the good way of doing it. The only problem is that when running "track interface" (and not having a static ip), I don't have access to the DHCPv6 or RA options…

    Which is something we keep hoping will get added, but never seems to…

    Why would anyone have that as a design spec. ?

    It seems non sensical to me to expect that your DHCP6-daemon config will change if your premises entrance number (prefix) changes. If it is at all doable, this is improper security to me. Intrusion from outside.

    I think a LAN Track Interface is not a robust trusted IPv6 connection for serving (global) clients. Your ISP is running your show. Services from LAN as Static or with DHCP6-server should be managed behind the WAN, from within your site.



  • It seems non sensible to me to expect that your DHCP6-daemon config will change if your premises entrance number (prefix) changes. If it is at all doable, this is improper security to me. Intrusion from outside.

    HDA, I've seen you make this point on a few threads. I understand your concern, but I don't understand your solution.

    If you're not assigned a static IPv6 range from your ISP, then you are at their mercy. That costs a lot more in most cases, and some ISPs even send your statics over DHCP6.

    So, if the ISP sends you a new prefix and you're not a static customer, how are you going to verify that this change is legit? Most customer service reps don't even understand IPv6, getting them to confirm the range is going to take a better part of the day!

    All that aside, wouldn't you think that a good solution for your concerns would be to have a notice that you've been assigned a new prefix, and not to implement that prefix until you approve it?

    The rest of us that have no choice but to blindly accept whatever IPv4 or IPv6 addresses our ISP gives us can have this setting disabled, but could also deploy ULA so we have control over our internal IPv4 and IPv6 ranges, while conceding that the ISP "owns" our public addresses.

    This would allow all of our devices to keep functioning internally when the ISP changes stuff.

    Sound good to you?



  • @JasonTracy:


    If you're not assigned a static IPv6 range from your ISP, then you are at their mercy. That costs a lot more in most cases, and some ISPs even send your statics over DHCP6.
    ...

    You are the customer, not the ISP slave at mercy or what ?  ;)

    Point is, in most cases the prefix with DHCP6c(PD) is (should be or allow for by ISP) quasi-static (as-if static). The preferred ISP method for IPv6 is prefix delegation by DHCP6c request, even with a fiber-line. Delegation of more than a /63 (/48 is more) should be quasi-permanent. No WAN auto tracking. I do not like the tracking.

    So no worry about a perfect-static, with DHCP6c(PD) you can make your LAN addressing as Static or with DHCP6-Server.

    Then when your ISP changes your prefix, your LAN-static or LAN-dhcp will be dropped or terminated. That is good security and information. (you call them, they tell you the new prefix. you nagging them).

    The discussion of the situation is a comparable case with your mobile phone number, if they (SP) change it, you are not reachable anymore. Or do you like a dynamic mobile phone number ?

    My concern is that customers should strive, ask (or buy) to have a (quasi-)permanent prefix, if the customer wants to offer a public service.

    For my home I get a DHCP6(PD) prefix, while the ISP lease renewal every hour, which I use as Static with construct of a static LAN for my internal net. I know my ISP will give/reserve me the same prefix(PD) every time per cold restart (yes, home account).



  • should be quasi-permanent. No WAN auto tracking. I do not like the tracking.

    We agree on how things should be, and I also don't like the tracking. Comcast is my only broadband option, and paying double just for a quasi-permanent IPv6 address is beyond what I'm going to do.

    That said, I'm interested to hear more about how you're doing this! Right now, I'm getting no IPv6 address at all from Comcast.

    Do you think you can/should share your config on this thread, or have you already published somewhere else? I'm ready to try anything to make it more stable, and manually changing my config would be easier at this point than what I've been living with.

    If you want to take it out of the forums and are willing to help, my email is my firstname at tracys dot org. Thanks!



  • @JasonTracy:

    That said, I'm interested to hear more about how you're doing this!

    What ?  :D  I will outline the principle for non-tracking setups.

    Comcast, I am not with them. But they supply a /60, I understood from elsewhere.
    Try [Interfaces: WAN] (Advanced(Send Options=ia-pd 0)) and (prefix delegation: checked)
    If you get the /60 on the WAN, then you can know your prefixnumber as the first 64 bits.

    Let's assume you get a prefixnumber like 2015:911:abcd:ff80(::1) on your WAN.
    The last placeholder (0) in :ff80: is actually the supplied space, your 4-bits equals 15 LAN's possibly.
    Now in webgui pfSense you can make a LAN-1 static as 2015:911:abcd:ff81::1/64 or a LAN-2 static as 2015:911:abcd:ff82::1/64. (The space available is :ff81: tru :ff8f: ).

    A (PC) serverhost on LAN-1 (:ff81:) could get a number issued by you, (not by DHCPv6), say 2015:911:abcd:ff81::1001.
    Or you could config a DHCPv6-Server/RA with a pool like [2015:911:abcd:ff81::1051 upto 2015:911:abcd:ff81::1100].

    You make your WAN firewall rules on a wellknown server fixed IPv6 address.

    So when ISP pulls/changes your 2015:911:abcd:ff8::/60, then your IPv6 LAN's and public server are securely off-line.


Log in to reply