I have an Active-Active cluster running 9.6 (5525X).
I currently have 3 interfaces:
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?
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.
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.
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 220.127.116.11 (hitcnt=0) 0x4039a6f7
access-list PBR_ACL line 1 extended permit ip host 10.26.30.28 host 18.104.22.168 (hitcnt=0) 0x362d8556
route-map PBR_RM, permit, sequence 10
ip address (access-lists): PBR_ACL
ip next-hop 22.214.171.124
show arp | i mpls_link
mpls_link 126.96.36.199 002c.e8a9.7880 1379
show run int Port-channel22.112
ip address 10.22.0.16 255.255.255.240 standby 10.22.0.17
policy-route route-map PBR_RM
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 188.8.131.52
network-object object 184.108.40.206
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 220.127.116.11 https detailed
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 18.104.22.168 detailed
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
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 22.214.171.124 log disable (hitcnt=4) 0xf60dbf01
access-list INSIDE_IN line 48 extended permit icmp 10.26.30.0 255.255.254.0 host 126.96.36.199 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 188.8.131.52
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.
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?
packet-tracer input inside tcp 10.26.30.28 52696 184.108.40.206 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]
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
access-list capture_mpls; 4 elements; name hash: 0x71ebc2b3
access-list capture_mpls line 1 extended permit ip host 220.127.116.11 any4 (hitcnt=0) 0x7d29173c
access-list capture_mpls line 2 extended permit ip any4 host 18.104.22.168 (hitcnt=0) 0x7d764a9a