Route/grant access from a Site to Site VPN to another Site to Site VPN

[johntampac]

Hello All,

This is my first time to be here hope that I could also contribute something in this forum. Right now I will need your help.

My scenario is this:

Our company have 2 offices  Main and a Remote Branch. Both are geographically far from each other. Both sites are currently connected with an IPsec Site to Site VPN, both sites are using FortiGate firewalls. Because of this, the remote branch can access services/servers in the Main branch. Recently we acquire Azure services, we placed some of our servers in Azure. The main branch have a Route based VPN Tunnel to Azure, so the main branch can access the servers in Azure. My problem is with the remote branch it cannot access the azure servers. Although this problem can be solved by creating a VPN tunnel between Azure and the remote branch, the management is reluctant to do this because of the addition cost. Because of this, I need the remote branch to access Azure via Main branch existing VPN tunnel to Azure. I have tried but I failed, I was not even sure if i was a doing it in a correct direction. I've been struggling with this for a while now, that is why I'm here seeking for your help on how  this can be don in FortiGate.

Additional Info:

Main Branch is using: FortiGate 200E

Remote Branch is using: FortiGate 50E

Hope you can help me. Please also see attached image for the diagram

Regards

John

[Toshi_Esumi]

I don't know about Azure side but assume it's just adding another or more subnets to the tunnel with the Main to pass the traffic for the remote branch. As you can find many discussions in this forum similar to your case, hub-and-spoke, you just need to take care of three things over the existing tunnel between main and remote.

[ul]

IPSec traffic(network) selectors for additional Azure subnets (unless you use 0/0<->0/0 )

routing for Azure subnets

policies to accommodate Azure subnets (if not all<->all)[/ul]

Then the rest would be some sniffing (diag debug sniffer packet), which you can find everywhere online.

[rwpatterson]

Welcome to the forums.

In the main office, how is the tunnel configured (to Azure)? If it is interface based (policy action is ALLOW), then you simply need to allow the IP address subnet for the remote site through. If it is policy based (policy action is IPSec), then there is no way to do it if the subnet is not directly connected to the main FGT. I would recommend you change it (not very hard, but down time is required) to Interface based. It will save you headaches in the future. The policy based (IPSec) style is older and far less robust.

[johntampac]

Hello rwpatterson,

The vpn to azure is using route based vpn this is probably what you meant by interface based vpn. I'm using this KB (link here)  to configure azure vpn. You can confirm if my route based vpn is what you meant. And yes, this setup cannot be implemented in Policy based VPN. Just a question though, I'm using fortigate built-in vpn template in configuring vpn tunnel between Main office and remote branch. Does this template use a policy based VPN?

Regards

John

[rwpatterson]

It depends on the code version you are running. I'm not sure when the default switched but I believe it was well before the E series were released. That being said, I believe you should be. Look at the policy between the sites. If the action is 'ACCEPT' then you are good.

Basically on the main FGT you have to:

* Add a static route to the remote subnet with a lower distance than the default back to the remote site(s)

  (This should have already been done since you are communicating with it already)

* Create an IP pool with a single unused IP address that would be allowed over the Azure VPN

* Create a policy from the remote site (subnet) to Azure and add the IP pool to the policy

On the remote FGT you have to:

* Create a policy to Azure pointing down the VPN

* Create a static route to the Azure subnet with a lower distance than the default pointing down the VPN

All from the top of my head, I believe that should do it. The reason for the IP pool is that the remote subnet may not be allowed over the tunnel, so you are simply masquerading it as an allowed IP address. If the remote subnet is allowed, the IP pool steps may be left out.

Hope that helps

[johntampac]

Hello rwpatterson,

I actually resolved the issue, I simulated this with another location (not Azure) and it was working perfect. I recreated the VPN tunnel. I did not use the Site to Site VPN template for FortiGate devices, I used custom instead and configure a route based vpn from Remote branch to Main. From the Main office to the other location I have to enable natting in the policy (to mask the original IP) and it went fine. The culprit was the Site to Site VPN template for Fortigate devices, I'm convinced that his template was using policy based vpn which does not allow this kind of setup.

Regards

John