- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-31-2018 10:52 AM - edited 08-31-2018 10:53 AM
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?
08-31-2018 11:18 AM
You'll want to configure a PBF (Policy-Based Forwarding) policy for something like this.
08-31-2018 11:18 AM
You'll want to configure a PBF (Policy-Based Forwarding) policy for something like this.
08-31-2018 11:38 AM
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,
08-31-2018 11:38 AM - edited 08-31-2018 11:40 AM
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.
08-31-2018 11:40 AM
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,
08-31-2018 11:44 AM - edited 08-31-2018 11:45 AM
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?
08-31-2018 11:49 AM
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.
08-31-2018 11:53 AM - edited 08-31-2018 11:56 AM
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
-------------------------------------------------------------------------------
08-31-2018 12:06 PM
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.
08-31-2018 12:44 PM - edited 08-31-2018 12:46 PM
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.
08-31-2018 12:46 PM
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.
08-31-2018 12:47 PM
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.
08-31-2018 06:31 PM
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 😉
09-02-2018 12:38 PM
@BPry Old habits die hard I guess. And PA could have just as easily called it PBR. 🙂
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!