- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-31-2017 03:11 AM
Hi Guys,
We have two isp links (ISP1 AND ISP2). We have defined to default gateways and set the ISP1 less priority so that all internal traffic will take ISP1.
for example
0.0.0.0/0 ethernet 1/1 next hop 76.45.146.22 admindistance 10 metric 1
0.0.0.0/0 ethernet 1/2 next hop 89.54.54.56 admindistance 10 metric 2
In this scenario. We have published SMTP via ISP1 AND our web server via ISP2.
My query is, when some one from internet access the web server it will go through via ISP2, get natted to public ip of the web server and will reach the server LOCAL which is in the DMZ. But... when the local server responds to the request, would it take ISP1 or ISP2?
03-31-2017 06:03 AM
This sounds like it would make a really good example for Policy Based Forwarding. Since your highest priority route for all traffic is ethernet1/1 the return traffic would attempt to take that route; however with a PBF policy configured you could actually specify that HTTP/HTTPS traffic from your webserver actually needs to Egress from ethernet1/2 next hop 89.54.54.56 and this would actually superseed the metric in your routing table.
03-31-2017 06:06 AM - edited 03-31-2017 06:08 AM
Yeah, PBF is the way to go. There you also have an option 'enforce symmetric return'. That way your server is visible on both ISPs all the time.
03-31-2017 04:34 AM
Hi
thanks for your comment! I'll move this topic over to the general discussion area as it was posted in the feedback board
03-31-2017 06:03 AM
This sounds like it would make a really good example for Policy Based Forwarding. Since your highest priority route for all traffic is ethernet1/1 the return traffic would attempt to take that route; however with a PBF policy configured you could actually specify that HTTP/HTTPS traffic from your webserver actually needs to Egress from ethernet1/2 next hop 89.54.54.56 and this would actually superseed the metric in your routing table.
03-31-2017 06:06 AM - edited 03-31-2017 06:08 AM
Yeah, PBF is the way to go. There you also have an option 'enforce symmetric return'. That way your server is visible on both ISPs all the time.
04-01-2017 01:47 PM
Thanks you.
I tried PBF with simetric routing. and it worked. i was having several discussion with palo alto engineers. because. currently we are migrating fortigate firewall to palo alto firewall. in Fortigate firewall the return traffic is taking the same path as it arrived even without PBF. As far as i understood firewall will notedown the ingress and egress interface in its session table. with that asumption and despite the face that fortigate does not have any PBF. we configured same configuration as the fortigate and failed the migration.
We learned in hard way...
Thanks for all for your comments.
09-09-2024 02:05 AM
Secondary ISP not able to ping form external
I have two ISPs connected to my Palo Alto firewall:
1. ISP1 is in the ISP1 zone, with a default route metric value of 10.
2. ISP2 is in the ISP2 zone, with a default route metric value of 15.
3. Both ISPs are in the same virtual router.
I am facing an issue where I am unable to ping ISP2 from an external network.
The only time I am able to ping ISP2 from my home (public IP) is when I configure a static route on the Palo Alto firewall in the virtual router, pointing to the ISP2 interface.
Here are the configurations I have made on my Palo Alto firewall:
Security Policy: ISP2 to ISP2 — Allow all (any to any)
PBF (Policy-Based Forwarding): Configured with the following:
Source: ISP2, Source Address: any
Destination: any
Forwarding to ISP2 interface with Enforce Symmetric Return enabled
NAT Policy:
Source: ISP2, Destination: ISP2
Destination Interface: ISP2 interface
Source and Destination: any
Translated to Dynamic IP and Port, pointing to ISP2 interface
Could someone please assist me in resolving the issue?
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!