ASA Policy Based Routing Question

[Wolfgang]

Hi Cisco Profs,

first, dont ask me why we have to use it that silly way... this is a specification from your partner. We have different access levels based on the source IP and Router.

As you can see on the attached picture is have 2 internal networks, one routed and one as vlan layer 2. Both are translated (hide nat) on the ASA but they need to go over different routers to reach the same destinations. What i have tested so far, when i add 3 routes to the target networks over the 172.17.34.1 router, the 10.1.0.0/24 network can access this destinations without a problem.

I added a ACL for PBR with source 192.168.172.0/24 and as destination the target networks (192.168.46/49/50), next hop 172.17.223.1 and added this PBR to the interface of 192.168.172.1. After that i can ping router interface 172.17.223.1. but i cannot reach the target networks. When i do a packet trace with an IP out of 192.168.172.0/24 and destination 192.168.46.2.2, i can successful reach the target, when im doing it live i only get a "routing failed to locate next hop..." 

Can somebody tell me where my fault here is? Do i need PBR on both internal interfaces?

Config Snip:

interface TenGigabitEthernet0/8.823
vlan 823
nameif LAN-PBR
security-level 50
ip address 192.168.172.1 255.255.255.0
policy-route route-map PBR

route-map PBR permit 1
match ip address PBR-ACL
set ip next-hop 172.17.223.1
set interface Interface-172.17.223.2

Thanks a lot!

[dukenuk96]

Hello!

1. Can you please share the full config of your ASA.

2. Show full output of your packet-tracer tests.

3. I would recommend to use PBR on both interfaces in your setup, so that there was no leaking to default routing

[Wolfgang]

Hi,

i can provide this infos, but i need some time to get rid of the confidential infos in it.

I think the problem is NAT. If i disable the Dynamic NAT statement which translates the 192.168.172.0/24 network to one IP out of 172.17.223.x network the PBR matches. The problem is, the package needs to be translated... so NAT is before routing... is there a way to get this scenario to work with the hide NAT and Policy-Based routing?

[dukenuk96]

Thougnt on your words a little more. Let's see in my packet-tracer:

ASA/vdc-1/act# packet-tracer input inside tcp 192.168.168.168 9000 8.8.8.8 90 detailed

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 via x.x.x.x, outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group AL-Inside-In in interface inside
access-list AL-Inside-In extended permit ip object-group OGN-Internal-Hosts any
object-group network OGN-Internal-Hosts
 network-object 192.168.0.0 255.255.0.0
Additional Information:
 Forward Flow based lookup yields rule:
 in id=0x7ffed50b67c0, priority=13, domain=permit, deny=false
 hits=7, user_data=0x7ffecbf42340, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
 src ip/id=192.168.0.0, mask=255.255.0.0, port=0, tag=0
 dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
 input_ifc=inside, output_ifc=any

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) after-auto source dynamic OGN-Internal-Hosts pat-pool ON-PAT-to-Addrs extended flat include-reserve round-robin description "Internal hosts PAT to Internet"
Additional Information:
Dynamic translate 192.168.168.168/9000 to y.y.y.y/9000
 Forward Flow based lookup yields rule:
 in id=0x7ffed5d602a0, priority=6, domain=nat, deny=false
 hits=6, user_data=0x7ffed5d5dec0, cs_id=0x0, flags=0x0, protocol=0
 src ip/id=192.168.0.0, mask=255.255.0.0, port=0, tag=0
 dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
 input_ifc=inside, output_ifc=outside

So, ASA makes NAT after routing. But this is my case, I have no PBR enabled, version 9.2(4).

And, which version of software asre you running? There is big changes between 8.x and 9.x for ASA in routing.

There is easier way to do it even without PBR - migrate to multiple context and you will get simple configs with a few static routes and NATs.

[Wolfgang]

I'm certainly not migrating to multiple context because of this ;) But thanks.
I think the only way is to let the Router RT2 do the NAT after i do the PBR.

We dont have access to this router but i'm sure the company who maintains this router can do this for us.

PS: Still open for suggestion, if i'm on the wrong path here!

[dukenuk96]

You know - VDCs are not so difficult as you may think, anyway it's your network.

If you will share your config, I could try to reproduce it in a lab environmnet to find the truth, since ver 9.4 in ASA, there is documented support for PBR.

[Wolfgang]

Then try it again with PBR activated. As soon as NAT is activated, the PBR is ignored.

NAT enabled (ngTARGET is a Group of Objects which includes the 192.168.46/49/50):

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (INSIDE,OUTSIDE) source dynamic INSIDE interface destination static ngTARGET ngTARGET Additional Information:
NAT divert to egress interface OUTSIDE
Untranslate 192.168.46.33/0 to 192.168.46.33/0

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.172.22 using egress ifc INSIDE

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
.....
Additional Information:

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (INSIDE,OUTISDE) source dynamic INSIDE interface destination static ngTARGET ngTARGET
Additional Information:
Dynamic translate 192.168.172.22/0 to 172.17.223.2/36187

NAT disabled:

Phase: 1
Type: PBR-LOOKUP
Subtype: policy-route
Result: ALLOW
Config:
route-map PBR permit 10
match ip address ACL-LAN-PBR
set ip next-hop 172.17.223.1
set interface OUTSIDE
Additional Information:
Matched route-map PBR, sequence 10, permit
Found next-hop 172.17.223.1 using egress ifc OUTSIDE

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.172.22 using egress ifc INSIDE