What Fortinet needs to do is implement route based VPNs and give us a choice instead of only extremely limited policy based VPNs.
Wow, I just noticed my time is correct if I set my time zone to Baghdad, Iraq. I live in the Eastern Standard time zone, but that' s only 8 hours off, not too bad.
Wow, I just noticed my time is correct if I set my time zone to Baghdad, Iraq. I live in the Eastern Standard time zone, but that' s only 8 hours off, not too bad.
I have seen tunnel mode VPNs mentioned in documentation, but have not seen any configuration in the Fortigate that refers to this type of VPN.
What is Fortinet' s idea of a tunnel mode VPN?
--> When I say a route based VPN, I mean a virtual interface, or interfaces that have a VPN or VPNs attached to it/them. The VPN tunnel would be established outside of the policies configured. Traffic would flow over the VPNs according to the policies configured on the firewall. There would no longer be a need to create a VPN policy. You could also configure routing protocols on a VPN " tunnel" interface. You could configure one policy to accomidate traffic for many VPNs, or many policies could be used to controll traffic over a single VPN.
I have not seen anything in the Fortigate that would even come close to this kind of configuration. I have put in a feature request over 18 months ago, but who knows what they' re going to put out in the next major release of code.
Tunnel mode i was referring too is when you create a vpn, then use routing to state whether to use a particular VPN. (like netscreen can do)
i remember it being mentioned in the 2.5 docs, it says. If you select " use wildcard selectors" in the Phase 2, heres the online manual extract;
Select this option for routing-based VPNs. A routing-based VPN uses routing information to select which VPN tunnel to use for the connection. In this configuration, the tunnel is referenced indirectly by a route that points to a tunnel interface.
You must select this option if the remote VPN peer is a non-FortiGate unit that has been configured to operate in tunnel interface mode.
Never seen a document that gives any more info though, in netscreen it creates a virtual interface for the vpn and you just route to it (if i remember correctly).
What would be a great feature, would be , as you say, when you create a VPN, it appears as a seperate policy (for example, instead of int -> ext, something like int -> myvpn) whereby you can then put the usual list of rules within it.
That would be cool. 
Here is the problem ...
we have too FG and i need to use the VPN to route into a 172.x.x.x (DMZ)net
and the 192.168.3.x (Int) net
i have try to open a second tunnel but the FG always give me PARSE ERROR on the log.
any idea ?
I have the smiliar situation in my office, I would recommend the following setting for your test:
1/ First, build up a normal VPN ipsec tunnel between the pair of FG100 (A & B)
2/ Define the addresses for subnet 172.x.x.x, 192.168.200.x and 192.168.3.x
3/ Group the 3 subnet addresses into a single Group, eg. " Local Office"
4/ Set a fw policy from port1 (int) to port2 (ext), Source: " Local Office" , Dest: Remote Office (10.0.x.x), Direction: inbound and outbound
5/ On FG100B, the prevous vpn policy should be already set to allow traffic from 100A to access DMZ (" Local Office" ), you may need to set another policy for accessing to Internal subnet.
6/ On " Other GW" , set an ACL to allow subnet of 10.0.x.x to access Destination Network.
7/ It' s assume that the External ALL is pointing to FG100A at Source Network side.
Remark: Please remember select " Use wildcard selectors" in the Quick Mode Identities section at Phase 2, Advanced option.
I am not sure whether it works on your side, but you can try.
Please correct me if I am wrong~ 
