I needed to route an FQDN (Fully Qualified Domain Name) down an IPSEC VPN tunnel but couldn’t because it was an external address and the IP is dynamic so I wasn’t able to just make a static route to force it down the IPSEC VPN tunnel. To solve this I discovered something called policy based forwarding.
In this post, I will explain the setup and the reason for why I used policy-based forwarding to solve my problem and I will show step-by-step how to do all of this with a Palo Alto Networks firewall.
The Background
For the setup, Palo Alto Networks firewalls are being used. There are two sites the Head Office and the Data Center. There is an IPSEC VPN tunnel between both sites. The Data Center firewall also has various vendor IPSEC VPN tunnels.
The Head Office firewall has its own internet connection as does the Data Center firewall. The Head Office firewall is configured with static routes to only send traffic for the Data Center down the Data Center IPSEC tunnel. All other traffic goes out the Head Office WAN.
Configuring it this way allows for a very simple and basic SD-WAN type configuration, only essential traffic is sent down the Data Center IPSEC VPN tunnel freeing up the IPSEC tunnel from normal internet traffic that does not need to be routed to the Data Center.
The Problem
There are two vendors we’ll call them Vendor1 and Vendor2. Both of them have an Oracle database that users at the Head Office site need to connect to.
Vendor1 has an IPSEC VPN tunnel from the Data Center firewall to the firewall at Vendor1. The Oracle database on their end is on a private IP. All traffic from the Data Center to Vendor1 is NATed behind a specific IP. Vendor1 only allows connections that are from that NATed IP over the IPSEC VPN tunnel.
Vendor2 won’t set up an IPSEC VPN tunnel. The Oracle database for Vendor2 is an FQDN we’ll say that the FQDN is Oracle.Vendor2.com the resolving IP of that FQDN can and will change without notice. The only way users can connect to the Oracle database at Vendor2 is for Vendor2 to add the WAN IP to an allowed list on their side. This process is slow and doesn’t scale well. To help with this we can have Vendor2 add a specific WAN IP to their allow list that we can NAT our traffic to them behind.
Now this works for the most part when you tunnel all traffic from the Head Office to the Data Center firewall. The problem with this solution is that it can be very costly as you may need an E-Line/MPLS/VPLS connection back to the Data Center and depending on the location they can be very expensive. If the Head Office moves to a new physical location coordinating an E-Line/MPLS/VPLS move is not always the quickest option. Ideally, we want a solution that allows for flexibility.
Yes, you could IPSEC tunnel all the Head Office traffic back to the Data Center but why? Why would you want Microsoft 365 traffic and other normal internet traffic going down your Data Center IPSEC tunnel? This just adds unnecessary overhead and can cause slowness, especially today as so many applications are web-based.
The overarching problem in all of this is how to scale it without needing to reach out to the vendors to add a new IP to the allow list or to build a new IPSEC VPN tunnel.
The Solutions
The solution for Vendor1 is simple because it’s a private IP. We can just add a static route on the Head Office firewall telling it to go down the Data Center IPSEC VPN tunnel and out the Vendor1 IPSEC tunnel from the Data Center.
If a user at the Head Office tries to access the Oracle database at Vendor1 the traffic goes to the Head Office firewall hits the static route and goes down the Data Center IPSEC tunnel to the Data Center firewall and then from the Data Center it gets NATed to the correct IP and then goes out the Vendor1 IPSEC tunnel right to the Oracle database. This works perfectly.
For Vendor2 the Oracle database FQDN is Oracle.Vendor2.com and this resolves to a public IP. Technically speaking, we could look at what the current IP of the FQDN is and make a static route for that however, when the IP changes it all falls apart and we have to manually fix it so that’s not a good solution.
The solution for Vendor2 is policy-based forwarding. With policy-based forwarding, we can re-route an FQDN to a different interface, in this case we can route it down the Data Center IPSEC VPN tunnel to then NAT the traffic behind the IP on the Vendor2 allow list.
The Deployment
Here is how to set up the Policy Based Forwarding rule to route traffic for Oracle.Vendor2.com down the Data Center IPSEC VPN tunnel.
- Login to the Head Office Palo Alto firewall.
- Click on Objects
- Click on Addresses
- Click on Add
- Change the Type to FQDN
- Give it a name and enter the FQDN.
In my example, I will call it Oracle at Vendor2 and I will enter Oracle.Vendor2.com as the FQDN.
We now have an Address Object that uses an FQDN. Now let’s use it in a policy.
- Click on Policies.
- Click on Policy Based Forwarding.
- Click on Add
- Set your source zone then for the destination select the Address Object you just created.
In my example, I will select the address object named Oracle at Vendor2.
- Set the action as Forward
- Set the Egress Interface to the Data Center IPSEC tunnel interface.
In my example, the IPSEC tunnel to the Data Center is on the interface tunnel.2.
- Set your Next Hop info.
In my example, my tunnel has an interface address so I will set the next hop to be the interface address.
In the end, you should have a Policy Based Forwarding Rule that looks something like the image below.
Depending on your setup you may need to configure a security rule on the Head Office firewall allowing the Oracle database traffic to Vendor2 down the Data Center IPSEC VPN tunnel. You may also need to tweak your Data Center firewall to allow that traffic.
Once the changes are committed if a user at the Head Office tries to access Oracle.Vendor2.com their traffic will hit the Head Office firewall and from there it will hit the policy-based routing rule which will send it down the Data Center IPSEC tunnel which will make it hit the Data Center firewall and get NATed to the IP that is on the Vendor2 allow list and send it out to Vendor2 as if the connection originated from the Data Center.
Setting it up this way allows us to maintain full control and you don’t have to annoy your vendors as you scale or move physical location as they don’t need to change anything and everything is modular making your life easier.
Here is an example traceroute to Oracle.Vendor2.com from the Head Office before the policy-based forwarding rule.
Here is an example traceroute to Oracle.Vendor2.com from the Head Office after the policy-based forwarding rule.
That’s all it takes to use policy based forwarding to route an FQDN address down an IPSEC tunnel.
Behind the scenes the Palo Alto firewall is looking up what the IP is of the FQDN but it also looks at the TTL entry for the FQDN and will check in to see if it changed based on the TTL of the DNS entry. This is a long way of saying that the Palo Alto firewall is acting like a DNS server.
If you want to read more about Policy-Based Forwarding here is the Palo Alto Networks documentation about it.
