IP SLA - but not dual ISP. Receiving and Forwarding from the same Interface.

Reply
L0 Member

IP SLA - but not dual ISP. Receiving and Forwarding from the same Interface.

hi, I know PA doesn't have IP SLA and i've read documents that talks about using VR and PBF to handle dual ISPs.

this works with an ASA but not sure how to do it with PA.

 

But there's a slight difference on my implementation and it seems to fail with a lot of SSL sites:

 

I have two links at each site.

First Link, ISP <----> Palo alto (10.1.1.1) <----> L3 Switch (10.1.1.3)

Second Link, MPLS <----> Cisco Router (10.1.1.2) <---> L3 Switch (10.1.1.3)

Basically, I have a layer 3 switch that connects both PA and Cisco Router to the same LAN (10.1.1.0).

 

1) All Devices talk to each other via OSPF

2) PA Firewall has a static default route with metric 5 to ISP

3) Cisco Router has a static default route with metric 10 to MPLS Cloud (where there is another internet breakout)

4) PA Firewall and Cisco router redistribute default route into OSPF.

5) Layer 3 sees PA firewall with better metric and sends to PA firewall when PA Firewall is up.

 

The idea is if I can't reach 8.8.8.8 on PA, it will tell me to send it out via the MPLS. This is accomplished in the past with IP SLA on the static route on the ASA, where the static route is removed and L3 stops forwarding traffic to the ASA. 

 

 

PA recommends using PBR to "monitor" IPs. The challenge I have is that when PA receives traffic, and forwards traffic out of the same interface (back to MPLS) , SSL traffic seem to stall.

 

Example when ISP is down:

1) User sends to L3 switch.

2) L3 switch sends packets to PA's ingress e1/1

3) PA determines ISP is down, and sends packet back out the same interface (e1/1) to Cisco router on the same LAN.

 

This seems to work for non-SSL. but fails with secure traffic to Google, facebook, etc... it just hangs 

 

Any thoughts?

L4 Transporter

Re: IP SLA - but not dual ISP. Receiving and Forwarding from the same Interface.

Hi,

 

In your case, when ISP connected to PA is down, is all the forward traffic (Client-> Internet) still going through the Palo Alto?

 

Two things are possible:

 

1. When Palo Alto forwards traffic back to Cisco, it sends a ICMP redirect to the L3 switch. I don't think PA does that.

2. Palo Alto sends traffic to Cisco, which forwards it out to Internet, but the reply traffic is forwarded directly by Cisco to L3 switch. 

 

In case 2 above, Palo Alto will only be seeing half of the traffic and this is a scenario of asymmetric routing. Palo Alto session will not see a SYN/ACK so the session does not matures and times out after 5 seconds (Default TCP init timeout).

 

You can do two things,

 

1. Allow asymmetric bypass on the PA firewall and disable TCP Reject Non SYN:

 

# set deviceconfig setting tcp asymmetric-path bypass

set deviceconfig setting session tcp-reject-non-syn no

# commit

 

2. Do a hair pinning NAT, so that when PA firewall forwards the traffic to Cisco, it does a source NAT on this traffic, so that the Cisco will see traffic coming from PA, and hence will forward reply packets to PA. For this create a source NAT rule from trust to trust zones doing a source NAT on e1/1 IP.

 

Regards

L0 Member

Re: IP SLA - but not dual ISP. Receiving and Forwarding from the same Interface.

Abjain, thanks for the quick reply. What you've described makes perfect sense.

I will give it a shot over the weekend and hopefully, it'll work.

 

(will come back and give an update either way).

 

 

 

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 Live Community as a whole!

The Live Community thanks you for your participation!