Route specific traffic out backup ISP?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Route specific traffic out backup ISP?

L4 Transporter

We have dual ISP (ISP-A and ISP-B) and utilizting PBR which works just fine.  Now I have use case whereas I have a NAT configured on ISP-B (1 to 1) and I want to force traffic to a specific destination out the backup interface.  I want to do this to ensure traffic destined for a specific address IP-B is sent out the backup interface.  I tried adding a specific route on the VR with the interface and next hop as ISP-B but the path from behind the PAN still takes the primary interface and hop.  

 

I am missing something but not sure what?  

1 accepted solution

Accepted Solutions

Cyber Elite
Cyber Elite

@drewdown,

You'll want to configure a PBF (Policy-Based Forwarding) policy for something like this. 

View solution in original post

13 REPLIES 13

Cyber Elite
Cyber Elite

@drewdown,

You'll want to configure a PBF (Policy-Based Forwarding) policy for something like this. 

Cyber Elite
Cyber Elite

Hello,

This is because the PBF takes affect prior to the virtual router. So do what @BPry suggested. Just make sure to put it higher in the list than your failover policy.

 

Regards,

I just created a PBR for that source network and the specific destiantion IPand its at the top of my list. 

 

When I traceroute from the core behind the router I see the right path. 

 

traceroute 125.17.100.5 source vlan99
Type escape sequence to abort.
Tracing the route to 125.17.100.5
VRF info: (vrf in name/id, vrf out name/id)
1 10.10.2.5 1 msec 1 msec 1 msec
2 111.44.44.33 4 msec 3 msec 3 msec  (DG OF ISP-B)
3 14.142.20.129 6 msec 4 msec 5 msec
4 172.31.167.137 27 msec 23 msec 23 msec
5 172.31.167.46 21 msec 21 msec 20 msec

 

But from the PAN I don't see packets from that NAT going out or coming in.  The provider on the far end sees the packets with the SOURCE IP of my backup interface and not the NAT in question.  IE ISP-B interface 111.44.44.37 vs  1 to 1 NAT 111.44.44.38

 

So something is amiss but I don't know what.  

Hello,

Check the order of your NAT's, I suspect that its using the wrong one. I've been caught out by this a few times. 

 

Regards,

The 1 to 1 NAT in question is at the top of the list, followed by the dynamic NAT statements for ISP-A and ISP-B. 

 

Is there a command I can run to see if a NAT is being applied to certain traffic based on source IP?  

@drewdown,

Within the CLI you can run 'test nat-policy-match' and build out the complete traffic match and it'll tell you the exact NAT policy that the traffic will match. 

Thanks...it shows its applying the NAT from the source and destination IP I created the NAT for.  Still don't understand why the provider would tell me they are seeing .37 vs .38 NAT'd IP.  

 

test nat-policy-match source 192.168.25.33 destination 125.17.100.5 protocol 1

Source-NAT: Rule matched: NAT-provider-1to1
192.168.25.33:0 => 111.44.44.38:0 (1), ethernet1/3

-------------------------------------------------------------------------------

 

@drewdown,

I would attempt to contact the provider and have them verify the source-address they are getting on their end again, maybe they just typo'd. I've never had nat-policy-match lie to me unless I entered something in wrong, but maybe? You can also verify within your own logs what NAT address was actually applied to the traffic, so verify that the address is being recorded correctly and that the logs aren't also indicating the wrong NAT IP. 

So its fixed.  It looks like the PAN was holding onto the old sessions before the NAT?  Once I cleared them it started using the NAT IP and the connection started to work.  Does PA not kill sessions after x amount of time?

 

\UNfrotunately I didn't do a show prior to clearing them...

 

admin@fw-PAN(active)> show session all filter source 192.168.25.33

--------------------------------------------------------------------------------
ID          Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])
Vsys                                          Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
124573       ipsec-esp-udp  ACTIVE  FLOW  NS   192.168.25.33[4505]/trust/17  (111.44.44.38[4505])
vsys1                                          125.17.100.5[4500]/untrust  (125.17.100.5[4500])
114885       ipsec-esp-udp  ACTIVE  FLOW  NS   192.168.25.33[4505]/trust/17  (111.44.44.38[4505])
vsys1                                          14.140.164.65[4500]/untrust  (14.140.164.65[4500]

Thanks for all your help dudes. 

@drewdown,

It'll kill traffic depending on what the identified application is; however if you kept sending the traffic it would continue to use the established session which is what you were running into. Going forward if you want to verify that the traffic isn't running on an old session use the 'clear session all filter' command from the CLI and you can specify everything you did with the test command to ensure all traffic will be utilizing the new policies. 

Thanks..

 

BTW I don't see anything your first post regarding PBR, its like you attached or pasted a pic but I dont see anything.  

@drewdown,

I didn't include a configuration example for PBF in my first post, however if you need one just let me know ... also stop calling it PBR. Its Policy Based Forwarding now bud, you leave those Cisco/Juniper terms where you found 'em 😉 

@BPry Old habits die hard I guess.  And PA could have just as easily called it PBR.  🙂   

  • 1 accepted solution
  • 10398 Views
  • 13 replies
  • 0 Likes
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!