Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
J_One
New Contributor

Multiple virtual interfaces

Hello everyone, I'm trying to setup my 40c with multiple virtual interfaces. I  simply followed this guide: http://kb.fortinet.com/kb....do?externalId=FD33738 Which basically comes down to: #FGT40C-3 # config system interface #FGT40C-3 (interface) # edit 'myvlan interface' #new entry 'myvlan interface' added #FGT40C-3 (test) # set interface internal #FGT40C-3 (test) # set vlanid 100 #FGT40C-3 (test) # set ip 192.168.100.254/24 #FGT40C-3 (test) # set vdom root #FGT40C-3 (test) # end I created the routes: IP 192.168.100.254/24 --> gateway 0.0.0.0 --> device wan1 And finally i created a policy to allow all outgoing traffic from 192.168.100.254/24 to the wan interface. My setup is: Fortigate 40c TP link sg108 (which holds the VLAN IDs) Intel NUC with ESX 6.5 (where I created the port groups based on the VLAN IDs) When I connect one of my VMs to one the newly created interfaces I can't get anything to work.

Any thoughts?

 

7 REPLIES 7
Iescudero
Contributor II

Hi there!

maybe is a dumb comment, but can you double check your route?

It should look something like this:

 

configure routing static

edit 1

set gateway 172.100.20.5

set device wan1

set dst 0.0.0.0

next

end

 

And then, what I would do is this:

 

1) Check in your internal interface if you any traffic with this:

diagnose sniffer packet internal

 

If you see a packet like this: 

0.553565 802.1Q vlan#100 P0

1.553430 802.1Q vlan#100P0

That would mean that your Switch and VM host configuration is right, otherwise is not, so you will have to check that.

 

2) Assuming that you saw packets with the VLAN tag, now you have to do is analysis that traffic, for instance you can do a ping to a google DNS from a host in VLAN 100:

 

diagnose sniffer packet myvlan interface "host 192.168.100.10 and icmp"

0.822234 192.168.100.10 -> 8.8.8.8: icmp: echo request

 

3) Finally, you can debug this traffic to see what's going on:

diagnose debug flow filter saddr 192.168.100.10

diagnose debug flow filter daddr 8.8.8.8

diagnose debug flow filter proto 1

diagnose debug flow show console enable

diagnose debug flow trace start 100

diagnose debug enable

 

Then you should look the output and check if you see something like this:

"iprope_in_check() check failed, drop"  or "Denied by forward policy check"  or "reverse path check fail, drop"

 

Hope it helps!

sw2090
Honored Contributor

Probably you have a mistake in your policy (If you set it like you wrote here).

You have to allow the traffc from the whole subnet 192.168.100.0/24

Routes have to be for the net too.

 

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
J_One
New Contributor

Hello guys, apologies for the late reply.

 

I tried/checked all of the above (re-entered the route), but i don't see any traffic from VLANs 200 when I enter 'diagnose sniffer packet internal'.

And I'm pretty sure the VLANs are correct because is basically the same setup as before, just a few extra VLANs.

 

sw2090
Honored Contributor

coud you additionally post a screenshot of your FGT's routing table? 

 

What I see is you have a vlan and a policy for internet access via dnat. This is good so far.

You one Screen (Switch) shows port 2 is just tagged in vlan 200. Basically this would mean that the device connected to that port on that switch must do the vlan tagging for tagged means the switch won't touch it.

What I miss is that there is only ONE port tagged in vlan200. It has to be at least two because the port your client is connected must be in that vlan and also the port that goes to your FGT has to be tagged there. And if there is more swiches between this and the FGT the whole "way" has to be tagged then. Otherwise there would not be vlan transport between FGT and Client...

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
J_One
New Contributor

Here is  a screenshot of my routing table:

 

As you point out, port 2 is the only port carrying the VLAN tags, and this is correct because port 2 is where my NUC (with ESXi) is connected to. And this is where the VLAN tags are divived into seperate virtual adaptors within ESXi (based on the VLAN tags), and this is where I need the VLANs, on my Virtual Machines. Al the physical devices are untagged on all of the other switch ports.

 

 

emnoc
Esteemed Contributor III

You need to do what lescudero  suggested and I would look at the firewall local arp table for that interface 

 

diag ip arp list 

 

if you have no  entries for the 192.168.100.xxx than fix your network/switching. Can you ping the  next-hop gateway from the client machines ( you need to allowaccess ping  on the interface )

 

Ken

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
J_One
New Contributor

Finally, its working!

Turns out I made two mistakes:

1) I didn't set the VLAN tags on the physical port my Fortigate was connected to (I know, floolish of me...)

2) I didn't enable ping on my DMZ interface (which I was trying to ping all the time...)

 

Big thanks to all of you! You helped me a lot! 

Labels
Top Kudoed Authors