05-07-2018 01:24 AM - edited 02-21-2020 07:43 AM
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!
05-07-2018 02:40 AM
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.
05-07-2018 04:23 AM
05-07-2018 04:51 AM
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.
05-07-2018 07:09 AM
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
05-07-2018 07:18 AM
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.
05-07-2018 08:26 AM
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?
05-07-2018 12:50 PM
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.
05-08-2018 04:43 AM
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
05-11-2018 03:35 AM
Any other idea guys?
05-13-2018 12:41 AM
Do you have any dynamic routing policies that might be overriding the PBR?
05-13-2018 07:46 AM
06-08-2018 04:57 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide