Hello, I am coming to you after spending many hours trying to solve this issue and i hope you could share some light on the issue
We are running fortinet 90D in the office and we have two ISP links connected to two switches and from there to the WAN1 & WAN2 interfaces on the fortinet appliance. The internal network is connected to port 1 interface. A quick diagram will look like this:
ISP -> switch 1 & switch 2 -> fortinet -> switch -> internal network ISP
We are running 3 VDOMs in NAT operation mode and everything works just lovely.I am attaching a screenshot of the interfaces that we are using.
The issue that we are facing with now is that we need to connect a video conference appliance that will need to use a public IP address. One of the 194.*.*.* that we get from our ISP. We can connect the VC appliance directly to the ISP using the switch, but we would like to have a FW to control the incoming and outgoing traffic.For that, we are are thinking about adding another VDOM that will be a transparent VDOM and will help us to monitor and control the traffic coming to the VC appliance.
We add another VDOM, set it as transparent, set two new interfaces (port 3 & port 4) to the VDOM. Port 3 is connected to the switch and set to vlan 2 (the same vlan as the ISP connection) and port 4 is connected directly to the VC appliance.
Running ping from public location to the VC public IP address, we could see ARP request coming from the ISP default GW, looking for the VC MAC address. We could also see the VC reply to that ARP, but it seems that the ISP is unable to receive the reply: (i changed the IP of the VC to 194.*.*.2 and the ISP to 194.*.*.1)
(Video) # diagnose sniffer packet internal4 "" 4
interfaces=[internal4]
filters=[]
pcap_lookupnet: internal4: no IPv4 address assigned
1.726121 internal4 -- arp who-has 194.*.*.2 tell 194.*.*.1
1.726244 internal4 -- arp reply 194.*.*.2 is-at 0:e0:db:42:44:10
2.718951 internal4 -- arp who-has 194.*.*.2 tell 194.*.*.1
2.719070 internal4 -- arp reply 194.*.*.2 is-at 0:e0:db:42:44:10
3.718960 internal4 -- arp who-has 194.*.*.2 tell 194.*.*.1
3.719076 internal4 -- arp reply 194.*.*.2 is-at 0:e0:db:42:44:10
6.725296 internal4 -- arp who-has 194.*.*.2 tell 194.*.*.1
6.725418 internal4 -- arp reply 194.*.*.2 is-at 0:e0:db:42:44:10
8 packets received by filter
0 packets dropped by kernel
(Video) # diagnose sniffer packet internal3 "" 4
interfaces=[internal3]
filters=[]
pcap_lookupnet: internal3: no IPv4 address assigned
1.044888 internal3 -- BPDU on switchport 'internal10' stp 802.1s, rapid stp, cist flags [forward]
2.725509 internal3 -- arp who-has 194.*.*.2 tell 194.*.*.1
2.725675 internal3 -- arp reply 194.*.*.2 is-at 0:e0:db:42:44:10
3.044840 internal3 -- BPDU on switchport 'internal10' stp 802.1s, rapid stp, cist flags [forward]
3.718876 internal3 -- arp who-has 194.*.*.2 tell 194.*.*.1
What do you think? Do we need to have an inter vdom link ? Do we need to set forward-domain on the interfaces? Can we delete the transparent VDOM and use the same Corp VDOM to have 2 public IPs in the same subnet? Do we have an issue with sharing the WAN interface? Any help / advice / question will be much appreciated.
Thanks
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
There are several options in "config system interface" pertaining to L2 forwarding and VLAN forwarding. I'd check these in the CLI Reference for your version of FortiOS (which is...?).
The WAN switches (plural) will have to have VLAN 2 forwarding enabled.
What about the default route in the second VDOM? Somehow the VDOM will have to know about the ingress addresses (which are arbitrary) so it won't discard the traffic as 'of unknown origin'. Frankly, I haven't worked much with TP mode yet so I'm in shallow waters with this one (whether RPF is active in TP mode).
Hi Ede, Thanks a lot for the quick reply and the helpful information. We already go over the system interface settings, and try all kind of combination . Like setting set l2forward enable & set forward-domain , but i with no luck. Do you think we need to enable forward-domain or l2forward also on the WAN interface? We haven't try that. About the default route, since this is a transparent VDOM, i dont think we need to have any routing. should i add a default route on the TP VDOM ? The firmware version we are using is: v5.2.4,build688 Thanks.
gmiretzky wrote:Hi Ede, Thanks a lot for the quick reply and the helpful information. We already go over the system interface settings, and try all kind of combination . Like setting set l2forward enable & set forward-domain , but i with no luck. Do you think we need to enable forward-domain or l2forward also on the WAN interface? We haven't try that. About the default route, since this is a transparent VDOM, i dont think we need to have any routing. should i add a default route on the TP VDOM ? The firmware version we are using is: v5.2.4,build688 Thanks.
Did you put both port 3 & port 4 in the same Fortwarding-domain and created a Policy that accepts the traffic?
No routes is needed in Transparent mode.
Nilsan wrote:
Did you put both port 3 & port 4 in the same Fortwarding-domain and created a Policy that accepts the traffic?
No routes is needed in Transparent mode.
Yes, we have. We added both ports:
edit "internal3"
set vdom "Video"
set broadcast-forward enable
set l2forward enable
set type physical
set forward-domain 2
set snmp-index 19
next
edit "internal4"
set vdom "Video"
set broadcast-forward enable
set l2forward enable
set type physical
set forward-domain 2
set snmp-index 20
And we also add allow all rule to the policy (as you can see in the attached picture)
Hi,
Sorry for jumping such an old post, but i just wanted to say, we are still looking for a solution for this problem.
Anyone have any idea? I just can't believe there is no solution for this issue. All we need is a way to have two VDOMs (one NAT and the other transparent), that will share the same ISP.
On the NAT VDOM we have configured the IP/subnet , but we have another machine that will need to use the same subnet to connect (it will connect using public IP).
It seems that the fortigate NAT VDOM is listening to the second IP (the transparent VDOM) also.
I am adding another drawing that i made.
As you can see we have two Forti devices connected in active/passive
The IP 192.168.0.0/24 - is really our real IP subnet - it changed it just for the drawing
One VDOM is using the WAN1 interface and has the public IP + subnet configure on the interface - it is connected to VLAN 2 in the switch
The transparent VDOM is using two interfaces - internal7 & internal8
internal7 is connected to vlan 2 (this is the external ISP vlan)
internal8 is connected to the server
on the switch, both internal7 & 8 are configured as access port (access vlan2 & access vlan4)
The idea is that traffic going to the server IP - 192.168.0.3 - will go to internal7 and from there to the server (which is isolate on vlan4)
For some reason i still see traffic for 192.168.0.3 on the NAT VDOM interface.
Please help.
I can help you..
In which interface you see traffic on nat vdom ? its has to be only on wan1
The external interface on nat vdom is on the same vlan as interface 7 on transparent vdom so is okay if you
see traffic directed to 192.168.0.3 on wan1 because arp , and are on the same vlan.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1647 | |
1070 | |
751 | |
443 | |
214 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.