IPSEC tunnel up. Can not ping through the tunnel.

[Eric_Robinson]

I have an IPSEC VPN tunnel established between two Fortigate Fortinet 50B' s. Each Fortigate is connected to the internet via WAN1 through a DSL modem. Phase 1 and phase 2 of the IPSEC tunnel are properly set up and the tunnel is shown as up on both units. Fortigate1 has an internal subnet of 192.168.90.0 Fortigate2 has an internal subnet of 192.168.1.0 When using Fortigate1 CLI console to send a ping request to a computer on the subnet of Fortigate2 (execute ping 192.168.1.110) I am getting a timeout. On an identical system with a different subnet the ping works fine. I am wondering if it is possible that the DSL modem attached to Fortigate1 might be causing problems with the communication if the DSL modem has an internal subnet of 192.168.1.0. To me it would seem that the PING is encapsulated in the VPN tunnel and would not be influenced by the DSL modem, but my knowledge of networking is falling short in this area. Thanks...

[Fullmoon]

Q: is this policy based or interface based type of ipsec vpn?

[ede_pfau]

You are right with your assumption that encapsulated internal addresses don' t matter. I suspect the .1.x subnet is used elsewhere on the FGT. You can check this: 1. look at the Routing Monitor (that is the live table of active routes). When the tunnel is down, there should not be any route to .1.x. If the tunnel is up, the FGT will insert a matching route with gateway ' your_tunnel' (whatever you named phase1) 2. ' diag debug flow' will show you where the traffic is going. You will find numerous examples on how to set this command up on the forums (emnoc loves this :) 3. of course, you could get both configs from the working and the current FGT and compare them with a tool to find the difference(s).

[rwpatterson]

ORIGINAL: ede_pfau You are right with your assumption that encapsulated internal addresses don' t matter. I suspect the .1.x subnet is used elsewhere on the FGT. You can check this: 1. look at the Routing Monitor (that is the live table of active routes). When the tunnel is down, there should not be any route to .1.x. If the tunnel is up, the FGT will insert a matching route with gateway ' your_tunnel' (whatever you named phase1) 2. ' diag debug flow' will show you where the traffic is going. You will find numerous examples on how to set this command up on the forums (emnoc loves this :) 3. of course, you could get both configs from the working and the current FGT and compare them with a tool to find the difference(s).

That' s only correct if the DSL modem is in bridge mode, and not doing any routing itself. Checking the WAN1 port of the FGT for it' s IP address should clear things up quickly enough. If both WAN1 and Internal share the 192.168.1.x address space, you have started working towards your solution.