5.4.4 Policy-based VPN FGT60E

Forum|Forum|9 years ago
February 22, 2017
1 reply
11480 views

Hi,

I want to configure a policy based VPN from a remote site to a central firewall. All traffic from the remote site should be tunnelled, no local internet access. To my knowledge the only reliable way to do this is with policy based VPN, and it worked perfectly in 5.2.

So i've set up the vpn tunnel and created the policy with action: IPSEC and specified the tunnel. local net 10.x.y.0/24, remote net: 0.0.0.0/0 (i want to tunnel all traffic to central site, remember?), but this breaks the fortigate's own initiated traffic, so it can't reach the vpn remote peer because it's trying to reach it over the VPN, which isn't up because it can't reach the peer... catch 22. This did not happen in 5.2.

Config below:

hostname # config vpn ipsec phase1

hostname (phase1) # show config vpn ipsec phase1 edit "vpn-something" set interface "wan1" set keylife 28800 set peertype any set proposal aes128-sha256 aes256-sha256 set remote-gw x.y.z.x set psksecret somepsk next end

hostname # config vpn ipsec phase2

hostname (phase2) # show config vpn ipsec phase2 edit "vpn-something" set phase1name "vpn-something" set proposal aes128-sha1 aes256-sha1 set keepalive enable set keylifeseconds 3600 set src-subnet 10.x.y.0 255.255.255.0 set dst-subnet 0.0.0.0 0.0.0.0 next end

config firewall policy edit 1 set name "vpn all traffic" set srcintf "internal" set dstintf "wan1" set srcaddr "object1" #10.x.y.0/24 set dstaddr "all-nets" #0.0.0.0/0.0.0.0 set action ipsec set schedule "always" set service "ALL" set logtraffic all set inbound enable set outbound enable set vpntunnel "vpn-something" next

I have an identical setup on a 60D on 5.2.something with works perfectly. Anyone else run into this problem? Any fix for it?

//Emil

VPN

Best answer by ede_pfau

Just create a static /32 host route to the remote VPN gateway, pointing to the WAN port. This will allow the local FGT to contact the remote peer at all times, circumventing the default route.

You should see the effect in the Routing monitor.

BTW, I wouldn't touch policy-based VPN anymore - too much going on 'behind the scene' as e.g. routing. Your scenario can easily be fitted with a regular route-based VPN. Makes debugging and scaling easier.

ede_pfauAnswer

SuperUser

Just create a static /32 host route to the remote VPN gateway, pointing to the WAN port. This will allow the local FGT to contact the remote peer at all times, circumventing the default route.

You should see the effect in the Routing monitor.

BTW, I wouldn't touch policy-based VPN anymore - too much going on 'behind the scene' as e.g. routing. Your scenario can easily be fitted with a regular route-based VPN. Makes debugging and scaling easier.

emillandstromAuthor

New Member

Hi!

Thanks for your reply. I thought of the /32-route to the remote peer, in fact that is how i did this in 5.2 before I discovered that it could be done with policy-based VPN (and in 5.2 without the /32-route). That was for me ideal because that solution can cope with the FW getting a new dynamic IP/gateway on its WAN interface without anything breaking.

I suppose i will have to go this route (no pun intended), but the reason I'd rather not use this approach is that the internet connection of the branch office has a dynamic IP, and so in worst case the gateway IP might change, and if that happens i will lose the VPN + all remote access to the FW.

I really wish i could downgrade the 60E to 5.2, but afaik that's not possible.

//Emil

ede_pfau

SuperUser

Again easy to fix. Assign the remote branch WAN ip to a dynamic DNS name, then build a site-2-site VPN from dynamic host to static IP, main mode. I pay dyn.com for DNS hosting my customer's dynamic gateways as they don't do it for free anymore. But Fortinet does, at least in v5.2 and v5.4.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded