Policy routing and network loop

[#1]

Hello, I' m trying to set up policy routing to make traffic from and to the internal network pass via a network accelerator device, connected to the DMZ interface of my FG-60. I have policy routes set up for both the internal and tunnel interfaces, as well as for packets coming from the accelerator device into the firewall. Please find a simple visualization of the setup below. Unfortunately, the packets seem to be resent (maybe according to policy id 1) to the accelerator device and never match policy id 3, which would send the packets out the VPN tunnel after having been handled by the accelerator. Note that source and destination addresses do not change, since the accelerator device handles them transparently. Is this a bug or does the Fortigate policy router simply not handle IP packets with a source address from another connected subnet? Thanks for any ideas or pointers! BR, Kristian -- 10.9.13.0/24 internal | |---------dmz (transparent device -172.21.13.10) | wan1 (TunnelVPN -10.10.0.0/16) -- config router policy edit 1 set dst 10.10.0.0 255.255.0.0 set gateway 172.21.13.10 set input-device " internal" set output-device " dmz" set protocol 6 set src 10.9.13.0 255.255.255.0 next edit 2 set dst 10.9.13.0 255.255.255.0 set gateway 172.21.13.10 set input-device " TunnelVPN" set output-device " dmz" set protocol 6 set src 10.42.0.0 255.255.0.0 next edit 3 set dst 10.10.0.0 255.255.0.0 set input-device " dmz" set output-device " TunnelVPN" set protocol 6 set src 10.9.13.0 255.255.255.0 next end --

[Fireshield]

Have you had this working with a different device? There are many problems I can see with this configuration, i.e.: - TCP is connection oriented. Who do you send the ACK to if the IP is on the wrong interface? - We can' t have the same IP address on 2 different MAC addresses, which is bound to happen if there are different devices representing themselves as the same IP address. Placement of this device should probably be just inside the internal port, not on the DMZ operating transparently. Of course I could be off there too since the only understanding I have of the end goal is a few quick sentences.

[rwpatterson]

I agree. The device should be placed inline somewhere in a non-routing mode (transparently) or inline as another hop. The only other option (I think) would be to use it as a proxy type device, which should still be on the same network.

[#4]

Hi, Thanks for your input. I' m sorry if my initial post left out too many details. First of all, all actual communicating parties are on the internal LAN and the other end of the VPN tunnel. The accelerator device (a Riverbed Steelhead) supports a _virtual_ in-path mode (which is currently enabled). This mode allows it to operate as in-path in environments where it is not possible to physically connect it inline (for example in redundant, multi-path LANs). When in virtual in-path mode, policy routing is used to direct packets to the device (172.21.13.10), which then, after processing, forwards them to a next hop, in this case the Fortigate DMZ-interface IP, 172.21.13.1. It is then up to the firewall' s policy routes to direct the packets to the actual endpoints. The problem, however, seems to be that the firewall keeps redirecting the incoming packets to the accelerator device. I base this conclusion on the fact that I see a flood of pings on the DMZ interface, after sending one single packet from internal to the other side of the VPN tunnel. Also, a traceroute from internal to remote subnet looks like this (to demonstrate, the policy routes have been changed to " set protocol 0" ): C:\Documents and Settings\XXX>tracert -d 10.10.1.1 Tracing route to 10.10.1.1 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 10.9.13.254 2 1 ms <1 ms <1 ms 172.21.13.10 3 <1 ms <1 ms <1 ms 10.9.13.254 4 1 ms <1 ms <1 ms 172.21.13.10 5 <1 ms <1 ms <1 ms 10.9.13.254 6 1 ms <1 ms <1 ms 172.21.13.10 7 <1 ms <1 ms <1 ms 10.9.13.254 8 <1 ms <1 ms ^C Regards, Kristian

[#5]

Hi again, Just to avoid any misunderstandings, the source address of policy route 2 should be 10.10.0.0/16. This, however, is not the actual problem. Regards, Kristian

[Fireshield]

I still don' t think you' re seeing the issue here. The same IP address cannot be seen on multiple interfaces, as there will be a whole host of problems due to the issues I outlined earlier. It' s just not clean networking and I' d be very surprised if this is the designed placement of the device.

[#7]

Hi, I hope I do see the issue. :) Actually, the design I have outlined above is exactly the one described in the Steelhead deployment manual, although the example is using Cisco routers. Please note that the same IP address is not seen on multiple interfaces, the packets are just routed via the appliance in the DMZ interface. There is still only one MAC/IP binding, and that binding is for the internal subnet. I know that many egress filters drop packets with " false" source addresses, but strictly speaking IP routing is based on destination addresses only. BR, Kristian

[rwpatterson]

Make sure NAT is turned off on the policy that the accelerator is using. NAT should only be used on interfaces facing the Internet. Also since you' re changing the natural routing order, the remote gateway needs to know that to return traffic to this network, the DMZ port will take the traffic, not the ' normal' port which actuall has the network on it. The DMZ (172.21.13.0/24) will be accepting all the traffic destined for 10.9.13.0/24 through the accelerator even though 10.9.13.0/24 is on the Fortinet. Give this static route a lower distance on the remote end and see what happens. Make sure you have another way in if it hangs. I don' t want you to have to hop a plane to fix it!

[rwpatterson]

By the way, how are you presenting that DMZ device to the tunnel? Are you using a VIP? If you are, then you will need to create a NAT pool for that policy with that same IP address in it, so that the packets leaving the Fortigate have the same IP address as the ones returning. Just another thought.

[Fireshield]

Let' s leave this at pure routing for a moment and ignore the other limitations of the Fortigate. You show a copy of a trace test, but the policy routes above are all listed as protocol 6 (TCP). Pings and traces are ICMP, not TCP, and should not be included in any policy route for protocol 6. Have you tried using protocol 0 (any) on all your policy routes? Are you seeing the same issues with other protocols, or are you only using ICMP for the moment?