Skip to main content
A
Anonymous_User
Contributor III
June 15, 2007
Question

Policy routing and network loop

  • June 15, 2007
  • 11 replies
  • 7752 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 --

    11 replies

    Show previous replies
    A
    Anonymous_UserAuthor
    Contributor III
    June 25, 2007
    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
    Terms & ConditionsAccessibility statement