FortiWiFi 90D - Network Design Change - Need Help

[HughOD]

We are moving to using Google Fiber with our FortiWiFi 90D, and the way Google handles static IPs and the way we currently have this device configured has us stumped.

{NOTES:  This office has tenants that are each on their own VLAN for privacy.  IPs are changed for the sake of the client's anonymity}

Current Setup 

2 VDOMs

[ol]

Name:  network[ol]

Port: WAN 1: manually sets its static IP (60.70.50.41)

Port: Interface 1: serves up the LAN for computers, etc in the 192.168.x.x range.[ol]

There are ~20 VLANS in this VDOM for each unique tenant in the office.

There are 3 machines down here with Virtual IP address like:[ol]

60.70.50.42 -> 192.168.18.2;  60.70.50.43 -> 192.168.18.3;  60.70.50.44 -> 192.168.18.4[/ol][/ol][/ol]

Name: phones[ol]

Port: WAN 2: manually sets its static IP (60.70.50.51)

Port: Interface 2: serves up all of the VOIP phones in the 192.168.100.x range on VLAN ID = 100.[/ol][/ol]

The VDOMs are given 50/50 priority.  This setup was so the VOIP vendor has full control over their network... and has worked well for years.  We did not set this up, the old IT vendor did.

New Setup Needed

Now that we are switching to Google Fiber, the way they hand out Static IPs is "funky".  You get one static IP that you receive via DHCP.  Then, the other 5 that we purchased are on a different subnet completely.

Example:

     Static IP via DHCP:  23.228.140.27

     Static IP LAN Subnet:  136.50.213.72/29

What I would *like* to do is assign 136.50.213.74 to be WAN 1.  Use 136.50.213.75-77 to be my 3 Virtual IP addresses on point 1.2.2.1 above.  And Use 136.50.213.78 for WAN 2.

But, I can't figure out how to get this to work.  I currently have WAN 1 using 23.228.140.27 and forwarding 136.50.213.75-77 properly, but I can't get the "phones" / WAN 2 to route properly.

Since the routing from the 23.228.140.27 to the 136.50.213.72/29 is on the "network" VDOM, how can I use the last IP for WAN 2?

I really don't want to have to rebuild the entire network layout.  Is there a way to do this?  I'm not super verbose in the Forti OS and capabilities.

Any help would be GREATLY appreciated.

Thank you,

Hugh

[Toshi_Esumi]

The "funky" you described seems to be very common at least around my area (NW corner of the US) like CenturyLink fiber or Comcast: get one interface public IP and GW then get additional public subnet /29s when customers request. You just need to know if those specific internet destinations, like voip vendor, SMTP server, etc. are expecting packets sourced from one of those VIP IPs in additional subnets. If yes, like in many cases, you need to SNAT those outgoing packets with the same IP in VIP.

[HughOD]

Would you be willing to explain how I can setup the SNAT for WAN2?  Like I said, not real great with this interface.  I inherited this router.  Thanks.

[ede_pfau]

The VIP will automatically take care of the source address: it will not only exchange the destination address for incoming traffic but will also source-NAT (exchange the source address) for outgoing traffic. 

You would only need additional source NAT (which would be done via enabling NAT in the policy, and specifying an IP pool) in a policy from LAN to WAN, that is, if these hosts initiate outbound sessions as well.

As I see it you have 2 independent VDOMs with 2 independent ISPs and default routes. Insofar, I don't understand the remark on 'routing between the 2 public addresses'. Just connect the voice VDOM to the same LAN switch as your LAN-VDOM, and pass the proper gateway and address to your phones via DHCP.

Actually, you cannot NOT use the one WAN1 public address - your connection/login to your ISP depends on the DHCP handshake. So one WAN interface will have to use that address while you're free to use the other address range via VIPs for either the LAN-VDOM or the phone-VDOM.

[Toshi_Esumi]

It's automatic only if the session is initiated from outside. Like an SMTP server, if the server located inside initiates a new session toward the internet there is no reference to the VIP statement and it follows the first available NAT policy, which is typically NATed with the interface IP. We had this problem in the past and created an ip-pool with one IP used in the VIP then SNATed with an outgoing policy using the ip-pool.

v5.6 seems to have improved these NAT related features and one policy seems to be able to handle both. But I haven't tested 5.6 yet so just based on "What's new" doc.

[Toshi_Esumi]

By assuming it's not 5.6, the config is simple and you can do it from GUI.

1) create an IP Pool with only one IP in the external IP range and accept all other default values.

2) create a new policy from inside to outside interface/zone with NAT enabled then choose "Use Dynamic IP Pool" instead of "Use Outgoing Interface...", then select the IP Pool you created.

3) move the new policy above the existing(default) inside to outside interface/zone policy.

You should test by at least sniffing on the outgoing interface to see the source IP of the packets (like ping) has the IP you intended. If you do "flow debug" that are in many other threads you can see the process in a flow.

[HughOD]

From what you are suggesting - "Just connect the voice VDOM to the same LAN switch as your LAN-VDOM" - The phone-VDOM would be running through the LAN-VDOM.  Therefor, they wouldn't really have 50/50 priority anymore... would they?

[Toshi_Esumi]

My questions to your description of the old/previous network are like below:

- Was the upstream device the previous ISP provided had two connections to your FG90D at WAN1 and WAN2? Or there were two physical circuits or two ISPs terminated at each WAN port?

- What is the default GW for each VDOM? You later mentioned phone VDOM is coming through LAN VDOM which doesn't much the description for WAN1 and WAN2 before.

- also I don't understand what is "50/50 priority of vdoms".

But unless you got two circuits from Google and terminating each at WAN1 and WAN2 separately, you have to use only one WAN port to get out to the internet. Then inside you might want to use VDOMs for some separation but you have to split the additional /29 to two /30s or even further into /31s to deliver the public IPs to each VDOM, so  probably it would be completely new design from whatever You had before.