Hot!Internal routing problem

Author
pietro.coletta
New Member
  • Total Posts : 3
  • Scores: 0
  • Reward points: 0
  • Joined: 2020/06/18 02:01:57
  • Status: offline
2020/06/18 03:26:49 (permalink)
0

Internal routing problem

Hello to everyone,
I'm managing a Fortigate 500E (firmware v5.4.8,build4108 (GA)).

Port7 has been connected to a switch and "multiplied" using VLANs.
The subinterface "Telecontrollo" is connected to a subnet where is present only a PC reachable via RDP and HTTP.
I created, without any trouble, all the rules necessary for the PC to be reachable from the internet via public IP and VPN.
 

 

The strangest thing is that the policy #135, the simplest of them all, which should permit the traffic from the LAN to the Telecontrollo subnet doesn't work. I debugged the packet's path on the firewall and they are sent to the WAN interface (port2) instead of port7, even though the routing is properly set.


 
Any ideas will be appreciated :-D
 
Bye.
Pietro
#1

8 Replies Related Threads

    ede_pfau
    Expert Member
    • Total Posts : 6340
    • Scores: 533
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    Re: Internal routing problem 2020/06/18 04:15:23 (permalink)
    0
    You don't need any of the 2 constructs, static route and policy routing.
     
    1- if you define a subnet on an interface the FGT automatically creates a route for it, with distance 0 and status "connected". This is so that it overrides any other manually configured route.
    2- you only need policy routing if the path cannot be determined by the destination address. PR allows path selection by source address, source port or destination port. In your case, simply using the (auto-) route will do.
     
    And why forwarding to the WAN port? see "gateway=0.0.0.0"? That network is not local.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #2
    BrUz
    Gold Member
    • Total Posts : 403
    • Scores: 8
    • Reward points: 0
    • Joined: 2011/09/30 01:26:25
    • Location: Norway
    • Status: offline
    Re: Internal routing problem 2020/06/18 04:20:25 (permalink)
    0
    You already have route to 172.16.15 why do you need policy route in addition?
     
    What is the config of your VIPs?

    Fortigate <3
    #3
    pietro.coletta
    New Member
    • Total Posts : 3
    • Scores: 0
    • Reward points: 0
    • Joined: 2020/06/18 02:01:57
    • Status: offline
    Re: Internal routing problem 2020/06/18 07:00:20 (permalink)
    0
    Thank you both for answering.
    To tell the all truth at first I hadn't created the static routes and policy routes, I added them later when things weren't working.
    I deleted them now but things are still not working.
    I did this test to give you some details in the troubleshooting:
    from a PC on the LAN (10.0.0.96) I'm pinging the computer 172.16.15.10, while I'm sniffing the packet on the Fortigate.
    This is what I get:
    id=20085 trace_id=1124 func=print_pkt_detail line=4930 msg="vd-root received a packet(proto=1, 10.0.0.96:1->172.16.15.10:2048) from port3. type=8, code=0, id=1, seq=2604."
    id=20085 trace_id=1124 func=resolve_ip_tuple_fast line=4994 msg="Find an existing session, id-23272381, original direction"
    id=20085 trace_id=1124 func=npu_handle_session44 line=1048 msg="Trying to offloading session from port3 to port2, skb.npu_flag=00000400 ses.state=00012204 ses.npu_state=0x00001008"
    id=20085 trace_id=1124 func=ids_receive line=252 msg="send to ips"
    id=20085 trace_id=1124 func=__ip_session_run_tuple line=2905 msg="SNAT 10.0.0.96->PublicIP_WAN:62464"
     
    Thanks.
    Pietro
    #4
    ede_pfau
    Expert Member
    • Total Posts : 6340
    • Scores: 533
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    Re: Internal routing problem 2020/06/18 08:29:55 (permalink)
    0
    nice that you can record debug flow. Now, the interesting part is missing: how the route is found.
    First, check via Policy Lookup which policy will allow this connection.
    Then, edit the policy in CLI and add the line "set auto-asic dis". This prevents the FGT from offloading to the NP.
    Offloaded traffic cannot be seen in the sniffer or debug flow.
    Then kill all sessions (or just wait for 3 minutes without any traffic), and ping once again, with trace on.

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #5
    pietro.coletta
    New Member
    • Total Posts : 3
    • Scores: 0
    • Reward points: 0
    • Joined: 2020/06/18 02:01:57
    • Status: offline
    Re: Internal routing problem 2020/06/22 14:10:01 (permalink)
    0
    Hi Ede,
    sorry for the delay.
    I tried the Policy lookup with these parameters:
    Source interface: Port 3 (my LAN)
    Protocol: TCP
    Source: 10.0.0.23 (my client on the LAN)
    Destination: 172.16.15.10 (the PC on the VLAN I'm trying to reach)
    Port: 3389
    The Policy that gets chosen is the one that forwards traffic to the internet using the WAN (port 2). That doesn't make any sense, because the routing should push the traffic on the subinterface where the VLAN Telecontrollo is connected!
     
    Thanks.
    Pietro
    #6
    ede_pfau
    Expert Member
    • Total Posts : 6340
    • Scores: 533
    • Reward points: 0
    • Joined: 2004/03/09 01:20:18
    • Location: Heidelberg, Germany
    • Status: offline
    Re: Internal routing problem 2020/06/28 04:50:51 (permalink)
    0
    Have you deleted the static route to 172.16.15.0 yet? There should be no explicit route to this subnet as it is directly connected. If looking up the Routing monitor, you should see the auto-inserted route.
    Then, do a 'diag debug flow' with 'auto-asic-offload' disabled, and post the results.
     

    Ede

    " Kernel panic: Aiee, killing interrupt handler!"
    #7
    Johan Witters
    Bronze Member
    • Total Posts : 45
    • Scores: 0
    • Reward points: 0
    • Joined: 2015/06/03 04:06:12
    • Location: Belgium
    • Status: offline
    Re: Internal routing problem 2020/06/29 03:29:30 (permalink)
    0
    It might be an existing session from when your configuration was not yet complete, as long as this session is active it might not take the new route. Try performing a trace for a different machine, or lookup the session mentioned (id-23272381) and delete it.
     
    Also, do you have any other policy routes defined? The Fortigate automatically adds all "connected" interfaces (physical ports and vlans) to the routing table, but policy routes supersede the routing table.
     
     
    #8
    oscar37
    New Member
    • Total Posts : 9
    • Scores: 0
    • Reward points: 0
    • Joined: 2020/02/12 05:28:35
    • Status: offline
    Re: Internal routing problem 2020/06/29 08:25:20 (permalink)
    0
    Hi,
     
     I see you have a policy for LAN to TELE network but do not see a reverse policy.

    Try adding a policy from TELE network to your LAN and move them  all the way up.
     
     
    Thanks
    #9
    Jump to:
    © 2020 APG vNext Commercial Version 5.5