Using FortiGate as an ISP

Hi easy to to which means: You have a Router which has the interface confgured out of /22 example .1/22 Create a VDOM-Transparent and add to outside world a interface which physically connects to the router' s ip .1. The Interface on Transparent Mode site does not have a IP which means Bridge Mode. Create a VDOM NAT and connect the NAT VDOM to the Transparent VDOM by interVDOM link. The Interface within the InterVDOM link which connects the Transparent VDOM does not have a IP (Transparent or/and Bridge Mode). The Interface within the InterVDOM link connecting the NAT VDOM does have a IP out of /22 with the Subnet /22. If you need another IP on this Interface add a Secodnary IP out of /22 with Subnet /22. At least add to the VDOM NAT a internal physical Interface which connects the lan. Thats it which means actually Request from Internal and visa verse is going: --> From internal LAN to VDOM NAT over pbulic IP /22 over the interVDOM link to the Transparent InterVDOM link through the Transparent VDOM to the ouside physical interface of Transparent VDOM through this link to the router .1/22. If you need another VDOM do the same with another NAT VDOM using another /22 IP etc. etc. etc. etc. Works out of the box like a charm and is often used by hosters. hope this helps have fun Andrea

Or just get a L3 switch or router like everybody else :) Why put a /22 of ip-traffic and try to manage the access via a firewall? Are the customer paying for security via firewall? I never heard of a ISP doing this & with a firewall ( been working in the SP arena for over 15years and currently work in a SP arena as a consultant ) Keep in mind, how many /30 do you need and how many interfaces , # of vdoms , and the #s of vlans could be a limiting factor & based on the hardware. I would recommend you review the specification matrix to look at this and the pure number of sessions. Andrea, I would like to see a topology drawing of what your proposing to ensure a clear view. Can you draft that and post it here ?

Using the transparent VDOM is the only current way to have multiple other VDOMs share a single IP subnet without any workarounds on the upstream switch/router. Until recently (scarcity of public IP space) I would have gone for each VDOM having its own /30, either on a VLAN interface to an appropriate L3 switch or a dedicated interface if needed. Unfortunately, this means that you end up using 4 IPs for each customer. With the transparent VDOM approach each VDOM only needs 1 IP from the shared pool on its VDOM link interface, using a single network, broadcast and router IP for the entire lot. You could split this up into smaller subnets but the same principle applies. If you have a /22 and don' t foresee running out of IPs very soon, the /30 approach is much ' nicer' but you use up IPs much faster. Depending on the hardware you' re using, going for the transparent VDOM approach may also lose you a lot of the ASIC acceleration when using VDOM links for the WAN side of each remaining vdom. You also lose one VDOM ' license' which may be an issue if you' re planning to use multiple low/mid range devices as opposed to a larger device with more than 10 VDOMs available. Basically, if you can afford to waste a few IPs - go for individual /30s as VLAN interfaces connected to a decent L3 switch. It' s much cleaner, uses less ports, is easier to troubleshoot and is likely to behave in exactly the way you anticipate it to work. If this is a problem, you' re going to need to make some sacrifices in either performance or complexity (or both). One last option is to use the same /22 but a different IP for each VDOM wan link and to use one of: 1. Physical interfaces for each VDOM connected to the same L2 broadcast domain (VLAN) - uses up switch and firewall ports pretty quickly. Does at least guarantee each customer the full port speed for their VDOM though. 2. Some form of VLAN translation to bridge VLANs together on the L3 switch - messy config and prone to troubleshooting problems and isn' t even an option on many switches. Could potentially be an issue for cross customer traffic depending on the switch' s forwarding logic. 3. Use an intermediary switch between the router and the Fortigate which allows multiple untagged VLANs on the port connected to the gateway router - also messy and could potentially be an issue for cross customer traffic depending on the switch' s forwarding logic. As a last resort, bug Fortinet or your Fortinet partner to push for a new feature request to allow multiple VDOMs to share a single broadcast domain (physical interface or VLAN) without having to use a dedicated VDOM for this purpose. I' ve tried to no avail but with enough interest it may get pushed up the priority list.

Hi this what is Adrian writting is true this means it depends on the implementation what has to be addtional implemented like broadcast domain etc. This means this implementation -as mentioned in my email- is " very" often used by ISP and Hoster to connect customers to there env. based on citrix. This means on the client site/location we have a FGT connecting to the main gateway over VPN. On client site we only have thin clients nothing else. Each customer receives such a NAT VDOM connected over Inter-VDOM link to the transparent fiewall. In the back which means in the local lan they have there own subnet with all stuff like ldap etc. (no need for forward domain config). Of course this is based on service and very granular and transparent also to be conf by special implementations needed on the customer site etc. If you go such a way and you plan for multiple implementation you need at least a FG-1000 (better a FG-1500) because only with 1000 and above you can buy addtional packages for VDOM' s. Again every implemetation have to be looked clearly if it makes sense or not. Only to split a /22 I would never do this. I would only do such implementation if the seperate firewall is needed based on service like described here. hope this helps have fun Andrea

A followup, we never seen the big design topology of how you would fit a /22 worth of space into a fortigate for individual customers, but I wanted to point out that /31s would waste less space and double the counts vrs a /30. Fortigates, support /31 ( 255.255.255.254 ) mask, but not as secondarys ip_address. Still the pure numbers of; interfaces ( real or virtual ), vdom, vlans and even secondaries ( your still limited to 32 per interface iirc ) would be a big limiting factor in this approach and it would not scale very well. Just keep all of this in mind, when designing this approach the complexity & potential problems it could create.