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!
Solved! Go to Solution.
I noticed no one else has responded yet. Perhaps check out this guide:
Could you post your PBR config?
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:
ip address ip_net_x netmask_net_x
ip address ip_net_y netmask_net_y
policy-route route-map rm_pbr
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
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.
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
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 ?
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.
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.
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?
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.
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.
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.