PC --> access switch --> core switch --> isa server --> ASA firewall --> Internet
(isa server is a windows firewall). My core switch has a default gateway pointing to the isa server and not the ASA firewall, this is pretty much the standard in the company. However there are specific devices that need to bypass the ISA and go to the Internet via the ASA alone (no ISA in the routing path). I therefore wish to implement a PBR on the core where traffic from a specific PC would go as follows:
PC --> access sw --> core --> ASA fw
bypassing the ISA server.
I did the following:
!pc is 18.104.22.168
access-list 1 permit 22.214.171.124 0.0.0.0
!pc vlan interface
interface vlan 20
ip add 126.96.36.199 255.255.255.0
ip policy route-map test
route-map test permit 1
match ip address 1
set ip next-hop <fw ip address)
This configuration did not work in lab environment.
Note that that the firewall IP address is on a different vlan than the pc but is routing within the core switch.
You plan should work in general but it is hard to say from what you have posted. If this is on the core switch and the core switch can in effect see both firewalls you can bypass with the policy route as you describe.
The issue you are going to have is the return traffic. How does the outside firewall know to send the return traffic back to the switch rather than send it via the PC firewall. Although in theory the traffic could pass the PC firewall on the way back most firewalls will drop this traffic.
I am not concerned about the route back as the firewall has a route back to the vlan hsrp address defined on the core and not the ISA server (windows firewall). I fear that my ACL will not allow the rest of the devices on that vlan to communicate out. Should I use extended ACL's and specify the dst ip address as well?
The traffic that I would like to bypass the ISA should be a "permit" or "deny" on the ACL? And should there be an explicit deny\permit?
I was looking for a simple example online but could not find one.
On policy routing anything that is deny just is not policy routed. The deny traffic will route as normal.
Your acl is fine if all you care about in the source address. If you show the access list, the counters increase as traffic matches it and is policy routed.
You need to make sure your firewall is receiving this packet from the correct interface. If your logs are detailed enough it shuold show that the packet came from the core swith mac address. If you can't tell you could add a SET DSCP option to your policy route to also mark the packets you policy route. You could then put a speical rule in your firewall looking for packet marking just so you get a log entry to verify it is correct
Based on the little bit of detail that you have given us the configuration of Policy Based Routing looks ok. Can you be any more specific about your testing in the lab. What was the topology in the lab? What was the result? You say that PBR did not work in the lab, so can you be a bit more specific about what did not work? Was the counter on the access list permit statement incrementing? Did you run debug for PBR and if so what kind of output did you get? Are you sure that in the lab the address that you gave as the next hop was really reachable from your test switch?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...