Contributor

Question

Policy routing and network loop

Forum|Forum|18 years ago
June 15, 2007
11 replies
7740 views

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

New Member

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

New Member

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.

A

Anonymous_UserAuthor

Contributor

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

A

Anonymous_UserAuthor

Contributor

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

New Member

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.

A

Anonymous_UserAuthor

Contributor

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

New Member

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!

A

Anonymous_UserAuthor

Contributor

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

A

Anonymous_UserAuthor

Contributor

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

New Member

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.

A

Anonymous_UserAuthor

Contributor

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

New Member

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.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded