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 --

[#2]

Hello, Thanks for your suggestions. I have double-checked that NAT is enabled only on my wan1-policies. I' m using policy routing from the tunnel to the DMZ (actually that is policy route 2 above), too. No NAT, and all related firewall policies allow ALL -> ALL. When using IPSec interfaces, I don' t think you can define an explicit gateway(?). You just route into the tunnel, so I don' t know if I can affect things at the other end. Luckily, this is a test environment, so I won' t break too much trying different approaches. :) BR, Kristian

[#3]

Hi, Yes, I' m seeing the same behaviour for all protocols. The accelerator device only affects TCP, though, so this is the desired setup. However, like I stated above, " to demonstrate [the traceroute], the policy routes have been changed to " set protocol 0" " . BR, Kristian

[Fireshield]

Based on the way the Fortigate is designed (it routes, but isn' t a true router), I can understand why you are having issues with this implementation. I' m sure there are easier solutions, but have you considered looking into vdoms to isolate the traffic properly? That would give you the ability to define what to do with internal IPs showing up on DMZ ports - just have them defined on the DMZ in the other vdom.

[#5]

Hi, Thanks again for your suggestions. I went ahead and set up a second vdom with two interfaces. One interface for the accelerator and an inter-vdom routing interface. Plain and simple, and the (original) internal subnet is on the same interface as the accelerator (in this vdom), so there should be no reason to drop packets because of false source addresses. Still, the same problem is there. Any packet gets stuck in a loop between the accelerator and the firewall interface. I' m wondering, if there is something else that is causing the problem? Perhaps the accelerator is so transparent, that the firewall thinks it is getting its own packet back and therefore drops it and re-transmits? I' m just grasping at straws here...any ideas are still welcome. BR, Kristian

[Fireshield]

Try doing a packet sniff: diag sniffer packet any ' host x.x.x.x' 4 where x.x.x.x is the host IP that is sourcing the traffic, and a 4 for verbose level will give you the interface name that is seeing the traffic. This should give you better visibility to where the FGT sees the traffic flowing.

[#7]

Hi, The packet trace shows pretty much what you would expect, that is packets going out and then coming back in on the AccInt -interface, which is the internal interface of the second vdom I set up. The link1 -interface is the inter-vdom routing interface of that vdom. The slightly surprising thing, however, is that you see echo requests going out on the internal interface as well (the first occurence should be displayed in bold), towards the client. --clip FGT-603906536929 (Accelerate) # diagnose sniffer packet any ' icmp and host 10.10.1.1' 4 interfaces=[any] filters=[icmp and host 10.10.1.1] 1.828107 internal in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828107 link1 in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828268 AccInt out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828279 internal out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828404 AccInt in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828430 AccInt out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828438 internal out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828544 AccInt in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828560 AccInt out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828568 internal out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828663 AccInt in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828679 AccInt out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828687 internal out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828783 AccInt in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828798 AccInt out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828806 internal out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828901 AccInt in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828918 AccInt out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.828926 internal out 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.829018 AccInt in 10.9.13.100 -> 10.10.1.1: icmp: echo request 1.829035 AccInt out 10.9.13.100 -> 10.10.1.1: icmp: echo request --clip Regards, Kristian