ASA 5512 9.4(2)3 Policy Based Routing (PBR) Stateful

[bobbobbessen]

Hi,

in our infrastructure we have an ASA 5512 version 9.4(2)3 deployed. In our network environment we need to apply Policy Based Routing (PBR) to circumvent the default gateway for particular networks, e.g. lets say a DMZ.

For new initiated outbound connections this is working as expected. For inbound connections to our “DMZ” all packets are reaching the provided service, but no connection can be established because the packets which have to be sent back to the requesting host are not routed correctly through the ASA. With debugging options for PBR enabled we recognized that PBR in this case is not applied. Furthermore, the packets are neither dropped by ACLs nor forwarded via the default gateway or other interfaces. Moreover, we are not able to see any hints in the logfiles indicating any issues.

So fare we tried the option "TCP state bypass" but this seems to have no impact. Since this is a kind of test environment there is not much load or traffic on the device, which may cause performance issues.

Is it not possible to use PBR for e.g. stateful connections? Or is there any option which has to be applied?

Thanks in advance!

[Philip D'Ath]

I noticed no one else has responded yet.  Perhaps check out this guide:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa94/configuration/general/asa-general-cli/route-policy-based.html

Could you post your PBR config?

[bobbobbessen]

To illustrate the basic network infrastructure (each net has its own interface):

- net_x  ... ISP A (default gateway )

- net_y ... dmz

- net_z ...ISP B, where all traffic from the dmz should be routed via PBR

Traffic to dmz originates only from ISP B.

As already mentioned all outbound connections from net_y to net_z are working, when they are initiated from net_y.

The relevant config parts are:

interface GigabitEthernet0/0
 nameif net_x
 security-level 60
 ip address ip_net_x netmask_net_x 
!
interface GigabitEthernet0/1
 nameif net_y
 security-level 15
 ip address ip_net_y netmask_net_y 
 policy-route route-map rm_pbr
!
 interface GigabitEthernet0/2
 nameif net_z
 security-level 10
 ip address ip_net_z netmask_net_z 
!
access-list acl_pbr standard deny net_y netmask_net_y 
access-list acl_pbr standard permit any4 
!
route-map rm_pbr permit 10
 match ip address acl_pbr
 set ip next-hop gw_net_z
 set default interface Null0
!
route net_x 0.0.0.0 0.0.0.0 gw_net_x 1

[Jon Marshall]

If ISP A is the default gateway why is your default route pointing to ISP B ?

That aside I suspect as you say the issue is that there is an entry in the state table so the ASA will use that for return traffic but (apart from the default route question above) it's not clear why the ASA then drops the traffic rather than just forward it to ISP A.

Jon

[bobbobbessen]

You're right. That was a typo, when editing the config for the discussion. The correct default gw is:

route net_x 0.0.0.0 0.0.0.0 gw_net_x 1

[Jon Marshall]

Can you just clarify something.

For the DMZ devices are you using static NATs ?

If so I would have thought they would only be configured from the DMZ to the ISP B interface so how is traffic for those DMZ hosts coming in via the ISP A interface ?

Is it because the IP address space is owned by ISP A or am I not understanding the actual problem ?

Jon

[bobbobbessen]

There is not NAT at all. It's all done within public IP address spaces.

There is no traffic from ISP A to the DMZ. All traffic to the DMZ comes from ISP B.

The 'rest' of the traffic, not related to the DMZ, should flow via default gw to ISP B.

[Jon Marshall]

Presumably that last line should be the rest of the traffic flows via ISP A ?

That aside if traffic is coming in via ISP B to the DMZ then I can't understand why the return traffic is being dropped.

Certainly TCP state bypass won't work here because the traffic is using the correct interface and only the one interface.

Jon

[bobbobbessen]

Again, you're right. The rest of the traffic should flow via ISP A.

Right. We do not understand why the packets, which are allowed when coming via ISP B and reach the service are blocked by the ASA on their way back.

It seems that the ASA can not match the SYN-ACK message to the corresponding SYN message, which was allowed when reaching the ASA via ISP B. Maybe SYN-ACK messages, which can not matched by the ASA to existing connections are dropped by the ASA without notice in the logs?

[Jon Marshall]

It may be that PBR behaves slightly differently on the ASA because of it being stateful.

What you may want to do is either move this thread to Firewalling or start a new thread there because there are Cisco TAC guys who participate in that forum and they may know what is happening.

Jon

[bobbobbessen · Accepted solution]

Our issue seems to be related to the following bug:

https://quickview.cloudapps.cisco.com/quickview/bug/CSCuv00272

which is not yet fixed.

[Jon Marshall]

Thanks for getting back on this.

It does indeed look like the problem although interestingly the bug makes no mention of the packet being dropped, just that PBR doesn't select the right interface.

I assume it gets passed to PBR then because it cannot select the interface it does not fall back to any other method of forwarding.

Surprised we haven't seen this on the forums before.

Jon

[dbogdan]

It seems I'm in the same situation. I know this thread is ancient, but I have a use for PBR on our ASA. It sends out the correct interface, but does not allow return traffic. If I add a route for the interface (with the IP's in the route map) it then work. That defeats the purpose of using PBR though. I'm going to post this on the firewall forum.

[Peter Koltl]

I am not sure how a standard ACL is evaluated in a route-map. Are you positive that acl_pbr does what you intend to? It has a deny line for net_y then permit everything else and you expect to set next-hop for all the packets coming from net_y... I would create a different extended ACL.