cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
833
Views
10
Helpful
12
Replies

ASA 9.6 PBR and NAT

Florin Barhala
Level 6
Level 6

Hi guys,

 

I have an Active-Active cluster running 9.6 (5525X). 

I currently have 3 interfaces:

 - inside

 - mpls_link

 - outside

and a network for which I do SNAT from inside to outside. This would be the current scenarion.

 

Now for one host behind inside I have applied PBR and sent it over the mpls_link.

All traffic over MPLS link also requires NAT so I have added above (etwork for which I do SNAT from inside to outside) a SNAT statement: inside to mpls_link.

 

I have tested for that host and it doesn't work.

Also packet tracer from CLI says packet is being dropped at step 14.

 

I have read 9.6 guide that states:

" PBR Policies Not Applied for Output Route Look-up

Policy Based Routing is an ingress-only feature; that is, it is applied only to the first packet of a new incoming connection, at which time the egress interface for the forward leg of the connection is selected. Note that PBR will not be triggered if the incoming packet belongs to an existing connection, or if NAT is applied."

 

What do I make of this? NAT & PBR doesn't work along?

 

Thanks! 

12 Replies 12

Both features are more or less independent. But they are working together. Your scenario is not that uncommon. I just assume that you just configured something wrong or just missed something. But without seeing what your NAT/PBR configuration is and what exactly goes wrong, it's impossible to say what that is.

That is good news! At least from your sayings both features are compatible together.
What output you think it's useful: show run nat, show route-map, show run int (inside)
or maybe packet-tracer output?

Last but not least, what would be the packet flow in this case:
- inside_interface IN direction ACL
- PBR
- source_NAT
or

- inside_interface IN direction ACL
- source_NAT
- PBR ; if the latter then I have to update my PBR statements

Thanks!

The PBR and NAT-config is needed. The result of packet-tracer is always a good idea to show.

For the order of operation, the PBR-decision is done first, the outgoing interface is selected and then the NAT is done.

 

PBR config:

access-list PBR_ACL line 1 extended permit ip object 10.26.30.28 object-group DM_INLINE_NETWORK_30 (hitcnt=0) 0xa2653c88
access-list PBR_ACL line 1 extended permit ip host 10.26.30.28 host 16.9.18.115 (hitcnt=0) 0x4039a6f7
access-list PBR_ACL line 1 extended permit ip host 10.26.30.28 host 22.9.22.3 (hitcnt=0) 0x362d8556

 

route-map PBR_RM, permit, sequence 10
Match clauses:
ip address (access-lists): PBR_ACL

Set clauses:
ip next-hop 91.24.4.13

 

show arp | i mpls_link
mpls_link 91.24.4.13 002c.e8a9.7880 1379

 

show run int Port-channel22.112
!
interface Port-channel22.112
nameif inside
security-level 100
ip address 10.22.0.16 255.255.255.240 standby 10.22.0.17
policy-route route-map PBR_RM

 

NAT config:

 

show run nat | i 10.226.130
nat (inside,mpls_link) source dynamic 10.26.30.28 ext-mpls-network_NAT destination static DM_INLINE_NETWORK_29 DM_INLINE_NETWORK_29 description PBR policy

 

object-group network DM_INLINE_NETWORK_29
network-object object 16.9.18.115
network-object object 22.9.22.3

 

 

Your PBR looks good, same for the NAT statement. But is that NAT-statement really used? Or do you have an also matching NAT before this line? Packet-Tracer should tell you that.

I just tested packet tracer for HTTPS and ICMP:

 

packet-tracer input inside tcp 10.26.30.28 3333 16.9.18.115 https detailed 

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: mpls_link
output-status: up
output-line-status: up
Action: allow

 

But I can't say the same about ICMP; I tested it last week and here's full output:

 

  packet-tracer input inside icmp 10.26.30.28 11 0 16.9.18.115 detailed 

Phase: 14
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x2aaad83e6f00, priority=0, domain=user-statistics, deny=false
hits=126440, user_data=0x2aaad838d9c0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=link_assurant_wan

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: mpls_link
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

 

Let's see the FW config:

 

access-group INSIDE_IN in interface inside

show access-list INSIDE_IN | i 10.26.30.0

access-list INSIDE_IN line 48 extended permit icmp 10.26.30.0 255.255.254.0 host 16.9.18.115 log disable (hitcnt=4) 0xf60dbf01
access-list INSIDE_IN line 48 extended permit icmp 10.26.30.0 255.255.254.0 host 22.9.22.3 log disable (hitcnt=18) 0x79a62db8

 

What do you think?

You are using ICMP code type 11 which is time-exceeded.  Have you tried with code 8 and code 0 (echo and echo-reply respectively)?  Theoretically your setup should work even with time-exceeded.  Perhaps try a test rule 

access-list INSIDE_IN extended permit ip 10.26.30.0 255.255.254.0 host 16.9.18.115

Just to see if it is actually the access rule that is dropping the traffic.

 

I just set this up in my virtual lab (but I used dynamic NAT for both interfaces) and got it working fine, With ICMP and other traffic.  However I used a permit IP any any on my inside interface.

--
Please remember to select a correct answer and rate helpful posts

This is getting worse!

I had the time today to further test and capture and got only bad news. Here's the summary:

 - packet tracer on tcp/443 says that packet is allowed

 - both telnet 443 and captures on the two involved interfaces (inside and mpls_link) tells me that it doesn't work. 

 

What can I take from this? That packet tracer is buggy on 9.6(3)1?

 

Tech details:

packet-tracer input inside tcp 10.26.30.28 52696 16.9.18.115 443 detailed 

capture cap1 type raw-data access-list capture_inside interface inside [Capturing - 2480 bytes]
capture cap2 type raw-data access-list capture_mpls interface mpls_link [Capturing - 0 bytes]

 

sa capture_inside
access-list capture_inside; 2 elements; name hash: 0xb0dbe7a9
access-list capture_inside line 1 extended permit ip host 10.26.30.28 any4 (hitcnt=24) 0x3cf6b232
access-list capture_inside line 2 extended permit ip any4 host 10.26.30.28 (hitcnt=0) 0x2bf3d83c
sa capture_mpls
access-list capture_mpls; 4 elements; name hash: 0x71ebc2b3
access-list capture_mpls line 1 extended permit ip host 16.9.18.115 any4 (hitcnt=0) 0x7d29173c
access-list capture_mpls line 2 extended permit ip any4 host 16.9.18.115 (hitcnt=0) 0x7d764a9a

Any other idea guys?

Do you have any dynamic routing policies that might be overriding the PBR?

--
Please remember to select a correct answer and rate helpful posts

I receive default route through BGP - but other than that I don't know what "dynamic routing policy" means.

Thanks!

An update for anyone interested: PBR was not working because of me using also NAT.
More specific I was using Twice NAT statements as I was intending to source nat only for a specific destination.

I quit NAT and PBR worked fine. Then a colleague suggested to also try with Object NAT and guess what: it worked! Pity the documentation: 9.6 to 9.9 adds no real detail about the inter operability between NAT and PBR (yet)
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: