Remote browsing using site-to-site IPsec VPN

[fb1907]

Hello,

i think that This configuration is not working. : http://cookbook.fortinet.com/remote-browsing-using-site-to-site-ipsec-vpn/

Is there anyone try it? Or Is there any suggestion for this config(Remote browsing using site-to-site IPsec VPN) ?

[przemo]

Hello, In the past, I used this recipe on two FGT60D 5.2.5. so I think that it is complete and correct. Perhaps you omitted one step?

[ede_pfau]

You are right, the recipe as given will only work under very special circumstances.

What is missing is the default route (0.0.0.0/0) on the remote FGT pointing to the tunnel interface.

The author describes to set up a static route to the HQ public IP address as a host route (172.20.120.154/32) but makes his first mistake to make the network mask too large (as /24). This will not prevent the tunnel from coming up but will make a lot of hosts on the internet inaccessible. As a host route (/32), this route will enable the remote FGT to reach the HQ FGT to establish the tunnel.

When the tunnel is up, traffic will only traverse the tunnel via the 'HQ private LAN' route to destinations on the HQ private LAN. To reach the internet across the tunnel, you need a default route on the remote FGT pointing to the tunnel interface - and this is missing.

It's distance doesn't really matter actually - if the tunnel is down, the explicit host route suffices to enable contact to the HQ FGT. And once the tunnel is up, a default route with any distance will do.

Frankly, I don't understand that Keith Leroux hasn't edited the recipe - users have pointed out the mistakes months ago. I hope he (or someone from Docs dept.) will read this.

[fb1907]

Thank you very much Ede.

For this link : http://cookbook.fortinet.com/remote-browsing-using-site-to-site-ipsec-vpn/

Firstly, ı will do ipsec vpn sitetosite with using wizard. For remote office,Then, i will correct static route( dst:0.0.0.0/0, device:tunnelinterface) and i will add static route (dst:172.20.120.154/32, bu t i did not understand what the device and gateway is?)

Are there true?

[ede_pfau]

Yes, half of it.

The default route (0.0.0.0/0) only takes a device destination, namely the tunnel interface (= name of phase1).

The host route to the HQ FGT is a public IP address - 172.20.120.154 is just an example. You will know the correct value. The device is 'wan1' or such, the internet-facing interface on the remote FGT. As gateway, put in the static public IP of your ISP. This is displayed in the interface setup of your WAN port.

[NAS]

Hello,two weeks ago i had the same problem after i read the cookbook article and setup my Fortis (FortiOS 5.2.4 / D60 RemoteOffice & D92 HeadOffice). I agree with ede, the default route on remote site Forti in cookbook article is missing (see my comment KSchmidt). For remote browsing i configure two routes on the remote site Forti: Specific Route1. Destination IP: HeadOfficePublicIP/32     Device: WAN1 (is the interface where InternetConnection is configured)    Gateway: ISP’s gateway ip address on RemoteOffice (you can determine/see the address in the Routing Monitor —> default route (0.0.0.0/0) on the remote Forti from ISP) Administrativ distance: 4 comment: Specific route to HeadOfficeForti to hold up the tunnel after vpn connection is alive.  2. Default Route through Tunnel Destination IP: 0.0.0.0/0 Device: Tunnelinterface to HeadOffice Administrativ distance: 4 (better/higherprio as the ISPs default route —> means lower num)Comment: Default Route is active when tunnel is up Thats all. In my special case i had a PPPoE Connection on WAN1 (dynamic IP) at remote site Forti with the effect that the Route 1. has never been active. I had to change a parameter in my route 1. config that it works (with cli): #config router static(static)# edit 3                        -->(depends on your route num)(3)# set dynamic-gateway enable(3)# end….. After this step it works for me. Hope i could help you.

[skrbek]

I know, that this thread is old. But for fortios 5.4.4 this thread has not solution for me.

I troubleshooted this and I figured out:

1) on remote office missing static default route 0.0.0.0/0.0.0.0 to IPSec tunnel to Head Office

2) on remote office to change IPSec Phase 2 selectors to : Local Address 192.168.1.0/24 and Remote Address 0.0.0.0/0.0.0.0

3) on head office to change IPSec Phase 2 selectors to: Local Address 0.0.0.0/0.0.0.0 and Remote Address 192.168.1.0/24

After this repair, works for me.

--

skr.

[ryoga121]

Hi, first of all, sorry for my english.

I made the same as skrbek:

1) on remote office missing static default route 0.0.0.0/0.0.0.0 to IPSec tunnel to Head Office

2) on remote office to change IPSec Phase 2 selectors to : Local Address 192.168.1.0/24 and Remote Address 0.0.0.0/0.0.0.0 

3) on head office to change IPSec Phase 2 selectors to: Local Address 0.0.0.0/0.0.0.0 and Remote Address 192.168.1.0/24

If i made specific route 0.0.0.0/0 with device tunnelIPSEC_to_HeadOffice and has lower distance than the route with destination the IP public of the HeadOffice, the tunnel fall...

Any idea with this?