NAT64 Follow UP.

Hello again.

This is a follow up to my previous post about NAT64.

I decided to do a few minor improvements to the lab, nothing out of the extraordinary.

The previous post dealt with a lab setup regarding NAT64.

The lab in itself is fairly straight forward. However, I decided to tweak it a bit and make it a bit more realistic.

So, Fig. 1 has the new topology.

Figure 1. DNS64 with ASA firewall.

The new topology has an ASA firewall inserted at the edge. Two Internet devices WAN and WAN6 connect to the ASA. These two devices stand it for Internet devices.

The idea here is to show how you would route to IPv4 and IPv6 devices. The ASA would be the dual-stack device allowing IPv4 and IPv6 traffic to reach the Internet.

As the diagram shows, some renumbering was needed. The configuration of OSPF in IPv6 is not different from that of IPv4.

I will not show the full configuration of the ASA, nor the configuration of the dynamic routing protocols, they are standard as I stated. There are though some caveats that you need to consider.

Old Lab.

The old lab connected R1 (IPv6) and R3 (IPv4) via a DNS64 (R2) device.

The main points of the configuration in terms of routing were:

  • R1 and R2 spoke RIP.
  • This allowed R2 to announce a default route.
  • With a default route, R1 could communicate with R3.
  • R2 and R3 communicate via IPv4 OSPF.
  • This allows R3 to receive routes from R2 and vice versa.
  • In order to talk to WAN, a default route was added to R3.

In a more realistic case, we would send IPv4 traffic one way while IPv6 will go a different route. In all cases, you will also have a firewall to filter traffic. This is a must for IPv6 since by the definition of IPv6, now your internal servers are also exposed to the Internet.

This is where the ASA enters the picture. ASA’s support both IPv4 and IPv6 and are typical of many other firewalls out there.

New Lab.

From Figure 1. you can see the devices added to the topology.

  • WAN an IPv4 only “Internet” site. For the networks, we are using 192.168.x.x as addresses.
  • WAN6 an IPv6 only “Internet site”. As prefixes, we use 2003::/64 and 2004::/64.
  • ASA firewall
    • As usual, the ASA has four interfaces defined: inside, inisde6, outside, outside6.
    • The IPv6 prefix in use is 2002::/64. This prefix is applied to R1 and the ASA.
    • A NAT overload statement for IPv4 allows internal clients R3 in this case to access WAN.
    • Notice that the packet reaching WAN will be a double NAT packet. This because R2 already does NAT on the IPv6 packet transforming it into an IPv4 packet. Then that packet is manipulated by the ASA before reaching WAN.
  • The server in use as a DNS64 server was also configured.

A couple of changes were made to R1 and R2 in order to make routing a bit robust.

On R2 we stop advertising a default route via RIP. This because we want R1 to route via IPv6 by default unless the address in question needs to be modified by NAT64.

If the packet is modified by NAT64, we want that packet to originate from R1 traverse R2 and R3 and reach WAN.

To achieve this after stopping RIP from announcing a default route, use the “redistribute static” statement under RIP.

The reason for this is that NAT64 creates floating static routes for the IPv6 prefix it will use for NAT64.

Now the only thing left is to announce a default route via OSPF from the ASA to R1.

Finally, the DNS server was configured. The server uses BIND, the standard service for DNS resolution. BIND has support for DNS64. The configuration is straight forward.

We configured a dummy zone making sure the server could resolve IPv4 and IPv6 addresses.

After that, the configuration for DNS64 is fairly easy. You need to add the following snippet in the configuration.

options { 
        (...) # Listening on IPv6 is off by default.
        listen-on-v6 { any; };
        # This is the key.
        # Note that you can write multiple of these if you need 
        # more IPv6 prefixes.
        # "3001::/96" is the pool configured on R1.
        dns64 3001::/96 {
                # Options per prefix (if you need them) here.
                # More info here: https://kb.isc.org/article/AA-01031 };
        };

The next thing to do was to add DNS resolution to R1. This is straight forward as Cisco routers can have a DNS resolver by issuing the following commands:

!Enables DNS-based host name-to-address translation.
!This command is enabled by default.
ip domain lookup
!Specifies the address of one or more name servers.
ip name-server x.x.x.x y.y.y.y

Caveats.

Some things to consider.

  • Make sure you only enable RIP and OSPF on the interfaces you want and disable it on the rest. Use the command “passive-interface default”, then enable the IGP on the interfaces you need.
  • Unlike IPv4 OSPF, there is no longer a network x.x.x.x area x to exchange routes. To advertise routes use the “redistribute connected” statement.
  • Found a quirk while configuring the ASA. Initially was going to use /128 for the interfaces connecting each other.
  • Found out that unlike routers, the ASA does not like to have a /128 on an interface even though this is acceptable and was used in the old lab.
  • No fancy configuration in the ASA other than the NAT statement. On both IPv4 and IPv6 by default, the ASA allows an interface with higher security to connect to an interface with lower security.
  • Of course, much more complicated rules can be placed and also allow WAN to access a service behind the ASA from the IPv4 network. Remember there is already a static rule on R2 that allows this, the ASA will have to allow it also for it to work properly.

Conclusions.

While the changes I made are not that complicated, they made the lab a bit more realistic. Having the DNS64 server also made it more realistic and closer to the way a real solution would work.

Until we meet again.

Leave a Reply

Your email address will not be published. Required fields are marked *