Trunk between Fortigate and Cisco Router

[nair_ron]

Hi Guys,

I have an issue which I am working on. I have a scenario setup with 2 separate network EG Network A and Network B. Network A is an existing production environment with simple setup. Cisco Router Interface A connected to WAN (OSPF) and Interface B connected to layer 2 switch. Router gives out IP to clients connected to switch with 192.168.2.x/24 IP range. This is working fine.

Network B - Has FG as edge with Interface running VLANS and connected different subnets. EG Port1 has VLAN10 etc with IP 10.11.15.33/28. Port 2 has an IP in the range of Network A on /24 configured configured on the interface itself e.g. 192.168.2.200 (I also tried to put it as a VLAN with subinterface IP as above)

FG is connected to a Layer 2 switch that has VLAN trunk allowed all and e.g port 4-8 is given access as VLAN10. Access port is connected to HOST A, B with IP's 10.11.15.34 and .35 respectively.

I need to have Client from Network A able to access HOST A in Network B which I am not able to do. I can Ping all interfaces in FG and VLANS talk to each other. Issue is when it goes to Network B

I tried different variation - I made a Trunk between the 2 switches and added sub interfaces in the Router in Network A with all VLANS. Router is trunked to Switch in Network A and there is second trunk going to switch  Network B.

I am not sure what I am missing but I am figuring it has to do with port 2 interface in with IP of second network. I am able to ping from FG to the Router using this setup but not to client.

Any suggestions?

[Justlinux · Accepted solution]

I think you are on the right target - it is an issue related to having two potential gateways on the same network along with a client that is configured (by dhcp) for the single Cisco router gateway. I would suggest reworking the topology to eliminate the clients routing decision. You also could manually add the network B route pointing to 192.168.2.200 on each client (which would be a very manual fix). I would advise against adding a route on the Cisco pointing Network B to the 192.168.2.200 address due to traffic from the client generally "bouncing" off the Cisco before it would forward it on to the Fortigate interface.

[Justlinux · Accepted solution]

I think you are on the right target - it is an issue related to having two potential gateways on the same network along with a client that is configured (by dhcp) for the single Cisco router gateway. I would suggest reworking the topology to eliminate the clients routing decision. You also could manually add the network B route pointing to 192.168.2.200 on each client (which would be a very manual fix). I would advise against adding a route on the Cisco pointing Network B to the 192.168.2.200 address due to traffic from the client generally "bouncing" off the Cisco before it would forward it on to the Fortigate interface.

[emnoc · Accepted solution]

What your trying to do is not even remotely possible, your trying to use a FGT in a switch-mode but it's not a switch nor operates as a switch unless it's transparent.

What you need to determine is 1> do you want routed ( aka NAT mode ) or 2> transparent and then build your layer2/layer3 segments to match your mode of operation. What you  probably might realize is that you need transparent mode for the topology that your indicating and stick the  FGT between the ISP-router and the LAN. In this setup, you will allow the  router to issue DHCP ( fwpolicy has to allowed this ) and if you need multiple LANs, you just trunk more sub-interfaces on the router

e.g

LAN01 ==tag 111 ( desktop )

LAN02  ==tag 112 ( servers )

LAN03 == tag 113  ( wireless )

Build the policies that you need  for allowance of traffic from the LANs. This commonly labeled as a "router on a stick"

[nair_ron]

Thanks for the quick response.Thanks Justlinux. The idea manual fix was already found but that is something I do not want to do in client machines. The change of topology I had suggested as well but the team implementing the new network environment are amendment on having Forti as the routing device. I did find a solution which I assume what you meant you advice against but it works.

Emnoc I understand what your trying to say as I advised the almost the same to the vendors initially who are setting up the equipment to be routed through the second network (this is a requirement from them and design the same which I made a lot of changes to)

What I am tying to imply is that the environment where there is a Router (say Network A) that gives DHCP is a Corporate site that is connected to my HQ.  The location is separate from HQ and above set-up explains how it is connect. ISP Router-----My Router----Switch----Client. Router give IP and all runs on VLAN 1. ISP connects to my HQ. Clients use gates of MY Router.

Environment 2 on the same site is a SCADA network and needs to be totally separazte. Newly connected whereby all SCADA sites now are centralized to one location. Network B is such.- All Devices from various SCADA sites connect to this site where setup is such SCADA WAN---Fortigate----Switch---Various VLANs(these VLANS connect separate sets). Host of each VLAN use gateway of its respective VLAN IP configured in the Fortigate sub interface.

What I have done so far is Network A scenario has been change. I have added sub interfaces on my Router and made a trunk from my Router to the switch. Then I made a second trunk on the switch with VLANS allowed to connect to a second port in Forti which has a VLAN same as the VLAN configured in Corporate Router.

Doing a ping test in FG by making the trunk to Corporate IP as a source show that both interfaces in Forti talk to each other. Host go as far as the Corporate router.

As mentioned I found a solution and that was to add static routes to the Corporate Router for each VLAN in the FG with the gateway as the IP of the second interface of FG. (that is the IP give to FG which is from same range as the Corporate router.

Using this I am able to have communication. I am not much for adding static routes but for now it works and I do not see the VLANS growing but still gives me time to work on a better solution. If there is let me.