Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

PBR policy rejected -- normal forwarding

I'm trying to set up the following:

LAN VLANS

|

7204VXR

|

Watchguard

Firewall ------ ISA Proxy Server

| |

|----------------------|

|

Internet

We have 4 VLANS. Two of these need to route traffic to the proxy server. One of these VLANs contains domain devices that I can force to the proxy server with Group Policy.

The other, however, is WiFi traffic that I must route to the proxy server.

I set up policy routing on the 7204VXR, trying various configurations. Essentially it is as follows:

interface FastEthernet0/0.3

encapsulation dot1Q 3

ip address 172.17.10.1 255.255.255.0

ip policy route-map VLAN3

:

access-list 103 permit ip 172.17.0.0 0.0.255.255 any [fragments]

:

route-map VLAN3 permit 10

match ip address 103

set ip [default] next-hop 10.1.1.[5 or 6]

ip route 0.0.0.0 0.0.0.0 10.1.1.2

ip route 10.1.1.4 255.255.255.252 10.1.1.[5 or 6]

I placed brackets around the variations of the configuration that I have tried.

The output of a debug ip policy is always the same result, no matter which configuration is used:

Aug 22 20:44:10: datagramsize=60, IP 1178: s=172.17.10.18 (FastEthernet0/0.3), d=216.239.37.99 (FastEthernet2/0), totlen 40, fragment 0, fo 0, policy rejected -- normal forwarding

Aug 22 20:44:10: datagramsize=60, IP 1179: s=172.17.10.18 (FastEthernet0/0.3), d=216.239.37.99 (FastEthernet2/0), totlen 40, fragment 0, fo 0, policy rejected -- normal forwarding

Is there a way to use policy routing to route the VLAN traffic to the proxy server?

If so, what is the correct configuration?

TIA

Rick

17 REPLIES

Re: PBR policy rejected -- normal forwarding

Is next-hop set in the policy actually reachable (ping?) and replies on ARP requests?

New Member

Re: PBR policy rejected -- normal forwarding

Yes, you can ping both 10.1.1.5 and 10.1.1.6.

10.1.1.5 displays in the ARP table.

I read the document at this link:

http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example09186a00801f3b54.shtml

It talks of 3 situations, particularly the last one where the address can only be reached through the default route. I have tried this, as well as other configurations where I specifically add a static route using 10.1.1.[2, 5, or 6] as the next hop address.

The thing I note, here, is that all the documentation talks of using policy routing when the next hop is another router.

I am wondering if it's even possible to utilize policy routing when the next hop isn't a router? I was assuming that policy routing just matched the criteria in the access-list and forced the traffic to a specific address, regardless of what the device is.

If it can be done, then I'd like to know what the config is supposed to be, as I haven't found one yet that works.

Thanks.

Rick

Re: PBR policy rejected -- normal forwarding

Hi,

Is 10.1.1.4/30 subnet directly connected to this router?

The route statement noted below you have in your config isn't correct. You can't have a route pointing to the next-hop that comes under the same route entry.

'ip route 10.1.1.4 255.255.255.252 10.1.1.[5 or 6]'

Which interface do you route through to get to 10.1.1.4/30 subnet. What's the IP address of that subnet.

Regards,

Sundar

New Member

Re: PBR policy rejected -- normal forwarding

No. The 10.1.1.4/30 subnet is not directly connected to this router.

But according to the documentation, I should still be able to use policy routing in that case. (Case 3 of the article - when the next hop can only be reached through the default route)

I have tried this with/without a static ip route, but all produce the same debug ip policy output of 'policy rejected -- normal forwarding'

Thanks.

Rick

Re: PBR policy rejected -- normal forwarding

Rick,

Got it.

But then in the third case study the default route is pointing to the directly connected next-hop address. Is that your case i.e is 10.1.1.2 directly connected to one of the interfaces of this switch?

Can you add static route for the 10.1.1.4/30 subnet to forward it to the next-hop (router) address, which is directly connected to this switch.

HTH,

Sundar

New Member

Re: PBR policy rejected -- normal forwarding

Sundar,

Yes. 10.1.1.1 is the 7204VXR and 10.1.1.2 is the Watchguard Firewall Trusted Interface.

The Watchguard has 4 optional interfaces, two of which I have used to set up the ISA server with dual NIC cards. 10.1.1.5 is the Watchguard Opitional interface and 10.1.1.6 is the ISA server NIC1.

If I add the 10.1.1.4/30 static route to the router, the output of the debug ip policy is still the same - 'policy rejected -- normal forwarding'

Thanks.

Rick

Re: PBR policy rejected -- normal forwarding

The issue here is that policy routing is of local signifiance. If 10.1.1.6 is not directly attached to your router, but you set it as next-hop. The only thing router can do is merely forward packet to a router on _locally_ attached network. Note that IP packet is not modified by this, therefore when it arrives to that next hop (watchguard in your case) there's no indication that packet should go to 10.1.1.6. Hence watchguard will see packet that has nothing to do with 10.1.1.5 or 10.1.1.6 and process it normal way.

What you're looking for is some sort of transparent proxy. Perhaps WCCP is the right tool for you. Have a look at http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008030c778.html

Cheers

Silver

Re: PBR policy rejected -- normal forwarding

Could you please provide the "sh ip route" & trace route result of 10.1.1.4/5 for reference ?

I believe there is an issue in the routing table. Once we fixed then it should work.

According to the information provided, please try to remove the static route for 10.1.14/30 abd ping to .5 & .6 again. If it works, please try to change the next-hop in route-map to 10.1.1.2, because it is the direct connected IP from 7204 to FW.

Please show us the result. Thx.

Hope this helps.

New Member

Re: PBR policy rejected -- normal forwarding

With configuration having no static ip route and having the set ip default next-hop 10.1.1.5, the results are:

Main-7204VXR#sh ip route 10.1.1.5

% Subnet not in table

Main-7204VXR#sh ip route 10.1.1.6

% Subnet not in table

Main-7204VXR#ping 10.1.1.5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Main-7204VXR#ping 10.1.1.6

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.6, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Main-7204VXR#trace ip 10.1.1.5

Type escape sequence to abort.

Tracing the route to fw1_optional1.scdl.local (10.1.1.5)

1 * * *

2 * *

Main-7204VXR#trace ip 10.1.1.6

Type escape sequence to abort.

Tracing the route to proxytest.scdl.local (10.1.1.6)

1 * * *

2 * *

Main-7204VXR#

With configuration of router including the static ip route of 10.1.1.4 255.255.255.252 10.1.1.2 and changing the route-map command to set ip next-hop 10.1.1.5, the results are:

Main-7204VXR#sh ip route 10.1.1.5

Routing entry for 10.1.1.4/30

Known via "static", distance 1, metric 0

Redistributing via eigrp 100

Advertised by eigrp 100

Routing Descriptor Blocks:

* 10.1.1.2

Route metric is 0, traffic share count is 1

Main-7204VXR#sh ip route 10.1.1.6

Routing entry for 10.1.1.4/30

Known via "static", distance 1, metric 0

Redistributing via eigrp 100

Advertised by eigrp 100

Routing Descriptor Blocks:

* 10.1.1.2

Route metric is 0, traffic share count is 1

Main-7204VXR#ping 10.1.1.5

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Main-7204VXR#ping 10.1.1.6

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.6, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

Main-7204VXR#trace ip 10.1.1.5

Type escape sequence to abort.

Tracing the route to fw1_optional1.scdl.local (10.1.1.5)

1 * * *

2 * * *

3

Main-7204VXR#trace ip 10.1.1.6

Type escape sequence to abort.

Tracing the route to proxytest.scdl.local (10.1.1.6)

1 * * *

2 * * *

3

Main-7204VXR#

Rick

Silver

Re: PBR policy rejected -- normal forwarding

Thx. for the info.

Could you please provide the "sh ip route" which include the subnet of .5 & .6 not the specific subnet. e.g. 10.1.1.0, etc. I could like to know if there is no such static route, how the packet reach .5 & .6 because you can ping it, so it should be reachable.

Moreover, if we find the next-hop for .5 & .6, we can set this next-hop for the PBR next-hop.

Wait for your info.

New Member

Re: PBR policy rejected -- normal forwarding

Jack,

I thought I did.

With both versions of the config, the first two commands issued were sh ip route 10.1.1.5 and sh ip route 10.1.1.6

In the first config, the result was "Subnet no in table" for each.

In the second config, the route information was displayed.

Was there something else you wanted to see?

Rick

Silver

Re: PBR policy rejected -- normal forwarding

Sorry if I not state it clearly.

What I mean is the routing table which inlcude the .5 &.6. The result of first case is the routing table of the specific route and it may not reflect how the packet route to .5 & .6. And the ping result shown the .5 & .6 are reachable. It means there is a route already include the route to route to .5 &.6, or the .5 & .6 is directlt connected at the router. So I wanet to have more info. May be you just type "sh ip route" then remove those sensitive information and paste it. Can you do it ?

New Member

Re: PBR policy rejected -- normal forwarding

Jack,

Here's the pertinent lines from the sh ip route command output:

Main-7204VXR#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

* - candidate default, U - per-user static route, o - ODR

P - periodic downloaded static route

Gateway of last resort is 10.1.1.2 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 16 subnets, 3 masks

C 10.1.1.0/30 is directly connected, FastEthernet2/0

S 10.1.1.4/30 [1/0] via 10.1.1.2

S* 0.0.0.0/0 [1/0] via 10.1.1.2

Main-7204VXR#

One other thing I found was that the trace ip attempts didn't produce output because the firewall didn't allow those UDP packets. I've added rules to the firewall to allow any TCP/UDP packets from the router's 10.1.1.1 address. This did not affect the policy routing, though, as all attempts still show the policy match, but then the rejection message.

Silver

Re: PBR policy rejected -- normal forwarding

Thx. for the info. According to the routing table. The .5 & .6 (i.e. 10.1.1.4/30) is not connected and via 10.1.1.2 as next-hop.

So whenever the traffic require PBR or follow routing table, it will still forward to the 10.1.1.2. So I believe there is no need PBR. For the reason of the failure of PBR, it may be the problem of .5 & .6 not an active next-hop in the routing table.

Please clarify if I misunderstood your case.

Moreover, if you allow trace route to pass through the FW, what is the result when trace yto .5 & .6 ?

New Member

Re: PBR policy rejected -- normal forwarding

Jack,

Traces to the 10.1.1.5 or 6 complete immediately, now, displaying the two hops taken 10.1.1.2 and 10.1.1.5 or 6.

I have been working from the information in this link, particularly Case 3, which seems to indicate that this type of setup should work.

http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example09186a00801f3b54.shtml

I only note that in Cisco's examples, the next hop is another router.

The reason for trying to use PBR is to try to get the packets to the ISA server on the optional port of the firewall, instead of having the firewall forward the packets out the external interface to the Internet. Even though I've tried using various firewall rules based on incoming IP addresses, the firewall doesn't seem to be capable of doing this either.

Thanks.

Rick

Hall of Fame Super Silver

Re: PBR policy rejected -- normal forwarding

Rick

I confess that I find this thread a bit difficult to follow and am not clear what is going on. If I understand the topology correctly there is one link from the router to the firewall over which you will forward this data.

The purpose of Policy Based Routing is to override the normal forwarding decision made in the routing table. But it seems to me that what you are attempting to do in PBR is to forward traffic out the same interface with the same device receiving it hoping that the receiving device will treat it differently. So you are not changing the forwarding logic at all. If I am not understanding something please help me understand it better.

It seems to me that what you really want to do is to change the behavior of the firewall. PBR on the router is not the right tool to do this.

HTH

Rick

Silver

Re: PBR policy rejected -- normal forwarding

Thanks Rick for your explanination. This is what I am going to say.

So the behavior of the FW should be controlled by the firewall and not the router. The .5 & .6 is the port on firewall and not the port on the router. So you have to forward all traffic yo FW (.2) then let the FW to redirect the traffic to .5 or .6

Or if you have another interface at FW which can direct connect to the router, then you can PBR the traffic to this interface then make the FW to forward to the particular hosts. i.e. like to add another FW to the network and connect between the router and the .5 & .6 hosts.

Hope this helps.

2254
Views
0
Helpful
17
Replies