5.4.4 Policy-based VPN FGT60E

[emillandstrom]

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

[ede_pfau · Accepted solution]

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.

[emillandstrom]

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]

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.

[emillandstrom]

Yep, I'm already using dyndns for the VPN, but that's not the issue. Issue is that if the branch FW gets a new "default gateway" on its WAN1-interface, the old /32 route for the remote VPN peer will no longer work because it's pointing at the wrong next hop IP.

So if the branch FW first gets an ip 20.20.20.20, gateway 20.20.20.1, then I would configure a route for remote vpn peer 30.30.30.30/32 with 20.20.20.1 as nexthop (i'd do this for my remote access IP-ranges as well).

Then the ISP decides to change the ip/gw on the branch office internet connection to 40.40.40.40/40.40.40.1, and all of a sudden the VPN doesn't work, and I can't access the branch FW remotely because the /32-routes i have configured for that are still pointing at 20.20.20.1. Another issue is that this branch FW might get moved to another location/internet connection where the IP/gw will definitely change, and then they have to send me the hardware or I have to drive out there to reconfigure it before it can work at the new location.

I might be nitpicking, the risk of the ISP changing both IP and gw on the internet connection are pretty slim, but in the past I used to work with Firewalls from another vendor where this kind of setup was pretty easy to accomplish.

[ede_pfau]

Now things get mixed up...in your initial post you state that the VPN is between a central site and a remote site. I am assuming that the central site has a fixed public IP address, or a DDNS name. As long as this is the case you can always connect a VPN from remote to central, using a static route. OK, routes to a FQDN are new in v5.4 but maybe you do have a static IP for your central site.

Main point is that the side which changes IP frequently (daily) or with unknown public IP must initiate the VPN, and the other side is the target.

[rwpatterson]

I currently have an IPSec tunnel between two DYNDNS clients and I have never had a noticeable issue. Now these are homes/residential, so the traffic load is pretty low and reliability isn't really measured when the IPs change. That being said, it can be done. For what it is worth, I have never had to manually bring the tunnel up because one of the IP addresses had changed. It's been working without issue for over three years. No ISP leases out that long, especially not FIOS.

I need to add that the IPSec tunnels are in interface mode, not policy mode. Ditch policy mode. You'll only pull out your hair and age faster trying to get that legacy system set up.

[emillandstrom]

Damn I wish we had a virtual whiteboard here so I could explain this properly. :) One more try, from the beginning:

Central site: A-FW

WAN1 static IP: 1.1.1.1

VPN: localnet 0.0.0.0/0, remote net 10.x.y.0/24, peer gw: branch.fortiddns.com

Branch site: B-FW

WAN1 dynamic IP: 3.3.3.3, gateway 3.3.3.1

VPN: localnet 10.x.y.0/24, remote net 0.0.0.0/0, peer gw: 1.1.1.1

If i set this up with interface mode VPN, no traffic will go over the VPN because remote net is 0.0.0.0/0 and the default route received by B-FW on its WAN1 interface will take precedence.

If i set it up with policy mode VPN in FortiOS 5.4.4, B-FW will ignore its default route and try to reach 1.1.1.1 over the VPN instead... Obviously that won't work.

Regardless, the fix is unchecking "receive default route from DHCP" on B-FW WAN1, and add a static route in B-FW to 1.1.1.1/32, nexthop: 3.3.3.1. And this works. No problem.

What happens next:

B-FW gets a new DHCP IP from ISP in a different subnet: 4.4.4.0/24 and the gateway in that subnet is 4.4.4.1. But B-FW doesn't get the new default route because we unchecked that option (above). B-FW still has a route for 1.1.1.1/32, but next hop is 3.3.3.1. This doesn't work because 3.3.3.1 is no longer in the same subnet as B-FW's WAN1 interface.

Now you see the problem? If this happens i have to go onsite and manually reconfigure the route in B-FW to use nexthop 4.4.4.1. Same problem will arise if the branch office is moved to another internet connection with subnet 5.5.5.0/24, B-FW WAN1 will get IP 5.5.5.5, but the configured static route for 1.1.1.1/32 is still trying to use 3.3.3.1 as next hop.