- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
02-26-2021 01:32 PM
I have been reading up and still trying to wrap my head around the exact setup I need.
Current ISP1 - use for all LAN traffic out including IP phones. Use global protect also. Have external DNS setup so remote.mydomain.com goes to this ip address. Still want this ISP used for all traffic unless it goes down
ISP 2 - I have one backup server that offloads to azure I want to use on this link. Traffic bogs down our main link.
So here is the final setup I am trying to configure. I have a PA-820.
ISP 1 - all traffic (except for backup server) including global protect should use this ISP. This is on interface 1
ISP2 - backup server traffic only unless a failover occurs. I have connected this to interface 7
So sounds like with global protect I need two virtual routers to insure all the traffic stays on isp 1. My present tunnel is in the L3-inside zone. Not sure if I need to change that. First PBF will be for the ISP1 traffic to failover to ISP2 if it loses the ping to outside. Then I need another PBF to send the backup server traffic out isp2. I also think I need to NAT the server traffic from the L3-inside to the new L3-outside zone I created for isp2.
I think this link describes a lot of what I need. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJeCAK
If I treat the LAN traffic in the example as my backup server traffic I think that may work.
Suggestions or other good links that describe something similar to my situation?
Thanks,
V
03-03-2021 07:32 PM - edited 03-03-2021 07:35 PM
Hey
Primary VR will have all connections
This is just example
ETH1 - Untrust 32.32.32.108/29 Primary VR
ETH2 - Trust 10.10.0.1/24 Primary VR
ETH3 - DMZ 10.254.1.1/24 Primary VR
ETH4 - DMZ2 10.254.2.1/24 Primary VR
ETH5 - Untrust 33.33.33.108/29 Secondary VR
Lets say that you have Global Protect Users using 10.1.1.1-10.1.1.1.254 on Gateway 1 and GP users using 10.1.2.1-10.1.2.254 on Gateway 2.
You will need route from Secondary VR to Trust 10.10.0.0/24, 10.254.1.0/24 10.254.2.0/24 and 10.1.1.0/24
Primary VR
1 Default route - 0.0.0.0/0 - 10 to gateway 32.32.32.105
2.Route to GP2 - 10.1.2.0/24 - NEXT VR
3 More Local Routes - to Core SW if you have any
Secondary VR
1 Default Route 0.0.0.0/0 10 33.33.33.108/29
2.Route to Local 10.0.0.0/24 10 Next VR
3, Route to DMZ 10.254.1.0/24 10 Next VR
4. Route to DMZ2 10.254.2.0/24 10 Next VR
5. Route to GP 10.1.1.0/24 Next VR
6. If you have any IPSEC S2S you need to point to Primary VR
If you want to have also another ipsec S2S from secondary ISP as backup you will need to crete second tunnel and you will need to change metric and setup path monitoring if secondary VR Tunnel will go down than you still will be able to reach from Primary VR with metric 15. But if you have only one tunnel and you don't need to create another one all you do from Secondary VR route to primary with metric 10.
I hope this will help
02-27-2021 07:25 AM
Hello there.
I do not know if I would agree completely with what you are doing.
What I understood from your comments are the following
Continue to use ISP1 for all traffic and failover to ISP2 in case ISP1 is down.
Always have backup traffic use ISP2.
So, what am thinking for PBF is one rule and
PBF Rule (generally configured)
BackUp to (IP of Azure), using PBF next hop of ISP.
Routing Tab
0.0.0.0/0 for ISP1, with metric of 9
0.0.0.0/0 for ISP2, with metric of 10
All main traffic using ISP, in case of outage, then use ISP
If ISP2 is lost (for the PBF rule), then the route is removed from the routing table, and now backup uses ISP1
As for NAT, recommend to find a company like Easy DNS, that will update DNS entry for your portal, so that if ISP1 is down, the FQDN for ISP2 is listed, and you would still have connectivity to your portal and gateways.
As for outbound routing for main traffic, you are correct... 2 NATs (one for ISP1 and 1 for ISP2).
Just be sure to include the interfaces to differentiate between the 2 ISPs in the NAT rules.
03-02-2021 07:03 AM
thanks for the suggestions. We already have external DNS setup and unfortunately use the @ A record for our externally hosted website. I can add another A record for say remote2.mydomain.com. I would not failover automatically but then users could use that one if our regular goes down. That is assuming that I can setup a second portal/gateway on the firewall as a backup
03-02-2021 07:29 PM
Hello,
Global Protect with 2 ISP require 2 Virtual Routers. On each Virtual Router you will have one Default Route (not 2). You will need to configure 2 portals , 2 gateways, both pointing to the same Zone. You will need also configured routes from Secondary VR to your local Trust Interfaces, and all other networks that will terminate on VR1.
You will need to create Primary PBF rules from any local Zone and Negate local Destination Addresses and forward to VR Egress Interface IP and the same for Secondary ISP (PBF) and enforce symmetric return.
You will need to create 1 NAT for ISP1 allowing local zones to get out and the same for Secondary ISP.
After that you can configure external DNS pointing to vpn.mycompany.com ISP1 and vpn2.mycompany.com ISP2. Both of them will be active all the time. you will be able to choose which portal you would like to connect.
All local traffic will failover between VR and you don't need to create any extra Security policy since all zones are the same.
I deploy this scenario multiple times and it is working really good.
03-03-2021 03:11 PM
Thanks for the info. One question I have on setting up two VR's. I have ethernet1/2 as our inside interface connected to my switch stack. Since an interface can only be in one router how do I set up the internal route. Do I do a second interface on the firewall also connected to the switch stack?
03-03-2021 07:32 PM - edited 03-03-2021 07:35 PM
Hey
Primary VR will have all connections
This is just example
ETH1 - Untrust 32.32.32.108/29 Primary VR
ETH2 - Trust 10.10.0.1/24 Primary VR
ETH3 - DMZ 10.254.1.1/24 Primary VR
ETH4 - DMZ2 10.254.2.1/24 Primary VR
ETH5 - Untrust 33.33.33.108/29 Secondary VR
Lets say that you have Global Protect Users using 10.1.1.1-10.1.1.1.254 on Gateway 1 and GP users using 10.1.2.1-10.1.2.254 on Gateway 2.
You will need route from Secondary VR to Trust 10.10.0.0/24, 10.254.1.0/24 10.254.2.0/24 and 10.1.1.0/24
Primary VR
1 Default route - 0.0.0.0/0 - 10 to gateway 32.32.32.105
2.Route to GP2 - 10.1.2.0/24 - NEXT VR
3 More Local Routes - to Core SW if you have any
Secondary VR
1 Default Route 0.0.0.0/0 10 33.33.33.108/29
2.Route to Local 10.0.0.0/24 10 Next VR
3, Route to DMZ 10.254.1.0/24 10 Next VR
4. Route to DMZ2 10.254.2.0/24 10 Next VR
5. Route to GP 10.1.1.0/24 Next VR
6. If you have any IPSEC S2S you need to point to Primary VR
If you want to have also another ipsec S2S from secondary ISP as backup you will need to crete second tunnel and you will need to change metric and setup path monitoring if secondary VR Tunnel will go down than you still will be able to reach from Primary VR with metric 15. But if you have only one tunnel and you don't need to create another one all you do from Secondary VR route to primary with metric 10.
I hope this will help
03-09-2021 04:11 PM
Thank you. I don't have S2S but I do have one DMZ for a server with a public IP address. So I believe I can follow your solution. I do need one PBF to route the backup traffic through ISP2 but I don't care if that is down for awhile so don't need to worry about path monitoring on that one.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!