Adding a 2nd ISP
cancel
Showing results for 
Search instead for 
Did you mean: 

Adding a 2nd ISP

L2 Linker

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

 

1 ACCEPTED SOLUTION

Accepted Solutions

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

 

View solution in original post

6 REPLIES 6

Cyber Elite
Cyber Elite

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.

 

 

 

 

 

Help the community: Like helpful comments and mark solutions

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

L1 Bithead

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.

 

 

 

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?

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

 

View solution in original post

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.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!