Skip to main content
dan
Explorer II
December 18, 2020
Solved

Bug in documentation or my wrong? (Inter-VDOM routing)

  • December 18, 2020
  • 7 replies
  • 7202 views

I try to understand the Inter-VDOM routing example at https://docs.fortinet.com/document/fortigate/6.2.4/cookbook/335646/inter-vdom-routing

 

In the example VDOM "Sales" connects to VDOM "root" via vdom-link "SalesVlnk".

The two interfaces are "SalesVlnk0" (on VDOM "Sales" side) and "SalesVlnk1" (on VDOM "root" side).

Nothing fancy here and I understand all of it (perhaps except the p2 and p3 IP addresses as they to not correspond with the picture in the example), until it comes to the policies.

 

The firewall policies in that example puzzle me. I believe those are wrong. But I might be mistaken? Please help me understand. It seems to me that the policies are completely garbled, though. For example the Sales VDOM related ones (this is from the content of above link):

To configure the firewall policies from SalesLocal to the Internet:

config vdom
    edit root <<< should that not be "Sales"?
        config firewall policy
            edit 6
                set name "Sales-local-to-Management"                 
set srcintf port2 <<< port2 is assigned to other VDOM in example.. correct port would be port 3
                set srcaddr all
                set dstintf SalesVlnk <<< I can't select this interfac, should that not be "SalesVlnk0" or "SalesVlnk1"?
                set dstaddr all
                set schedule always
                set service ALL
                set action accept
                set logtraffic enable
            next
        end
    next
    edit Sales <<< should be "root" I think
        config firewall policy
            edit 7
                set name "Sales-VDOM-to-Internet" <<< according to this, this policy should be on VDOM root, right?
                set srcintf SalesVlnk <<< Can't select this as interface. This is the vdom-link... which is the correct interface?
                set srcaddr SalesManagement <<< what address might that be? I'd guess
                set dstintf external
                set dstaddr all
                set schedule always
                set service OfficeServices
                set action accept
                set logtraffic enable
            next
        end
    next
end

 

This is just an excerpt. Up to the firewall policies, it makes sense.. then, it doesn't.. for me..

 

I have a FG100F with 6.4.3, but the documentation is based on 6.2.4. I might not be able to do some of that due to version changes, but I frankly believe the example is wrong. I compared to other versions. They are slightly different, but all of them seem incorrect to me.

 

As I urgently need to understand how this works, would someone please provide me with a correct example?

or.. correct me if I'm wrong?

 

Thanks

Daniel

 

Best answer by Toshi_Esumi

Yea, virtually everybody needs to experience documentation bugs, especially with cookbooks, one way or the other. Of course, without '0' or '1' it's not even an interface. You need to correct those errors intelligently while you read through any document.

However, if your 100F should suport npu_vlink, which goes through the np6xlite off-loaded from the CPU, and that's what you should be using instead of theose regular vdom links.

Check below architecture doc first:

https://docs.fortinet.com/document/fortigate/6.4.0/hardware-acceleration/47902/fortigate-100f-and-101f-fast-path-architecture

Then configure like below. It's 6.0.0 doc but this part should be the same.

https://docs.fortinet.com/document/fortigate/6.0.0/hardware-acceleration/851990/configuring-inter-vdom-link-acceleration-with-np6-processors

It would make a significant difference in performance under multi-vdom envitonment.

 

Toshi

7 replies

Toshi_Esumi
SuperUser
SuperUser
December 18, 2020

Yea, virtually everybody needs to experience documentation bugs, especially with cookbooks, one way or the other. Of course, without '0' or '1' it's not even an interface. You need to correct those errors intelligently while you read through any document.

However, if your 100F should suport npu_vlink, which goes through the np6xlite off-loaded from the CPU, and that's what you should be using instead of theose regular vdom links.

Check below architecture doc first:

https://docs.fortinet.com/document/fortigate/6.4.0/hardware-acceleration/47902/fortigate-100f-and-101f-fast-path-architecture

Then configure like below. It's 6.0.0 doc but this part should be the same.

https://docs.fortinet.com/document/fortigate/6.0.0/hardware-acceleration/851990/configuring-inter-vdom-link-acceleration-with-np6-processors

It would make a significant difference in performance under multi-vdom envitonment.

 

Toshi

dan
danAuthor
Explorer II
December 18, 2020

Well, the reason I go through those examples is to learn.

Most people tell me that I must do a training course. I will, most likely, but for now, I need reliable information on how to do things.

Do you, or somebody else could point me to a reliable example that would show me (a novice) how to do Inter-VDOM routing? Perhaps as detailed as the cookbook?

 

Thanks

Dan

 

Toshi_Esumi
SuperUser
SuperUser
December 18, 2020

Below is the only thing I could find so far. But it's simple, just a built-in vdom-link and one side is named as npu0_vlink0 and the other side is npu0_vlink1. You should create VLAN interfaces on top of npu-vlink to have muliple links.

https://docs.fortinet.com...r-vdom-link-interfaces

Once you configured a set of VLAN interfaces on both sides, the rest is just regular VDOM/FW/router configuration for routing toward the destinations and set of policies to regulate traffic between ingress and egress interfaces. You already know what VDOM does and have chosen to use them on your new FW. I believe you can figure this out even by yourself.

 

 

 

Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.
Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!