How To Handle NAT Reflection on a Sonicwall for a Cisco Expressway One NIC Configuration

Holy hell folks. I ran into an issue over the last few weeks that seemed way harder than it should have been in my opinion. The problem I ran into was a mix of a difference in terminology between Cisco and Sonicwall, and how they handle traffic going from an internal LAN to a WAN IP. For instance, for this setup Cisco said that I needed a NAT reflection policy on my firewall. Well, Sonicwall doesn't know what a NAT reflection policy is, because they call it a loopback policy.

Another thing I ran into is how Sonicwall handles loopback, it's not how Cisco wants it done. For instance, when you want an internal LAN server to talk to another server on it's public IP address, Sonicwall NAT's the connection outbound in order to communicate to the public IP of the server you want to connect to,

Ok, that being said, here is a really basic diagram of my setup. The IP addresses have been changed to protect the innocent. In this example, 1.1.1.1 is the public IP of my Expressway-E device that is NAT'd to it's internal LAN IP of 192.168.1.3. The Expressway-E is setup with a single NIC, with static NAT enabled.

In this configuration, Expressway-C (192.168.1.2) sends traffic to the public NAT IP of Expressway-E (1.1.1.1) so Cisco says you need a NAT reflection policy on your firewall. In an ASA firewall, you would configure that as follows:

object network obj-192.168.1.2
host 192.168.1.2

object network obj-192.168.1.3
host 192.168.1.3

object network obj-1.1.1.1
host 1.1.1.1

nat (inside,outside) source static obj-192.168.1.2 obj-192.168.1.2 destination static
obj-1.1.1.1 obj-1.1.1.1

Simple enough right? Not on Sonicwall. What I found, as I mentioned before, is that with the loopback policy, which Sonicwall documentation, and support says needs to be configured from "All firewalled subnets" usually, causes the outbound traffic of Expressway-C to be NAT'd to a public IP address in order to send traffic to the public NAT'd IP address of Expressway-E. Because of that nonsense, in order for traffic to flow the way you need it to, you actually have to assign a public NAT address for Expressway-C as well, and configure it for NAT, then use the internal and external IP of Expressway-C in a specific loopback policy with Expressway-E... Confused yet?

Let me see if I can break this down...

On the Sonicwall, assign a public IP address for Expressway-C, let's use 1.1.1.2 in this example. You will need to create a NAT rule to to point 1.1.1.2 to 192.168.1.2. Make sure it's reflexive so that the outbound traffic of 192.168.1.2 goes out as 1.1.1.2 as well. Your network should now look like this:

Now you need to create your loopback policy (NAT reflection) as follows:

• Original Source: 192.168.1.2
• Translated Source: 1.1.1.2
• Original Destination: 1.1.1.1
• Translated Destination: 192.168.1.3
• Original Service: Any
• Translated Service: Original
• Inbound Interface: Any
• Outbound Interface: Any
• Comment: NAT reflection

Once we did that, the Expressway setup correctly, and our external MRA phones were able to register and make inbound and outbound calls. When I set this up my Cisco Engineer's mind was blown, but it was the only way we could get it to work.

One thing to note, even though you created a NAT address for Expressway-C, it's still not exposed to the public in your firewall rules (At least it shouldn't be, if it is you need to check your rules). This whole setup is just so Expressway-E knows who is talking to it, and can send the appropriate traffic back to Expressway-C.

If this is confusing to you, take comfort in the fact that it took me two weeks to figure this out, and Sonicwall support, and Cisco TAC was no help at all. I'm writing this in the hopes that it will help out some other poor Systems/Network Engineer that has to make a Cisco Expressway work with a Sonicwall in the future, because there is no documentation on this ANYWHERE!

Related articles

• Microsoft breaks DHCP with latest Windows 10 update; suggests a reboot to get back online
• Juniper Networks acquires cloud optimization service AppFormix
• 3 Reasons Why Cisco Systems, Inc. (CSCO) Stock Is a Buy Now
• List of Professional Hacking Tools Straight from the Realm of Hackers - Part 1