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.


  • LAYER 8 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.


  • LAYER 8 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.



  • I think a common mistake made is to assume NAT only has one purpose "to address ip space shortage", when that assumption is made, then another assumption gets made which it has no purpose on ipv6. Then there is the third assumption which is that every isp allocates a static routeable ip block.

    In the real world however these scenarios exist.

    Some isp's do give out /128's.
    People may prefer to use consistent internal addresses even on IPv6 and not have routeable IPv6 on every device. This will be especially the case if the isp provides dynamic prefixes.
    Outbound NAT is used to divert outbound traffic e.g. to force all outbound DNS to go via one resolver.

    The argument might be made that if an isp gives out a /128, a solution shouldnt be present for that situation and instead the user should ditch the isp, I dont agree with that mentality, plus the other two situations I detailed are clear legitimate uses of NAT. Although one could say NPt might satisfy the second scenario which then just leaves the outbound NAT situation, for the 3rd scenario I cannot think of anything else that could be done as a substitute, other than using a VPN which I consider way more complex and intervening than NAT.

    My opinion of this subject is that NAT64 and NAT66 should be a feature on every router type device, but at the same time discouraged, so off by default, and not as accessible as IPv4 NAT. But I think the approach of refusing to accept these as features of IPv6 and as such keeping them off devices is not the right way to go.

    One thing proving this point is there is an article on the internet, from a guy who absolutely hates NAT, the article itself is a guide on how to setup NAT66, basically his provider only provided a /128, he assessed his options, which were to use a he.net tunnel, to change provider (he didnt mention this one, but is assumed he loved the price and features of provider too much to consider it), or to setup NAT66. He admitted going the he tunnel route was messier, and worse latency than a simple NAT configuration so went the NAT66 route.

    Thanks to the OP tho as this guide might be a way to "properly " sort out my ipv6 dns leak problem, I find my current solution of simply having a reject firewall rule as "hacky" as the requests will be made and denied before a successful request is made. Whilst outbound NAT makes the software making the request think its had a successful lookup from its chosen dns server. So works transparently.

    The issue is tho, is of course how does one get the NAT64 rules to auto apply on every PF reload, and sadly I dont know the solution as I dont think there is a hooking mechanism provided to trigger script execution on firewall reload.

    --

    Think this is a no go without pfSense official support, it requires IPFIREWALL_NAT64 compiled in the kernel, and its not in GENERIC.



  • @chrcoluk said in Setup NAT64 in pfSense:

    Some isp's do give out /128's.

    The /128 is generally used to identify a system and since it's a /128 it's not possible to communicate with it directly. Traffic must be routed to it. Are there any ISPs that hand out a single IPv6 address? Even my cell phone gets a /64. The only time I've seen a /127 assigned was with the 6in4 tunnel provider I used to use. Depending on configuration, either a /127 single address or a /56 prefix were available. I used the /56 on my home network and the /127 on my notebook computer, when away from home.

    People may prefer to use consistent internal addresses even on IPv6 and not have routeable IPv6 on every device. This will be especially the case if the isp provides dynamic prefixes.

    You'd use Unique Local Addresses for that. ULA are the IPv6 equivalent to the IPv4 RFC 1918 addresses.

    which then just leaves the outbound NAT situation, for the 3rd scenario

    Why would you need outbound NAT, when you have so many addresses available. NAT was sometimes used when combining networks that have overlapping addresses. But that's a problem that arose through using NAT. It could never happen when using public addresses.

    I have yet to see a use for NAT that wasn't caused by the IPv4 address shortage.

    NAT is used to get around the IPv4 address shortage. There is no need for it on IPv6, other than someone being incompetent.



  • @JKnott said in Setup NAT64 in pfSense:

    I have yet to see a use for NAT that wasn't caused by the IPv4 address shortage.

    NAT is used to get around the IPv4 address shortage. There is no need for it on IPv6, other than someone being incompetent.

    I have a lot of experience with v4, but little with v6. I f nat is useless please explain how I handle situations such as: A client changes ISPs- do I re-address every device? What about multi-wan? Is 'prefix' translation not the great satan that network translation is? And don't tell me to get every small business a block from IANA, because they charge as much for 6 as they used to for 4.



  • @dotdash

    A client changes ISPs- do I re-address every device?

    Changing device addresses is very easy on IPv6, as you normally don't set them at all. The router provides the prefix and the device provides it's own suffix via SLAAC or DHCP.

    What about multi-wan?

    IPv6 actually supports that. You can get connections from as many ISPs as you want and assign priority, etc.. If you change prefixes, you'd have to update DNS accordingly, but that's about all.

    Is 'prefix' translation not the great satan that network translation is?

    The problem is NAT breaks some protocols. One of the first that broke was FTP, when used with command line clients. Some couldn't use passive mode, which was needed to work through NAT. More recently, it breaks IPSec Authentication Headers, which is one of the security mechanisms that IPSec provides. You also need STUN servers, to get around NAT, with VoIP and some games.

    And don't tell me to get every small business a block from IANA, because they charge as much for 6 as they used to for 4.

    Well, I managed to get a /56 from my ISP and another from a 6in4 tunnel provider I used to use. The tunnel service was free and my Internet access isn't that expensive. I have no idea what addresses sell for, but I understand IPv4 addresses are becoming more expensive. Also, if you're buying address blocks, you're also buying a much higher level of service from a carrier, rather than an ISP. I have set up many fibre connections to corporate customers. They tend to get an Ethernet connection, rather than IP, from the carrier.

    Because of NAT and trying to save address space, many people have developed bad habits that wouldn't have occurred had sufficient address space been available. According to Vint Cerf, IPv4 was only intended to be a proof of concept system and he planned to go to a much larger address space in the "official" IP>



  • In v6 you don't set fixed addresses on servers providing services to the network? I know the problems with NAT, but I find the condescending attitude about how bad NAT is that many v6 proponents have very grating. I brought up IANA with regard to portability- If I have a business network privately addressed, I can switch the Internet connection to a new provider simply by changing the WAN settings on the firewall. I don't have to change the network from ATT's block to Comcast's block. From a practical standpoint v6 has a lot of issues, which I think is evidenced by it's slow adoption. Some portray this as due to stupid lazy network admins, but I think some of the blame lies with the way v6 was designed. Those people are all way smarter than I am, but I wished they would have listened to some of the concerns brought up by those in the trenches, not the towers. The BGP exhaustion issue was handled much quicker and elegantly, IMHO.
    Sorry about the rant, but I still don't know how to do multi-wan on v6 without NAT (Isn't using 'private' v6 addresses and doing prefix translation, basically NAT?)



  • @dotdash

    In v6 you don't set fixed addresses on servers providing services to the network?

    There's nothing stopping you from manually setting addresses, but you'd still just set the suffix and get the prefix from router advertisements.

    If I have a business network privately addressed, I can switch the Internet connection to a new provider simply by changing the WAN settings on the firewall. I don't have to change the network from ATT's block to Comcast's block.

    If you're getting your addresses from an ISP, rather than the registry, then you'd still have to change external DNS. Given that the LAN prefix changes automatically, when you change ISPs, then there's no addresses to change, other than DNS. In pfSense, that's just a repeat search and replace in /etc/hosts.

    If you take a look on the Router Advertisements page, you'll see a setting called "Router priority". This is used to give a router priority over another. So, you could have connections to 2 or more ISPs, each advertising prefixes on the network, but the devices will use the one with the highest priority. This is part of IPv6, but does not exist in IPv4.

    which I think is evidenced by it's slow adoption.

    A big part of the problem is inertia and those who insist IPv4 is adequate, when it hasn't been since the day NAT became necessary and who then come up with hacks, to get around the address shortage and then more hacks to get around the problems NAT causes.

    but I think some of the blame lies with the way v6 was designed

    IPv6 was designed bearing in mind what worked well in IPv4 and what didn't. What problems can you think of in IPv6 that weren't in IPv4?

    Sorry about the rant, but I still don't know how to do multi-wan on v6 without NAT (Isn't using 'private' v6 addresses and doing prefix translation, basically NAT?)

    You can create as many prefixes as you want with IPv6, whether from an ISP or ULA. And no using private addresses is not NAT. You can do the same thing on IPv4, where you have both public and private addresses on the network, though IPv6 was designed with that in mind, while IPv4 wasn't. On my home network, I have both public and private addresses at the same time. It just works as is intended with IPv6. If you take a look on the Router Advertisements page, you'll see a setting called "Router priority". This is used to give a router priority over another. So, you could have connections to 2 or more ISPs, each advertising prefixes on the network, but the devices will use the one with the highest priority. This is part of IPv6, but does not exist in IPv4. If you take a look on the Router Advertisements page, you'll see a setting called "Router priority". This is used to give a router priority over another. So, you could have connections to 2 or more ISPs, each advertising prefixes on the network, but the devices will use the one with the highest priority. This is part of IPv6, but does not exist in IPv4.

    If you're interested in learning about IPv6 and perhaps clearing up some misconceptions, I'd recommend IPv6 Essentials. (I normally link to the O'Reilly site, but it appears to be down at the moment.)



  • On my previous comments, I realised its only redirect I need not NAT for my scenario. Since pfsense in its UI pairs rdr with NAT functionality it made me assume its NAT, but its just the redirect functionality I am missing which technically isnt NAT but just often used alongside NAT to make it work.

    I still think NAT64 would be a useful addition for those who are single homed on ipv6 tho.

    On the subject of ipv6 rdr I will make a new thread later on a problem I am having in getting it to work to redirect some outbound requests, and if pfsense can add official support for ipv6 rdr.



  • @dotdash said in Setup NAT64 in pfSense:

    In v6 you don't set fixed addresses on servers providing services to the network? I know the problems with NAT, but I find the condescending attitude about how bad NAT is that many v6 proponents have very grating. I brought up IANA with regard to portability- If I have a business network privately addressed, I can switch the Internet connection to a new provider simply by changing the WAN settings on the firewall. I don't have to change the network from ATT's block to Comcast's block. From a practical standpoint v6 has a lot of issues, which I think is evidenced by it's slow adoption. Some portray this as due to stupid lazy network admins, but I think some of the blame lies with the way v6 was designed. Those people are all way smarter than I am, but I wished they would have listened to some of the concerns brought up by those in the trenches, not the towers. The BGP exhaustion issue was handled much quicker and elegantly, IMHO.
    Sorry about the rant, but I still don't know how to do multi-wan on v6 without NAT (Isn't using 'private' v6 addresses and doing prefix translation, basically NAT?)

    You have actually hit the nail on the head.

    I have been involved in many many discussions on different parts of the web, lots of these have been me ranting about how many large isp's are yet to rollout ipv6 to their customer base. The pattern is usually (but not always), that those isp's that have ipv4 capacity problems are rolling out ipv6, which is usually either dual stacked with ipv4 or alongside CGN ipv4. The isp's which have no ipv4 capacity problems are usually staying ipv4 single stacked, there is exceptions, but they are exceptions.

    I have a friend who recently got a job in one of the biggest isp's in the UK, and I asked him off the record on what the story is with ipv6 rollout, the isp has actually already done over 30 field trials "thirty!!!", and they coming up against problem after problem, many of these problems are small of nature, and would be worked around by someone who is technically affluent, but 99% of internet users dont have a clue on internet protocols, and would just hog the isp tech support lines demanding fixes for their problems.

    Some of the problems are down to the design of ipv6 exactly as you stated, others are unforeseen problems and related to inconsistent implementation from vendor to vendor.

    I will list the ones he "specifically" mentioned.

    1 - Address management inside LAN's, the designers of ipv6 are clearly very "strong" in their view that organisations and homes should be using routeable ip's inside internal networks. They "strongly" oppose NAT and is a strong movement to make NAT66 not be even available on routing kit. However many large organisation's actually now design their networks on the principle that the internal addressing is consistent, static and most importantly completely independent of the WAN (internet), whilst NAT was never originally intended for this purpose and simply seen as a band aid for address shortage, its clearly now used in various ways away from that original intention, there is companies who have enough ipv4 address space to assign to all their devices but have simply "chosen" to use NAT instead. The issue the isp has is if they rollout ipv6, the devices they use and supply to customers "must" support NAT66, this is actually a showstopper and until such equipment is widely available its company policy is to not rollout ipv6, the original designers of ipv6 absolutely hate NAT, and are fighting hard to keep it from routing devices, and so its like a western standoff, this isp has customer's in the millions, its a major isp, and there is other isp's with similar positions. I asked him if they would enable NAT by default, or just want it available and he doesnt know in his head but will get back to me.
    2 - Implementation in software, an example provided was the xbox one, xbox live supports ipv6 and so does the console. The console has utilised privacy features so the ipv6 chnges on every power up. The console does "not" allow the ip to be manually configured. A typical firewall does not track ipv6 changes to mac addresses, so basically opening up ports to a games console (needed for various games), is a admin nightmare as the rule would have to be updated either on every boot up of the console or set to globally allow across the entire network. A security nightmare. Incidentally I seen this exact issue mentioned by a user on a forum as well. The user uses pfSense. ;)
    3 - inconsistent implementation of things like icmp and fragment handling aka bugs

    Even John on here has commented a few times "ipv6 isnt there yet". It is frustrating as I feel the net needs to move forward, but ipv6 is been held back by politics.



  • @chrcoluk said in Setup NAT64 in pfSense:

    2 - Implementation in software, an example provided was the xbox one, xbox live supports ipv6 and so does the console. The console has utilised privacy features so the ipv6 chnges on every power up. The console does "not" allow the ip to be manually configured. A typical firewall does not track ipv6 changes to mac addresses, so basically opening up ports to a games console (needed for various games), is a admin nightmare as the rule would have to be updated either on every boot up of the console or set to globally allow across the entire network. A security nightmare. Incidentally I seen this exact issue mentioned by a user on a forum as well. The user uses pfSense. ;)

    What addresses are available? With SLAAC, there is one consistent address, based on MAC or random number that does not change. There are also up to 7 privacy addresses, with a new one every day. You'd configure the firewall for the consistent address, not the privacy addresses. Take a look at what's on the wire to see what addresses are actually used. Outgoing connections should be using the privacy addresses. There are many people, including some here, who are not aware of this difference.

    inconsistent implementation of things like icmp and fragment handling aka bugs

    What fragments? Routers are not allowed to fragment oversize packets. Even IPv4 is moving from fragmenting to path MTU detection.



  • It seems some vendors are treating fragments differently, I dont know the specifics.

    Also I dont own an xbox one. So dont know what addresses are been made available, the guy who posted on the tech forum said was just one address showing in the xbox interface.



  • @chrcoluk said in Setup NAT64 in pfSense:

    seems some vendors are treating fragments differently, I dont know the specifics.

    There shouldn't ever be any fragments for some vendors to treat differently. In IPv6 routers are not allowed to fragment, ever. In IPv4, routers originally would fragment when sending over a link with a MTU too small to handle the packet. With IPv6, [path MTU discovery](Path MTU Discovery) is used to prevent sending packets that are too large for the smallest MTU along the path. This is mandatory on IPv6 and IPv4 is moving to it too. On Linux PMTUD is used for everything over IPv4 and Windows uses it for TCP. IPv6 doesn't even have the IP flags to support fragmentation, so where are those fragments coming from?



  • You never heard of vendors not following guidelines before? It happens.

    Also why do cloudflare even test for fragment support on this page if it never ever happens? http://icmpcheckv6.popcount.org/

    I think I remember reading about reports of broken dnssec related to fragments on ipv6.



  • @chrcoluk

    I tried that test, but didn't see any ICMP too big messages. Also, is the spec supposed to be changed because some vendors don't follow it? As I mentioned, IPv6 doesn't even support fragmentation and IPv4 has the do not fragment flag that tells routers not to fragment. So, if routers fragment with either, then those routers are defective.



  • I dont know about the spec, but most people just care if the internet works. They dont care about specification's if their internet appliance isnt working, and if you are a large isp, then ultimately thats all you going to care about as well, just making the internet work well enough to keep the complaints down and sales coming in.

    I just reported on here what I was told in regards to this large isp, they have had problems discovered that were related to fragments as well as icmp issues.

    As an example, ipv6 everyone ideally should be using 1280 mtu, which is compatible with pppoe, pppoa, ethernet, openvpn etc. In this imagined world everyone is happy without mtu discovery even doing anything at all, but we already have various entities including cloudflare deciding to use different mtu sizes. But as you said icmp discovery is mandatory so that shouldnt be a problem right? yet we have devices blocking icmp discovery on ipv6. Its just how it is.

    I had to enable icmp in my windows firewall to get ipv6 icmp working, windows is the most popular OS on the planet and doesnt even comply.



  • @chrcoluk

    In IPv4, routers use the fragment offset and more fragments flag to handle fragments. Those do not exist in IPv6, so how is a router supposed to fragment IPv6? Any router that fragments IPv6 or IPv4 with the do not fragment flag set is defective. There is no two ways about it and those routers shouldn't be allowed anywhere near the Internet. The only fragmentation allowed with IPv6 is that which may be done by the source and never by any router. Here is some info on the source fragmenting a packet. Please note that requires an extra header and is used only for end to end fragmentation.

    As an example, ipv6 everyone ideally should be using 1280 mtu

    That would be the same as everyone having to use 576 bytes on IPv4. By doing that, you decrease usable bandwidth. On the other hand some networks now use 9K jumbo frames, to improve performance.



  • By accident when looking on other information related to PF I came across this old mailing list post.

    https://lists.freebsd.org/pipermail/freebsd-pf/2014-December/007532.html

    Its in regards to PF in FreeBSD mishandling fragment headers, its EDNS0 so again dnssec related.

    Now of course supposedly fragments are not a thing in IPv6 so how can a device be mishandling something that's not part of the spec?

    I looked into it a bit more, and I think fragments are allowed to be sent by the sender, but the difference from IPv4 is intermediate routers should only pass on the fragments and do no reassembly. Not block them entirely. The recipient can reassemble or block.

    I have gone back to my friend on this, as this is above my head and experience. He has way more qualifications than me, and I will see what he tells me and post back here.

    I also came across this

    https://melkfl.es/article/2018/07/edns/

    So IPv6 is adding new challenges to people related to fragments, that guy figured it out as he is affluent in internet tech, but your average joe bloggs broadband subscriber wouldn't.



  • @chrcoluk said in Setup NAT64 in pfSense:

    I looked into it a bit more, and I think fragments are allowed to be sent by the sender, but the difference from IPv4 is intermediate routers should only pass on the fragments and do no reassembly.

    I mentioned that only the source can fragment. Also, routers never reassemble fragments, even with IPv4. Reassembly only occurs at the destination.

    Not block them entirely.

    Are they being blocked? Or is there some other issue?

    FWIW, I just tried pinging google.com with 2000 byte pings, but it fails. I can see the fragments going out, but nothing comes back. I then tried from my notebook computer, connected to another port on my modem and pinged my desktop computer. Wireshark on the desktop shows both the ping and reply, but Wireshark on the notebook and also Packet Capture on pfSense WAN show only the ping, but not the reply. So, pfSense is allowing the fragmented ping in, but not letting the fragmented reply out. I'll have to look into this some more.



  • @JKnott

    I just did some more testing. I connected my notebook computer to the 2nd port on my cable modem, so that it gets it's own address, separate from my LAN. When I ping my desktop system from my notebook, I receive the requests and replies are sent, but not received. Packet Capture on the WAN port does not show replies. When I ping from my desktop to the notebook, I get replies. It appears pfSense is blocking replies from a computer on the LAN to another out on the WAN, but not from WAN to LAN. All pings were sent with the payload set to 2000 bytes.

    This appears to be a bug in pfSense or, more likely, in the BSD it runs on. How does this bug get "officially" reported?



  • @JKnott said in Setup NAT64 in pfSense:

    @chrcoluk said in Setup NAT64 in pfSense:

    I looked into it a bit more, and I think fragments are allowed to be sent by the sender, but the difference from IPv4 is intermediate routers should only pass on the fragments and do no reassembly.

    I mentioned that only the source can fragment. Also, routers never reassemble fragments, even with IPv4. Reassembly only occurs at the destination.

    Not block them entirely.

    Are they being blocked? Or is there some other issue?

    FWIW, I just tried pinging google.com with 2000 byte pings, but it fails. I can see the fragments going out, but nothing comes back. I then tried from my notebook computer, connected to another port on my modem and pinged my desktop computer. Wireshark on the desktop shows both the ping and reply, but Wireshark on the notebook and also Packet Capture on pfSense WAN show only the ping, but not the reply. So, pfSense is allowing the fragmented ping in, but not letting the fragmented reply out. I'll have to look into this some more.

    I expect its a bug, and also that url is very old, that particular issue might even be fixed now.

    It be good if you look into it tho. :)

    Just seen your newer reply also, if you think its a bug, and its in the underlying PF/BSD code, then my opinion is it should be reported to FreeBSD developers. Then if/when they fix it, that fix would make it into pfSense.



  • @chrcoluk said in Setup NAT64 in pfSense:

    I expect its a bug, and also that url is very old, that particular issue might even be fixed now.
    It be good if you look into it tho. :)

    I did look into it and it appears there is a bug with pfSense, as I mentioned above. This is with the current version of pfSense.



  • Any news on this? I need NAT64. Is it possible in any way with pfSense?



  • @johnpoz said in Setup NAT64 in pfSense:

    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.

    They don't need to move to IPv6, they could continue working around the shortcomings of legacy ip for years to come. Just like you could keep repairing and modifying a rusty 1980s car. Microsoft have clearly decided that it's more cost effective, easier and more secure to move to IPv6.

    Yes not everything needs to talk to each other, but inevitably some things will.
    With an IPv6 network where everything is addressable, you add the necessary allow rules and job done.

    With legacy ip, you might have overlapping address space so you need nat or even double nat, which then means you need to waste address space with the translated addresses too. Their offices in redmond and finland might both use 192.168.1.x, so 192.168.1.10 (finland) cant talk to 192.168.1.10 (redmond) as the stack will route the traffic locally. Instead you need to create a virtual network 192.168.2.10 (virtual) which 192.168.1.10(redmond) talks to, which then translates the traffic before forwarding it to 192.168.1.10(finland), so both sides are actually talking to 192.168.2.10.
    Then you have inconsistent addresses, depending on where you're locate you might need to connect to 192.168.1.10 or 192.168.2.10, so you need to setup split dns etc too.
    Then you consider logging/security, as the traffic will have different src/dst addresses depending where on the network it is, you have to correlate multiple log sources. If your sat in the SOC and you see suspicious traffic from 192.168.1.10 did it originate in finland or redmond? You now have extra work to find out... If you see traffic from an ipv6 address it's unique and you know it correlates to a single device.

    The idea that the number of employees correlates to address usage also makes no sense... Assuming every employee has at least a desktop and a mobile device, some employees are going to have a lot more - for instance software developers will have clusters of machines performing builds, machines for testing etc. Microsoft also support their products for several years after release so they are going to have build/test networks for each major version going back several years.
    Then you have address wastage due to the nat kludges above...
    Not to mention the wastage of addresses each time you create a legacy ip subnet - network address, broadcast address, minimum of 1 address for the router possibly 3 if you use vrrp/hsrp/etc.
    Then every time you create a subnet, you make it bigger than strictly necessary to allow room for expansion - because otherwise having to readdress everything is extremely painful.

    Github isn't the last company microsoft are going to acquire either, sooner or later they are going to acquire more and it will be the same integration headaches all over again.

    So yes, Microsoft could kick the can down the road and continue struggling with legacy ip for a few more years, spending a lot of money dealing with the headaches and security implications before having to implement IPv6 at some point in the future anyway.
    Or they can implement ipv6 now, then its done and doesn't need to be done again. They gain a network which is simpler, easier to manage, easier to monitor, more secure and easier to expand in future. They made the smart move.



  • @bert64 said in Setup NAT64 in pfSense:

    They don't need to move to IPv6, they could continue working around the shortcomings of legacy ip for years to come. Just like you could keep repairing and modifying a rusty 1980s car. Microsoft have clearly decided that it's more cost effective, easier and more secure to move to IPv6.
    Yes not everything needs to talk to each other, but inevitably some things will.
    With an IPv6 network where everything is addressable, you add the necessary allow rules and job done.
    With legacy ip, you might have overlapping address space so you need nat or even double nat, which then means you need to waste address space with the translated addresses too.

    Yep, IPv4 hasn't been adequate since the day it became necessary to use NAT. Now, we have hacks upon hacks to get around the address shortage. Of course, this is before we get to the fact that many people are behind carrier grade NAT, which means they have no means of accessing their home network with a VPN etc..

    IPv6 is where the world is moving and refusing to move with it is head in the sand stupidity. The longer people refuse to move, the longer some people will be behind CG NAT.


Log in to reply