Remote browsing using site-to-site IPsec VPN

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

In this recipe, you will configure a site-to-site, also called gateway-to-gateway, IPsec VPN between an office with Internet access restrictions (Remote Office) and an office without these restrictions (Head Office) so that the Remote Office can access the Internet through the Head Office, avoiding the restrictions.

To bypass this restriction, this example shows how create a site-to-site VPN to connect the Remote Office FortiGate unit to the Head Office FortiGate unit, and allow Remote Office staff to transparently browse the Internet to google.com using the Head Office’s Internet connection.

Note that both FortiGates run FortiOS firmware version 5.2.2 and have static IP addresses on Internet-facing interfaces. You will also need to know the Remote Office’s gateway IP address.

1. Configuring IPsec VPN on the Head Office FortiGate

In a real world scenario, a Remote Office’s ISP or something in their local Internet may be blocking access to Google, or any other site for that matter.

On the Head Office FortiGate, go to VPN > IPSec > Wizard.

Name the VPN, select Site to Site – FortiGate, and click Next.

FGTHQVPNWizard1

Set the Remote Gateway to the Remote Office FortiGate IP address

The Wizard should select the correct Outgoing Interface when you click anywhere else in the window. Depending on your configuration, you may have to manually set the outgoing interface.

Select Pre-shared Key for the Authentication Method.

Enter a pre-shared key then click Next.

FGTHQVPNWizard2

Under Policy & Routing, set the Local Interface to the interface connected to the Head Office internal network.

For Local Subnets, enter the subnet range of the Head Office internal network. Depending on your configuration, this may be set automatically by the wizard.

For Remote Subnets, enter the subnet range of the Remote Office internal network then click Create.

FGTHQVPNWizard3

The VPN Wizard informs you that a static route has been created, as well as two two security policies and two address objects, which are added to two address groups (also created).

FGTHQVPNWizard4

Create a security policy to allow the Remote Office to have Internet access. Go to Policy & Objects > Policy > IPv4 and select Create New.

Set Incoming Interface to the VPN interface created by the VPN wizard and set Source Address to the remote office address group created by the VPN wizard.

Set Outgoing Interface to the Internet-facing interface and set Destination Address to all.

Enable NAT and (optionally) enforce any company security profiles.

FGTHQVPNInternetAccessPolicy

 

2. Adding a route on the Remote Office FortiGate

On the Remote Office FortiGate, create a static route that forwards traffic destined for the Head Office FortiGate to the ISP’s Internet gateway.

(In this example, the Head Office FortiGate IP address is 172.20.120.154 so the destination IP/Mask is 172.20.120.154/255.255.255.0 and the ISP’s gateway IP address is 10.10.20.100.)

 FGT-Remote-StaticRoute

3. Configuring IPsec VPN on the Remote Office FortiGate

On the Remote Office FortiGate, go to VPN > IPSec > Wizard.

Name the VPN, select Site to Site – FortiGate, and click Next.

FGTRemoteVPNWizard1

Set the Remote Gateway to the Head Office FortiGate IP address.

The Wizard should select the correct Outgoing Interface.

Select Pre-shared Key for the Authentication Method and enter the same Pre-shared Key as you entered in Step 1.

FGTRemoteVPNWizard2

Under Policy & Routing, set the Local Interface to the interface connected to the Remote Office internal network.

For Local Subnets, enter the subnet range of the Remote Office internal network.

For Remote Subnets, enter the subnet range of the Head Office internal network then click Create.

FGTRemoteVPNWizard3

The VPN Wizard informs you that a static route has been created, as well as two address groups and two security policies.

FGTRemoteVPNWizard4

Allow Internet traffic from the remote office to enter the VPN tunnel.

On the Remote Office FortiGate, go to Policy & Objects > Policy > IPv4.

Edit the outbound security policy created by the VPN Wizard.

Change the Destination Address to all so that the policy accepts Internet traffic.

FGT-Remote-Policy-Edit-All

4. Establishing the tunnel

On either FortiGate, go to VPN > Monitor > IPsec Monitor.

Right-click the newly created tunnel and select Bring Up.

BringTunnelUp
If the tunnel is established, the Status column will read Up on both of the FortiGates. TunnelUp

6. Results

With the tunnel up, you can now visit google.com without being blocked, since the Internet traffic is handled by the Head Office FortiGate and the access restrictions on the remote FortiGate have been bypassed.

WebFilterBypassed

For further reading, check out IPsec VPN in the web-based manager in the FortiOS 5.2 Handbook.

 

Keith Leroux

Keith Leroux

Technical Writer at Fortinet
Keith Leroux is a writer on the FortiOS 'techdocs' team in Ottawa, Ontario. He obtained a Bachelor's degree from Queen's University in English Language and Literature, and a graduate certificate in Technical Writing from Algonquin College. He spent a year teaching ESL in South Korea. Annyeong!
Keith Leroux
  • Was this helpful?
  • Yes   No
The pre-shared key is a credential for the VPN and should differ from the user’s password. Both FortiGate’s must have the same pre-shared key.
  • KSchmidt

    Iam really desperated because i need a solution for this scenarion. I have set up a route based ipsec site2site connection with no problem. I don’t get it to run when i extend the connection for remote browsing over the tunnel to HeadOffice. On my RemoteOffice site i have a PPPoE connection on WAN1 with static ip, Default route is auto set by PPPoE Interface with adm distance 5.

    On my RemoteOffice i set up two routes:

    1. Destination IP: HeadOfficeStaticPublicIP/32
    Device: WAN1 (is the interface where PPPoE connection is confígured)
    Gateway: ISP’s gateway ip address on RemoteOffice
    Administrativ distance: 4

    2. Destination IP: 0.0.0.0/0
    Device: Tunnelinterface to HeadOffice
    Administrativ distance: 4
    After that, i cant bring up the PPPoE Interface, it always fails. I Need help, some ideas?
    Thanks in advance!

    • Włodek W.

      First set priority of your default route greater than 0 ex. 2. For PPPoE this can be done only from CLI.
      config system interface
      edit wan1
      set priority 2
      end
      Then set your static route 0.0.0.0/0 to Head Office tunnel with distance equal to your PPPoE default route i.e 5 and priority 0.
      That’s all. It works. But… from now on u cannot connect to your Remote FG from HeadOffice using its public WAN1 address. It does not work. You must connect to it using your VPN tunnel and IP address of internal interface. When VPN tunnel is down you use WAN1 IP address for remote management.

      The reason is static route are inactive for PPPoE connection when default gateway is in other subnet then Wan interface. Go to CLI and run command: get router info routing-table database.
      It means you do not even have to add static route to ur HeadOffice – it will not work for PPPoE.

      See http://kb.fortinet.com/kb/documentLink.do?externalID=FD36417
      The following routes will appear as inactive:
      • • Static routes on an interface with a static IP address where the static IP address is in a different subnet than the default gateway

  • Włodek W.

    This guide does not work. There is one important step missing: at the Remote Office Fortigate add default route 0.0.0.0 0.0.0.0 going to Head Office tunel (named here Remote Office for making all the matter misunderstood??) with administrative distance less than 10 ex. 9. That’s why, next u need “STEP 2- Adding a route on the Remote Office FortiGate” – but with administrative distance also 9 – if the default route (all internet traffic) is redirected to tunel to HeadOffice, Remote Office Fortigate must know route to Head Office Fortigate 172.20.120.154 being VPN tunel remote gateway.

    • Włodek W.

      It depends also if you use Route-based VPN or Policy-based VPN. Keith’s guide could work in Policy-based VPN not Routed-base.

  • Tom

    Just an FYI that this guide does not work. There are some important missing steps, particularly having to do with the routing on the remote site side.

    • Tom

      specifically its the part where you mention to enter 172.20.120.154/255.255.255.0 for the destination IP in the route on the remote site. The Fortinet will not allow you to enter 172.20.120.154/255.255.255.0 and will instead change it to 172.20.120.0/255.255.255.0.

      Can you please clarify better how the remote site route should be set?

  • BM

    Hi Keith,

    I’m using Fortigate v5.4 in test environment where both of the FG devices have the same gateway. Can cause a problem the same gateway of the devices, because this doesn’t work for me?

    • Keith Leroux

      Hi BM,

      Since this is a test environment, can you be more specific about the network topology in your scenario? What are the interface and gateway IPs, etc? If you mean that both FortiGates have the same WAN IP, that would be a problem..

      • BM

        Head office WAN IP: 192.168.1.100, LAN: 192.168.50.0/24
        Remote office IP: 192.168.1.101, LAN: 192.168.30.0/24
        Gateway: 192.168.1.1

        Site to site VPN is established and ping between LANs works.

        Rule on Head office FG for connection from VPN to internet must be ok, because I made the same for the Forticlient and it’s working.
        I think that there is problem with static route. If you just check: your mask that you typed in tutorial can’t be /24 (172.20.120.154/255.255.255.0).

  • Keith Leroux

    Hi Nathan, thank you for your feedback! It is my understanding that the static routes created by the VPN wizard resolve the issue. Google is blocked on the remote gateway, and when the remote user connects to the head office VPN, they are no longer blocked access to Google, so the bypass appears to be working as intended.

  • Nathan

    I’m sorry to say that these steps alone will not produce the results you’re describing. There’s no reason for traffic going to google to magically know to traverse the VPN tunnel and come back. Please revise this post with all the information.

    • Keith Leroux

      Hi Nathan, thank you for your feedback! It’s my understanding that the static routes created by the VPN wizard resolve the issue. Google is blocked on the remote gateway, and when the remote user connects to the head office VPN, they are no longer blocked access to Google, so the bypass appears to be working as intended.

      • Nathan

        Static routes would only work if you set static routes for everything. We tried your guide with a few setups:
        FGT200D AWS VPN didn’t work for us
        FGT200D AWS FGT VM didn’t work for us

        We would consider a consulting fee for getting this working as it would be a big win for us. As far as I can tell this can’t be done with IPSec or there is something missing from this guide.

  • Alex Bezlepkin

    Hi Keith

    my name is Alexander
    I’m trying to do the same steps as you, but I can’t get result

    can you make a video how to do it?

  • Keith Leroux

    Hello Phua,

    10.10.20.100 represents the ISP’s gateway IP address.

  • Phua

    Remote Office WAN IP Address is 10.10.20.1?
    Head Office WAN IP Address is 172.20.120.154?
    Then IP Address 10.10.20.100 is???

    • Keith Leroux

      Hello Phua,

      10.10.20.100 represents the ISP gateway IP address.

      • Casey

        How can 10.10.20.100 represent the ISP gateway IP@? It’s a private IP@.

        • Keith Leroux

          Hi Casey,

          In this case, it was a lab environment where I simulated an ISP, and so I chose the 10.10.20.100 IP address.

          • Casey

            Hi Keith,
            I appreciate your reply. Now it makes sense.
            For Step 2, you created that static route to enable the remote FGT to reach the HQ FGT in order to establish the tunnel. Correct me if I’m wrong.
            Another question regardless the defautl route of the remote FGT, I imagine that it points to the ISP Gateway and not the HQ FGT, isn’t it?

      • Casey

        I didn’t get Step 2. You created a static route that forwards traffic destined to the Head Office FortiGate to the ISP’s Internet gateway, I’m really confused! I mean, the only way for the Remote Office FortiGate to reach the iternet including” the Head Office FortiGate” is to send the traffic to the ISP Gateway.