loopback: VPN services presented by the FortiGate

[Richard_Bartlett]

In complex WAN solutions, where you have a single chassis performing perimeter security and VPN concentration; it is painful not to be able to target VPNs onto the FG using a logical internal address. Using a DrayTek 2x00 as an initiating end-point relies on manual intervention or automation on it or the DNS that resolves the FortiGate address. I' m sure many other end-points, including FortiGate would benefit in having a loopback address to reach on the landing end-point that could evade dual WAN line failings (as the broken WAN link would lose the knowledge of the path to the loopback, whilst remain viable via the alternative path - plus load balancing when both are available) I' d like to see a loopback address that has membership to one or more physical interfaces (that works like a secondary IP - that would be very different in nature as would a secondary IP is restricted to a single interface). Such a loopback definition therefore inherits the rules/policies/route-maps of the interfaces it is a member of OR has its own policies in the context of the flows that come its way. However, unlike a regular interface network IP, and unlike say a cisco IOS platform, the loopback would not be a router interface that performed gateway services. This is rather in appropriate when such an interface would not have a layer-2 representation in the non-transparent mode etc. Perhaps this is already in 3.0

[#2]

Are you talking about having a VPN terminate on a " virtual" interface that relies on end to end connectivity rather than connectivity on an individual interface? There are ways to do this, but the solutions that I imagine of have nothing to do with a loopback address. In the context of security, zones are probably more appropriate. If you have two interfaces that have separate internet/WAN connections, they would belong to the same zone. Policies are applied at the zone level, not the interface level. In this case, the VPN connection would be created in that zone using whatever means necessary to make the connection, either or both interfaces. In this case, I guess you could use a loopback address, though for the purpose of identification, rather than an actual functioning IP address. This is a very simple explanation and leaves a lot of routing out, but that' s somewhat what I think of. The Netscreens are much further along in this than Fortinet. Hopefully v3.0 will resolve some of this. I don' t expect them to make such drastic changes in single release though. Not only would the code have to be dramatically altered from what they currently have, most firewall technicians would be lost because the concepts in VPN would be so dramatically different, albeit, that' s the way it shoud have been done in the first place. There are many changes I would like to see in VPNs to increase their flexability. Is this what you are talking about?

[Richard_Bartlett]

Yes it is. Thanks. However I can' t quite determine how the zone would be a benefit over say having the same policy on both interfaces. The main gain would appear to be that the incoming VPN packets could arrive on either interface. However the remote initiator would have to make that decision based on a singular IP. I' ve not determined if a Zone has an individual IP not bound to a physical interface ie a la VRRP/HSRP.... I' ll go and look. The best part of what you' ve helped me with Trombone is that the routeing aspects are now what I feel are the sticky point. OSPF could attend to some aspects of this but in the cases I' ve come across the WAN has been public or over semi-public infrastructure, so OSPF tunnels would be required for database propogation. However a load-variance, per packet or per flow/session (ideally selectable per policy) forwarding engine would be a good enhancement to the router part of the FortiGate. Like you said, to paraphrase you, some of this is carved in stone. This then permits firmware upgrades without losing important config when the configuration gets upgraded by the RunOnce (style) process. I figure that the closest match to this is to wire up the router to itself (physically or via vlans) and split the device into vdomains and then target an indirectly connected interface that isn' t quite the Internal side of the box. However this would half the licensed capacity of the box and cause latency due to the extra ethernet serialisation. However I' m never one to give up when I have a need and the equipment just won' t play sensibly. I' m looking forward to 3.0, but these difficiencies do make voting with your feet seem as plausible. NetScreen and ASA units are only getting cheaper.