Playing with NAT on a Watchguard for non primary IP addreses

Yeah, I can already hear you saying “Why would I need to do this?”
Well, you can have a few reasons. For example you can NAT different subnets out different IP addresses for multi tenancy. Configure Natting for optional interfaces. Or as in the case I had recently… your ISP buggers up BGP.

Feel free to skip the horror story and scroll down to “The Method” for a technical explanation of changing your Primary NAT IP

The Example setup

So I’ll quickly explain what happened to one of my customers recently. We have a pair of XTM 330’s in the process of migrating to a FireCluster with redundant Internet connections. An EFM link and a backup ADSL connection.
The EFM circuit came with a /30 IP range to begin with and since expanded to include a couple of /29’s as well, one range is attached direct to the WatchGuard cluster and the other is routed to a DMZ behind the cluster

This morning at 7AM I have one of the guys from the office call in advising the link was down. My first question was of course “has it failed over to the ADSL?” to which the answer was “No.”
The Watchguard itself could see quite far into the carriers network and thus didn’t mark the link is bad. This is by design and trust me saves you more grief than just pinging a single known host

Interestingly IP addresses from the /29 were working fine. But as these were not the “Primary” address for the Watchguard normal internet bound traffic would fail.

Investigation showed that the /30 Ip address tied to the Watchguard had somehow lost its BGP advertisement (I don’t pretend to be a BGP guru.. but a quick haunt around some looking glasses showed big routing issues) yet as the /29s were in a different IP range their advertisements were working fine.

The issue

So we’re stuck with the problem. Do we failover to the backup ADSL and allow the 60+ staff to access the internet whilst the BGP issue with the carrier is fixed? Taking our DMZ offline or do we change our failover preferences to make the ADSL the primary link.

Option 1 was ruled out as some services in the DMZ were required to communicate to other business units that the VPN endpoint was offline

Option 2 was ruled out due to several IPSec tunnels being on the EFM link and we wern’t sure of the impact the Failover changes would make

A third option presented itself, Re-use a “spare” ip in the /29 as a primary NAT IP until the carrier can sort their stuff out and then simply remove the NAT rule.

 

This solution isn’t perfect either. But it was the quickest way we can get the clients back online and breaks the least amount of services whilst having the minimum risk and allowed remote rollback if things took a turn for the worse.
Yes. There would be some breakage to external 3rd parties locking down access via IP address, but we can add static routes out the functioning ADSL link as we always tell 3rd parties to include our backup addresses. As any network engineer can tell you during an outage, the best solution is not always the prettiest.

The Method

The actual fix is quite simple, but can be used for quite a few things and is often forgotten about in the Watchguard configuration.

Head on over to “Network > NAT…” and you will notice the basic 3 networks.

The screen is pretty self-explanatory, but for those new to the game we will take a quick look at the top rule.

192.168.0.0/16 – Any-External
This rule is dead simple, after passing through the Policy list and before the packet is routed out an interface, the traffic is checked against this list. If the source (192.168.0.0/16) and the destination (Any-External) match a rule in the Dynamic Nat List the packet is NATted using the exit interface’s IP address as a source address using PAT to track the connection. If not the packet is routed untouched. Similar to how Cisco does NAT with an ACL and Overload.
Note I should point out here.. Natting applies AFTER firewall policies so don’t expect to “Nat some magic” then apply firewall rules

What isn’t obviously apparent when first looking at this, is that NAT is really configurable on these devices.
– You can NAT traffic from your remote offices into other private networks and have the traffic appear to come from your LAN. This removes the issue of the private network needing to know how to “route back” to you.

• You can Nat traffic out a 3rd party link instead of routing it to provide an additional layer of security (and yes. You can static nat back)

• You can specify the IP address to use on an interface rather than letting the interfaces Primary address dictate everything.

Click on “Add…”

Here you can select any Network, Network or Host Alias or Interface as the source and destination. But the part here that makes the WG more powerful than anyone really realises is that you don’t need to select an external address as well as the “Set source IP” option.
Fill in the Source interface/network and the interface/network your packets are heading to. Set your source address as an IP that is tied to the exit interface and click OK.

Make sure to move this rule to the Top for it to apply

In this case I specified an IP address from the /29 attached to the EFM link that still had its route being advertised by the carrier and saved the config to the Watchguard.

Traffic was now coming from the secondary /29 tied to the same interface, the carrier router picked it up as it was in the allowed network and sent the traffic along. This time with return traffic making back thanks to working BGP.

 

What horror stories have you fixed with a quick NAT or similar technology? Comment below.