Setup NAT64 in pfSense



  • Since pfSense hasn't yet added support for NAT64 I was looking into how difficult it would be to manually add the required rules. Here is the original commit to FreeBSD adding support for NAT64. The comment on the commit provides the following instructions:

    Stateless NAT64 registers external action with name nat64stl. This
    keyword should be used to create NAT64 instance and to address this
    instance in rules. Stateless NAT64 uses two lookup tables with mapped
    IPv4->IPv6 and IPv6->IPv4 addresses to perform translation.
    
    A configuration of instance should looks like this:
     1. Create lookup tables:
     # ipfw table T46 create type addr valtype ipv6
     # ipfw table T64 create type addr valtype ipv4
     2. Fill T46 and T64 tables.
     3. Add rule to allow neighbor solicitation and advertisement:
     # ipfw add allow icmp6 from any to any icmp6types 135,136
     4. Create NAT64 instance:
     # ipfw nat64stl NAT create table4 T46 table6 T64
     5. Add rules that matches the traffic:
     # ipfw add nat64stl NAT ip from any to table(T46)
     # ipfw add nat64stl NAT ip from table(T64) to 64:ff9b::/96
     6. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96
        via NAT64 host.
    
    Stateful NAT64 registers external action with name nat64lsn. The only
    one option required to create nat64lsn instance - prefix4. It defines
    the pool of IPv4 addresses used for translation.
    
    A configuration of instance should looks like this:
     1. Add rule to allow neighbor solicitation and advertisement:
     # ipfw add allow icmp6 from any to any icmp6types 135,136
     2. Create NAT64 instance:
     # ipfw nat64lsn NAT create prefix4 A.B.C.D/28
     3. Add rules that matches the traffic:
     # ipfw add nat64lsn NAT ip from any to A.B.C.D/28
     # ipfw add nat64lsn NAT ip6 from any to 64:ff9b::/96
     4. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96
        via NAT64 host.
    

    I'm new to FreeBSD but from what I understand there's three firewall applications available, IPFW, PF and IPF. The example provided is based on IPFW. How would I go about implementing the IPFW statements above in PF, specifically pfSense? Is this doable?

    In regards to DNS64, adding this line to the custom options in the Unbound module enables DNS64 support:

    module-config: "dns64 validator iterator"
    

    Alternatively you can use Google's public DNS64 servers.

    Am I being naive or can I enable NAT64 in pfSense on an experimental basis with a few custom pf rules?



  • Why would even want to use NAT on IPv6?? NAT is a hack to get around the IPv4 address shortage. No such shortage exists on IPv6.



  • @jknott said in Setup NAT64 in pfSense:

    Why would even want to use NAT on IPv6?? NAT is a hack to get around the IPv4 address shortage. No such shortage exists on IPv6.

    NAT64 isn't "natting" in the traditional sense. NAT64 allows IPv6 only hosts to reach IPv4 hosts. Large companies such as Microsoft are using NAT64 and going IPv6 only because they've run out of RFC 1918 addresses.

    Here's an article describing Microsoft's move to NAT64



  • Sorry, I hadn't had my morning beer yet, when I posted that. ;)

    Actually, a better solution is 464XLAT, which avoids some of the problems with NAT64. Some carriers are now using that.


  • LAYER 8 Global Moderator

    Sounds like bad planning on MS if they are running out of rfc1918 space... As of last count I see their employee number at 124K.. Well the 10/8 allows for 16.7 Million IPs - that a shit ton of IPs per person ;)

    That is not counting the rest which is nothing to sneeze at either 172.16/12 over a million..

    So while MS for sure is large - making comments that they have exhausted rfc1918 is BS if you ask me.. I am sure a re IP of their sites could free huge amounts of space..



  • @johnpoz said in Setup NAT64 in pfSense:

    Sounds like bad planning on MS if they are running out of rfc1918 space

    Comcast had the same problem. There weren't enough RFC1918 addresses available for them to seamlessly manage their network.



  • @johnpoz said in Setup NAT64 in pfSense:

    So while MS for sure is large - making comments that they have exhausted rfc1918 is BS

    Don't take my word for it. From the article I linked to above:

    The depletion of public IPv4 space is well-known, but Microsoft IT has exhausted almost all RFC1918 space.
    

    @jknott said in Setup NAT64 in pfSense:

    Actually, a better solution is 464XLAT, which avoids some of the problems with NAT64.

    I'm no expert in IPv6 transition technologies so please correct me if I'm wrong, but from what I understand, NAT64 is still required when using 464XLAT. The issue that 464XLAT solves is IPv4 literals (trying to access a host by IP address instead of a DNS hostname). If an IPv6 only client attempts to connect to 1.2.3.4 directly there's no opportunity for DNS64 to translate the address. In those circumstances, a CLAT daemon is used on the CLIENT device to translate that address to an IPv6 address. But yeah, ideally clients should have CLAT enabled if you want a proper setup.



  • With 464XLAT, you run dual stack, so that IPv4 addresses can be used to access IPv4 servers. In the process, IPv4 is converted to IPv6 and back again. It all happens transparently.


  • LAYER 8 Global Moderator

    @imcdona

    I read the article and saw that - and what I am saying is BS.. Sure you can use up anything with bad management.. Sorry but they are not big enough to use it up if they would of planned correctly.

    They do not have enough employees to justify all 17 plus million IPs being gone with proper planning.


  • Rebel Alliance Moderator

    @johnpoz said in Setup NAT64 in pfSense:

    I read the article and saw that - and what I am saying is BS.. Sure you can use up anything with bad management.. Sorry but they are not big enough to use it up if they would of planned correctly.

    As there are currently MS speakers in Heidelberg talking about IPv6 in internal use and having heard and read their presentation, there's no BS involved or "bad management" at all. One just has to take into account that with MS there is also:

    • Linkedin
    • Nokia
    • GitHub
    • Azure Cloud

    and various other aquisitions and connections to multiple destinations, datacenters etc. round the globe. Nothing to do with "just clients" or emplyoees. As one can see from the presentation of their CSEO here:

    https://twitter.com/Enno_Insinuator/status/1107919913707061248

    they are calculating that at max they have 2-3y left until they can't move with RFC1918 anymore. So they are - and more should go that route - actively working on IPv6, IPv6 only abilities, security etc. Just to clear up that "confusion" - it doesn't have to be a company or management etc. "at fault" for RFC1918 address space to become exhausted. :)


  • LAYER 8 Global Moderator

    Sorry again BS... Nokia doesn't need to talk to github, or linkedn directly... All of those places can use the same rfc1918 space.. So each one of those have the full rfc1918 space to work with.

    The whole point of rfc1918 is it can be used at each location, etc. etc.


  • Rebel Alliance Moderator

    What has to talk to each other and how and why - you know that? I don't. So if your magic eight ball has more insight than mine, I'm jealous ;) But I take the word from their network and security staff talking about their problems seriously and don't simply dismiss it as bullshit without further insight. :)
    Also working for a big US tech company with "C" I've seen a LOT of private adressranges needed and used in software testing and development alone. So I'm sure that at MS you'll see even more of them in use. And yes, they often have to talk to each other. Sadly :/


  • LAYER 8 Global Moderator

    They are running out of IPv4 rfc1918 space because they choose to do so.. Plain and simple!

    Sure some devices might need to talk to each other.. Not ALL of them!! And if need be they can nat, etc. etc.. Sorry but they are touting their move to ipv6 like they are doing something innovative.. And they are using it as marketing.. they don't NEED to move to it..

    Which is GREAT... But don't tell me you "have to" because your out of rfc1918 space.

    And to be honest here is the big problem with the eventual migration... Is once you move part of the network to IPv6.. That frees up lots of IPv4 that can be used now..

    For example could their management vlans on Ipv6, they could put their storage vlans on IPv6, they could put xyz on IPv6, etc etc.. This frees up LOTS of address space to use where its needed, etc.



  • The point of IPv6 is not to free up IPv4 address space so people can keep on using IPv4, it's to completely replace IPv4.

    Whether you like Microsoft or not, they have built more hosts that support dual-stack networking than any other company, probably by a significant margin if you count the number of licenses of all windows and windows server versions that support IPv6. As @JKnott pointed out, this began with Windows XP SP3, which was launched on April 21, 2008. That's a lot of hosts.

    So I think Microsoft has people capable of reorganizing an IPv4 network, if they thought it was the approach to take. I'll give them the benefit of the doubt that if it if was more practical / expedient / cost effective / ..., they would have reorganized their IPv4 address space. Apparently, they decided to go with IPv6. Again, so much for claims that no one is using IPv6...



  • @johnpoz said in Setup NAT64 in pfSense:

    They are running out of IPv4 rfc1918 space because they choose to do so.. Plain and simple!

    I read an article, a while ago, about how Comcast couldn't manage their network with IPv4, without breaking it into segments, due to a lack of RFC 1918 addresses.



  • @JKnott said in Setup NAT64 in pfSense:

    I read an article, a while ago, about how Comcast couldn't manage their network with IPv4, without breaking it into segments, due to a lack of RFC 1918 addresses.

    Yup. Comcast ran out of RFC1918 addresses back in 2005. Here's an interesting presentation that Comcast gave regarding the challenges of managing a 100+ million IP addresses and their IPv6 migration strategy.

    According to the presentation they use 8-9 IP addresses per household. Things got so tight they actually started using public space for device management.


Log in to reply