Palo Alto Dual ISP, ECMP enables the external interfaces and enables IPSEC VPN tunnels.
Good afternoon, as always, thanks for the collaboration and support.
A few doubts, We currently have an PA configured with ECMP, for outbound to the Internet, with two different ISPs. We plan to configure a Site to Site VPN, with each of the ISP.
Here are the doubts, so that you can give me your opinions and suggestions:
Doubt 1: Will I have any problem when I configure the two IPSEC tunnels, with the dual ISPs ( With ECMP previously enabled ), with the IKE/ESP type traffic ? will it generate any conflict or problem with the stability of each IPSEC Tunnel ? The PA will not have problems with this type of traffic, from its Interfaces, with their respective public IPs, with their respective ISPs and Peers?
Doubt 2: If I configure, already thinking and focused on the routes, with the tunnel interfaces that are used to declare the routes of each ISP, to reach the same destination, is it feasible to use ECMP for the tunnel interfaces ( tunnel.20 and tunnel.21 ) ? to send the traffic in a balanced way ?
Doubt 3: Thinking about a Dual Fail Over scenario, not balancing, but fail over, which is better? To use routes with Path Monitoring ( At route level, in the Virtual Router VR, not at HA level ) and so in case of failure the other route becomes valid in the FIB ? Or use PBF ? If I use PBF, I am forced that the Tunnels have IP in each end to be able to monitor the other peer, right? because for example, for the case of Path Monitoring, using an IP of the range and that this allowed in the encryption domain is enough for me to sense the IP at the level of Path Monitoring Route, but with PBF, I am forced that the other end also has an IP in its tunnel interface. What is the recommendation or the best way ?
I am not talking about Dual fail over type, that one responds and in case of failure, the other responds, but an ECMP type balancing for vpn ipsec site to site traffic. This is for Doubt 2.
Thank you very much for your time, I remain attentive to your comments.
When I setup multiple ISP's, I always give one preference. This way I know how things are routed and can easily be notified if one of the links goes down. Here are my replies to your questions:
Doubt 1: You shouldnt as long as you have your routing setup correctly. I have done this many times before, this is because the ISP's use different IP's on your firewall, etc.
Doubt 2: You can, however I have run into too many routing issues. I always give one of the paths a weight to ensure I know which path the traffic is taking, etc.
Doubt 3: Either one should work just fine. I tend to use Policy Based Forwarding since the PAN takes this routing information prior to looking at the Virtual Router. (just my preference)
Hope these help out and feel free to post additional questions.
Hello @OtakarKlier , thank you very much for your time, your collaboration and your answers.
Some doubts, regarding point or doubt number 2, if it is being given a weight, for example, prefer traffic with a greater weight, example weight tunnel.20, "200" (Best link Bandwidth and stability), tunnel.21 "50" (lower bandwidth and less stability), in that case you will always be giving more weight to one connection than the other, based on the balancing algorithms, but if you have so many problems with balancing and load balancing and routing, in that case it does not contribute much or not at all useful to use EMCP for this type of scenario (VPN IPSEC DUAL load balancing)? In that case it would be better to just use type Fail Over with PBF or with static route path monitoring??
I also understand that the other important considerations are that the other peer, the other end, with its two tunnels (regardless of the Firewall manufacturer) should also have something like ECMP or similar, since if at the routing level, the other peer, always has preference for only one of its tunnels, some asymmetric traffic could occur, or ruotung problems. Since the other end does not understand that it can reach the networks behind Palo Alto, only from one of its interfaces or only from one of the tunnels, El PAlo Alto, it will send by ECMP, through one tunnel and another, and the other end, but it does not have something like ECMP, it will forward or use the return route or the return traffic, it will always be through one of its tunnels, this referring to the peer, to the other end.
Then you have to consider that in both firewalls, both in Palo Alto, and at the other end (the vendor whatever it may be), since Palo Alto could be sending traffic through a tunnel or tunnel interface of one of the IPSEC tunnels , and the other responds the same traffic and/or return route, it goes through the other tunnel, where the other firewall of the peer, from the other end, points out its preference metric to reach the networks that are behind the high pole and that knows through the ipsec tunnel, I understand that in that case we could have that type of problem, right, of symmetrical traffic? Are my considerations correct? Should asymmetric traffic be allowed in Palo Alto and at the other end?
Thank you very much for your time, for your collaboration.
I remain attentive to your comments
Here are my thoughts on your questions:
ECMP/weights = Correct ECMP should not be used if using weights to prefer one route/path over another.
Better to use PBF? = if preferring a route, yes you can.
The other device = Correct, the other device would need to be also setup to use PBF or something similar to ensure traffic goes back down the correct path. I prefer OSPF in this case and use route weights here. That way the other device will learn the routes and weights, etc.
Asymmetric traffic = I would make sure you dont have this scenario as it will not work. Best to go with weighted routes, etc.
Check out my reply to this post and see if it makes a bit more sense.
Hope this makes sense.
Hello @OtakarKlier Good afternoon, thank you for your collaboration and your time.
Yes, but now what I was referring to was the scenario of having 2 IPSEC tunnels, with ECMP enabled (IPSEC routes equal to both tunnels: Tunnel.21 and Tunnel.22) for Site-To-Site VPN traffic. so that it is balanced, so that both links, both tunnels are used (No Dual Fail Over, I mean balanced, not that if one link fails it goes through the other, where you could use Router Monitoring or PBF). So based on the above and in a Dual Balanced scenario, not Dual Fail Over, if the Palo Alto firewall with ECMP for the tunnel interfaces, and routes of the same metric, to use both links, the Palo Alto will be sending traffic through a tunnel then through the other tunnel, so to what I mean, to have a fully balanced traffic scenario, it would require that the other peer, the other end, the other firewall, from whatever manufacturer, also have some ECMP mechanism enabled, or balancing or similar, with equal metric routes, as an example if Palo Alto sends traffic through one of its tunnels, and then through the other, if the other end does not have an ECMP type balancing or similar, for the return traffic, the other end will always forward the return traffic through its route with the best metric (thinking that it does not have something like ECMP) and therefore through its route with the tunnel with the best metric and not in a balanced way, in this scenario it could eventually occur asim traffic metric, since the PA will send traffic through both tunnels in a random and/or balanced way, but if the other end does not have something like ECMP, the return traffic will always go through its best metric and therefore always through a tunnel. Now in a full scenario balanced by both ends, both devices must have the ECMP mechanism enabled so that they can send the outgoing or return traffic through both links.
Please give your comments regarding what is mentioned in this post.
Thank you in advance for your time and collaboration.
Stay tuned to your comments
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!