PBR policy rejected -- normal forwarding

[scdladmin]

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

[ilya.varlashkin]

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

[scdladmin]

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

[sundar.palaniappan]

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

[scdladmin]

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

[sundar.palaniappan]

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

[scdladmin]

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

[ilya.varlashkin]

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

[jackyoung]

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.

[scdladmin]

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

[jackyoung]

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.

[scdladmin]

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

[jackyoung]

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 ?

[scdladmin]

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.

[jackyoung]

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 ?