Solved! Go to Solution.
basically:
once you have a vpn tunnel (e.g. IPSEC) set up, the rest is definied by policies and routing.
So if you want user from network A to acces network B throuogh your VPN Tunnel you need:
a route on the FGT which the user in network A uses as default gateway which goes to network B with the Tunnel as interface
a route on the FGT which is the default gateway for network B which goes to network A with the Tunnel as interface.
And then both sides need policies to allow the traffic....
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
hmm
I almost never define any subnet but 0.0.0.0/0.0.0.0 in phase2 selectors.
With that you jsut need routing and policies to reach subnets over the vpn.
And I didn't write anything about default routes. I just wrote that if the corresponding Fortigate on each side of the tunnel then it has to do the routing (and policies) for traffic over the tunnel.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
I'm not sure what you mean by "wan to wan works". But looks like you have a number of subnet behind the device with 192.168.51.2/30 (FGT has .1/30). Unless you put all of those in "pltotr" address group, they won't be able to reach the other side. Currently the phase2 selector has only the /30 in.
@sunny007:
PLEASE do not post a complete config file with tons of sensitive data! If you can, edit your post and delete the attachment. If you need to post config info, post snippets and change all sensitive data like public IPs, passwords etc.
basically:
once you have a vpn tunnel (e.g. IPSEC) set up, the rest is definied by policies and routing.
So if you want user from network A to acces network B throuogh your VPN Tunnel you need:
a route on the FGT which the user in network A uses as default gateway which goes to network B with the Tunnel as interface
a route on the FGT which is the default gateway for network B which goes to network A with the Tunnel as interface.
And then both sides need policies to allow the traffic....
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
@sw2090
Actually, you don't need to point your default route to the tunnel (interface), a simple static route for the remote subnet will suffice. The default route handles the remote FGT's WAN interface as well which is NOT reachable through the tunnel - you need to access it via WAN port.
But I'm sure you meant that.
Besides routing, one needs to
- have all remote subnets in the phase2 quick mode selectors
- have all remote subnets in the address fields of the tunnel-to-LAN/LAN-to-tunnel policies.
hmm
I almost never define any subnet but 0.0.0.0/0.0.0.0 in phase2 selectors.
With that you jsut need routing and policies to reach subnets over the vpn.
And I didn't write anything about default routes. I just wrote that if the corresponding Fortigate on each side of the tunnel then it has to do the routing (and policies) for traffic over the tunnel.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
a route on the FGT which the user in network A uses as default gateway which goes to network B with the Tunnel as interfaceIn my view that is a default route. As long as there are no other, more specific routes, all traffic will follow it down the tunnel. Which is not desireable. If you leave out the "default" then it's just a route, and it'll work as planned.
Anyway, I just want to be precise here as others with less experience may find this post and follow it.
One more note: the '0.0.0.0/0' address in a phase2 quick mode selector is AFAIK a FortiOS speciality, it's a wildcard notation. As long as the other side is a FGT as well, it'll work. But not against a Cisco, Juniper or what else. Not very stringent though, you can't use it e.g. as an address wildcard in a policy.
One more note: the '0.0.0.0/0' address in a phase2 quick mode selector is AFAIK a FortiOS speciality, it's a wildcard notation. As long as the other side is a FGT as well, it'll work. But not against a Cisco, Juniper or what else. Not very stringent though, you can't use it e.g. as an address wildcard i
Correction;
It will work with a cisco , juniper, forcepoint, and a few others ...... In cisco if you do VTI you can use quad 0s, same for route-base in JunOS and Forcepoint based firewalls. Just that I would point that out ;)
Ken
PCNSE
NSE
StrongSwan
Thanks Ken,
for sharing your experience with 3rd party vendors which I lack. I thought this was a big caveat a while ago but if this is indeed working, all the better!
I always appreciate learning from you.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.