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.
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.
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 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.