My PBR doesn't appear to be working

[Scott Chauncey]

Hi,

I have a 3945 router with two interfaces connected to my firewall, one to the management interface and another to my dmz.  I'm running eigrp between all my network devices.  The problem I'm running into is when I try to ssh to the management interface of the 3945 the traffice hits the firewall, then goes right to the management interface as it should, but the return traffic is trying to use the dmz interface since that is how the router knows to get back to my computers network.  I created 2 route-maps to try and address this issue.  The first

ip access-l ext 110 permit ip any 192.168.0.0 0.0.0.255

route-map MANAGE_IN permit 10

match ip address 110

set ip next-hop 192.168.30.1

route-map MANAGE_IN permit 20

route-map MANAGE_OUT permit 10

match ip address 110

set ip next-hop 192.168.0.1

route-map MANAGE_OUT permit 20

I've applied the MANAGE_IN route-map to all interfaces that might have inbound traffic destined for the management network and applied the MANAGE_OUT route-map to the management interface.  The MANAGE_IN policy appears to be functioning correctly, the MANAGE_OUT doesn't appear to be functioning correctly.  When I look at traffic from my host going to the management interface I see it still trying to return through the dmz interface.  Can anyone tell me what I'm doing incorrectly?  We've temporarily fixed the issue by nat'ing our management stations into the management network, but I would prefer not to do this if it isnt' neccessary.   Any help would be greatly appreciated.              

[Bilal Nawaz · Accepted solution]

Hi Scott, instead of doing PBR and NAT you could always create a VRF that is only used for management?
This will then totally separate routing instance from your DMZ routing (personally I prefer this option). If you have a VRF you can define a default route back to the firewall which will be a lot better for you. So I can see benefits in this.

Creating a VRF is fairly easy, however I do warn, that when you Apply a VRF to an interface, it removes the IP address on the interface until you re-apply the IP address back.

You could even enable eigrp or any other routing protocol for that matter. It's like a virtual router whereby you assign it interfaces. So the interface belongs to the VRF.
In this case, we would only assign it to the management interface, and would then have the same interface for outbound.

http://www.cisco.com/en/US/products/hw/modules/ps2797/products_tech_note09186a0080b6216e.shtml

http://packetlife.net/blog/2009/apr/30/intro-vrf-lite/

Hope this helps

Sent from Cisco Technical Support iPhone App

[Richard Burts]

I am slightly puzzled about the MANAGE_OUT route map and what you are trying to do with it. It sounds like you are trying to manage the traffic going out of the interface. But PBR uses a route map on the interface for inbound traffic and not for outbound traffic. Is this perhaps the reason why it is not doing what you intended?

HTH

Rick

[Scott Chauncey]

This appears to have fixed some issues and introduced others.  NTP to the management interface is now working, it wasn't before, I can ssh to the management interface without nat'ing, however, when ssh'ing I'm having to use the local account as the router doesn't appear to be attempting to contact my TACACS+ server.  I'm sure this is something else in the config I've probably missed as with pinging, you have to add the vrf "name" tag to the command in order to get it to work.  Do you happen to know what I need to do to get the management interface to use the tacacs server for authentication?  I'll keep digging in the meantime.

[Bilal Nawaz]

Hello Scott

The below is an example of how to get tacacs to use the VRF.
Remember that the VRF needs to know how to get to the tacacs servers too.
You can check the routes in the VRF by doing 'show ip route VRF
In this example, a default route has been configured.

hostname vrfAAA
!
boot−start−marker
boot−end−marker
!
aaa new−model
!
aaa group server tacacs+ management
server−private 192.0.2.4 key cisco
server−private 192.0.2.5 key cisco
ip vrf forwarding blue
ip tacacs source−interface GigabitEthernet0/0
!
aaa authentication login default group management local
aaa authorization exec default group management if−authenticated aaa accounting exec default start−stop group management
!
aaa session−id common
!
ip vrf blue
!
interface GigabitEthernet0/0
ip vrf forwarding blue
ip address 203.0.113.2 255.255.255.0
duplex auto
speed auto
!
ip route vrf blue 0.0.0.0 0.0.0.0 203.0.113.1

Please see TAC document here: http://www.cisco.com/image/gif/paws/113667/ios-vrf-tshoot.pdf

Hope this helps

Sent from Cisco Technical Support iPhone App

[Bilal Nawaz]

We should be able to get to a stage where we can ping the ACS boxes from the vrf.

Ping vrf x.x.x.x

Sent from Cisco Technical Support iPhone App

[Scott Chauncey]

This is what I currently have configured on the router and it still isn't working.  It's a bit different from what you have above. This is that new 15.x series IOS where they are deprecating the tacacs-server commands...

aaa new-model

!

aaa group server tacacs+ ESSC

server name GPESSC

server name PHESSC

ip vrf forwarding MNGMNT

ip tacacs source-interface GigabitEthernet0/2

aaa authentication login CSACS group tacacs+ local

aaa session-id common

!

tacacs server GPESSC

address ipv4 192.168.0.5

key 7 1543252F201E0B2708307176264333

tacacs server PHESSC

address ipv4 192.168.34.58

key 7 00553D25206F2B052F22081A3C5D20

!

ip route vrf MNGMNT 0.0.0.0 0.0.0.0 192.168.0.1

!

interface GigabitEthernet0/2

description Connection to Vlan 998 via via 4506 G6/24

ip vrf forwarding MNGMNT

ip address 192.168.0.11 255.255.255.0

ip access-group MGT_ALLOW in

ip access-group MGT_DENY out

no ip redirects

no ip unreachables

no ip proxy-arp

duplex auto

speed auto

media-type rj45

no mop enabled

end

As you can see my primary tacacs+ server is in the same network that the routers vrf interface is in.  Not real sure why it's trying to use the routers non vrf routing table to route traffic to the tacacs server

[Bilal Nawaz]

Hi Scott, could you kindly provide us with some debugs please?

• debug tacacs
• debug aaa authentication

The VRF is just for routing the packet, in our case it shouldn't even need to. Are your ACL's allowing TACACS+?

I also just noted that the group name is different in your aaa authentication statement.

aaa new-model
!
aaa group server tacacs+ ESSC
server name GPESSC
server name PHESSC
ip vrf forwarding MNGMNT
ip tacacs source-interface GigabitEthernet0/2
aaa authentication login CSACS group tacacs+ local
(Instead of this command, can you please try)
aaa authentication login ESSC group tacacs+ local
!
tacacs server GPESSC
address ipv4 192.168.0.5
key 7 1543252F201E0B2708307176264333
tacacs server PHESSC
address ipv4 192.168.34.58
key 7 00553D25206F2B052F22081A3C5D20
!
interface GigabitEthernet0/2
description Connection to Vlan 998 via via 4506 G6/24
ip vrf forwarding MNGMNT
ip address 192.168.0.11 255.255.255.0
ip access-group MGT_ALLOW in
ip access-group MGT_DENY out

Please rate useful posts and remember to mark any solved questions as answered. Thank you.

[Scott Chauncey]

Once I read through the information on the link you provided I realized I had some more config work to do.  I changed the aaa authentication login statement, removed the tacacs servers from the global config and changed the console and vty ports to login authentication default.  It works like a champ.  Thanks for the heads-up on vrf.

[Parvesh Paliwal]

Can you come up with the topology and the details of the ip addresses: 192.168.0.1 and 192.168.30.1 ?

[Parvesh Paliwal]

your statement :

I've applied the MANAGE_IN route-map to all interfaces that might have  inbound traffic destined for the management network ---- looks fine.

and applied the  MANAGE_OUT route-map to the management interface. --- What I think is ... it is simply redirecting the same data to some other reference point.

[Scott Chauncey]

Also, I guess I should have put in my first post, 192.168.30.0/24 is my vlan 400 net and 192.168.0.0/24 is my vlan 998 (management) net.

Hopefully you can see the drawing and it doesn't confuse matters more than it helps.  The edge router, firewall and satuplink router are all peered on vlan 750 via interfaces on the core switch.  The core switch sends all it's traffic to the firewall via vlan 100.  The core switch is the gateway for all my host nets.  It does not have interfaces on vlans 400 and 750.  The firewall is the gateway for vlans 400 and 998, the edge router is the gateway for vlan 750.  192.168.0..1 is the firewall interface for vlan 998, 192.168.30.1 is the firewall interface for vlan 400.

In answer to Mr, Burts question what I'm trying to do with the MANAGE_OUT route map is force the satuplink router to send the traffic back to the originating interface on the firewall.  What is currently happening is traffic from the host bound for the 998 interface on the satuplink router is going to the router on vlan 998 and trying to return, via the route it has in it's routing table for the host net, on vlan 400, which the firewall denies because it is expecting to see that traffic on it's 998 interface.

Mr. Nawaz, I've never messed around with vrf before but I will definately take a look at the link you provided.  That may be the only way, other than nat'ing, to accomplish what I want to do as it doesn't appear that PBR is a good fit here unless someone see's something I'm doing incorrectly.