Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Dr_Pepper
New Contributor II

Basic routing issue through IPsec tunnel

My issue is that I can't ping devices connected to the remote gateway. The tunnel is working just fine and I can ping the remote gateway. The remote gateway is a FortiGate 60D on Firmware v5.2.3,build670 (GA).

 

Here's the (simplified) network setup:

 

device1 (192.168.200.11)
|
(remote net 192.168.200.0/24)
|
FG-60D (192.168.200.10 on internal interfaces)
|
(IPsec tunnel)
|
local GW (192.168.180.70)
|
(local net 192.168.180.0/24)

On the FortiGate CLI device1 responds to pinging and also devices on the local net respond. But I can't reach device1 from the local net.

 

I'm suspecting the error might be, that I haven't configured the IP and Remote IP on the VPN interface. They're set to the default value 0.0.0.0. I tried entering the Fortigate's IP 192.168.200.10 and 192.168.180.70 as Remote IP. But because I've configured that IP already for the internal interfaces I get the error "IP address is in same subnet as the others".

 

 

What should I enter as IP and Remote IP on the VPN interface and what's that setting for? I'm afraid to loose access to the remote FG should I make an error, as I currently don't have physical access to the device...

 

Here's the routing table:

FGT60D # get router info routing-table all

S*      0.0.0.0/0 [10/0] via 192.168.200.11, internal
S       192.168.180.0/24 [9/0] is directly connected, VPN-Tunnel
C       192.168.200.0/24 is directly connected, internal

(device1 provides internet access)

 

 

I can post some more information like packet flow debugging if my issue is not connected to the VPN interface IPs.

I think I might just have missed somehting very simple, I'm not very experienced with router setups.. Thanks in advance for any help :)

1 Solution
ede_pfau
SuperUser
SuperUser

hi,

 

you've got a routing issue here.

For proper routing, each device on the network needs to know where to send traffic.

Letz start with device1:

to reach the (non-local, unknown) subnet .180.0/24 it needs to send it's traffic via the default route to the network's router, that is the FG-60D:

0.0.0.0/0 via 192.168.200.10 (= FG-60D internal interface)

 

Next, the FG needs routes:

[ul]
  • to the other local subnet .180.0/24 via the tunnel
  • => 192.168.180.0/24 via "VPN-Tunnel"[/ul]

    It suffices to specify the interface, you don't need to have a valid IP address at the tunnel's end here.

    [ul]
  • to anywhere else outside it's own subnet via the default route:
  • 0.0.0.0/0 via wan1[/ul]

    Here, I'm assuming that the VPN is defined on wan1.

    On leaving the tunnel the packet has reached it's destination.

     

    Now, the return traffic or any original traffic pointed to device1 needs to be routed properly as well:

    [ul]
  • on devices in the .180 subnet, the default route points to the router: 0.0.0.0/0 via 192.168.180.70[/ul]

    On the .180 router:

    [ul]
  • remote subnet is behind the tunnel's end: 192.168.200.0/24 via "VPN-Tunnel", or via 192.168.200.10, depending on the device's capabilities.
  • anything else via default route: 0.0.0.0/0 via wan interface[/ul]

    As I don't know much about that device I cannot give you any specific advice on how to configure it. It has to know that the .200 subnet is behind the tunnel if you specify the .200.10 address in the route.

     

    While you are configuring the routes, allow HTTPS and/or SSH admin access to the wan1 interface on the FG-60D and use this path to configure it. If you're sure the setup is valid and working, remove access again. This way you will not kick yourself out inadvertedly.

     

  • Ede Kernel panic: Aiee, killing interrupt handler!

    View solution in original post

    Ede Kernel panic: Aiee, killing interrupt handler!
    3 REPLIES 3
    ede_pfau
    SuperUser
    SuperUser

    hi,

     

    you've got a routing issue here.

    For proper routing, each device on the network needs to know where to send traffic.

    Letz start with device1:

    to reach the (non-local, unknown) subnet .180.0/24 it needs to send it's traffic via the default route to the network's router, that is the FG-60D:

    0.0.0.0/0 via 192.168.200.10 (= FG-60D internal interface)

     

    Next, the FG needs routes:

    [ul]
  • to the other local subnet .180.0/24 via the tunnel
  • => 192.168.180.0/24 via "VPN-Tunnel"[/ul]

    It suffices to specify the interface, you don't need to have a valid IP address at the tunnel's end here.

    [ul]
  • to anywhere else outside it's own subnet via the default route:
  • 0.0.0.0/0 via wan1[/ul]

    Here, I'm assuming that the VPN is defined on wan1.

    On leaving the tunnel the packet has reached it's destination.

     

    Now, the return traffic or any original traffic pointed to device1 needs to be routed properly as well:

    [ul]
  • on devices in the .180 subnet, the default route points to the router: 0.0.0.0/0 via 192.168.180.70[/ul]

    On the .180 router:

    [ul]
  • remote subnet is behind the tunnel's end: 192.168.200.0/24 via "VPN-Tunnel", or via 192.168.200.10, depending on the device's capabilities.
  • anything else via default route: 0.0.0.0/0 via wan interface[/ul]

    As I don't know much about that device I cannot give you any specific advice on how to configure it. It has to know that the .200 subnet is behind the tunnel if you specify the .200.10 address in the route.

     

    While you are configuring the routes, allow HTTPS and/or SSH admin access to the wan1 interface on the FG-60D and use this path to configure it. If you're sure the setup is valid and working, remove access again. This way you will not kick yourself out inadvertedly.

     

  • Ede Kernel panic: Aiee, killing interrupt handler!
    Ede Kernel panic: Aiee, killing interrupt handler!
    Dr_Pepper
    New Contributor II

    Hello Ede, thanks for your thorough explanations!

     

    I guess my setup for the .200 net is probably a bit odd..

    Device1 is a LTE router that provides internet access. The LTE router is not connected to a wan interface on the FG. It's just located in the .200 net, like the FG.

    The VPN is not defined on a wan interface, it has it's own virtual interface.

     

    So the current routes on the FG should be ok in my opinion. The FG can ping devices in the .180 net just fine.

     

    I can't check the LTE routers configuration currently but I think you're right. The LTE router doesn't have a route to the .180 net and therefore can't respond to my pings from the .180 net.

    During the next days I will have a PC in the .200 net available. When setting the FG as the default gateway the PC should be able to reach the .180 net.

     

    The .180 router belongs to a third party and I can't check it's configuration, but I'm pretty sure it's correctly configured.

     

    Thanks again :)

    ede_pfau

    Makes sense if the FGT is not the default gateway. The pings are not returned because of the missing specific route, and the default route to the internet is followed instead. Into Nirvana.

    Ede Kernel panic: Aiee, killing interrupt handler!
    Ede Kernel panic: Aiee, killing interrupt handler!
    Announcements

    Select Forum Responses to become Knowledge Articles!

    Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

    Labels
    Top Kudoed Authors