How to allow address groups to communicate

[nunderwood]

Hi all.  I'm in a pickle.  My network guy just left and I have a situation where I have 2 subnets that I need to comunicate with one another.  I am not a network guy and Fortigate is very hard for me to understand.  I really need someone to explain to me, like I'm 5, how to get these subnets to communicate.  For some unknown reason one of the subnets is a /32 and only contains the IP of a domain controller.  The client devices are all grabbing IP addresses on a totally different subnet, so my client is unable to join their new PC's to the domain.

I've tried reading all the documentation and watching videos but it's all Greek to me.  Address groups and interfaces and VLAN's oh my.  If anyone out there is willing to assist me with understanding what I'm doing here I would be forever grateful.  Thanks.

[Mrinmoy]

If possible share a network topology and firewall config (if you have no security concern)

https://docs.fortinet.com/document/fortigate/7.4.1/administration-guide/702257/configuration-backups

[rahul_p1]

Hi, Can you please explain to us from which network you are trying to communicate? Just share your network topology here so that we can understand properly and assist you better.

you need a firewall policy to allow communication between two networks. Please refer to this article.:- https://docs.fortinet.com/document/fortigate/7.0.0/sd-wan-sd-branch-deployment-guide/198932/allowing...

[Atul_S]

Hi There,

Let me try another approach since any further use of network jargon may complicate things.

What I understood so far is that you want the two subnets to communicate where one has/32 subnets assigned to a domain controller.

Imagine your Fortigate as a house and you can relate the subnets as different rooms. Now for anyone to move from one room to another, one need to pass through the doors. These doors are the route(inside the routing table) that allows one to move from one room to another. If anyone wants to go from room 1 to room 2, one need to go through the specific doors.

Likewise, if anyone want to go from room 1 to room 3, one cannot use the room 2 door but have to use the door specific to 1 and 3. So routes are cleared in terms of doors. Specific routes(door) allow specific subnets(rooms) to communicate with each other. This means that, for your problem, we have to check whether the door is there or not or it's just a room with no door at all(weird I know) Hence we have to verify the routing as one of the checks. 

Secondly, firewalls also have firewall policies that allow any connection from one subnet to another. Consider this firewall policy as a security guard standing in front of the door. So, even if you have the door if the security guard does not have your name on his permit list, you won't be able to pass just yet. Hence we have to check the firewall policy as well in your case.

For example, if one of the subnets is 192.168.1.1/24 (don't stress too much /xx at this stage) and wants to reach 10.10.10.1/32, then we can try to ping(as good as say "hello") from 192 to 10 and will run some test at the FortiGate. Please follow the below steps:

Step 1:
-------
Go to the PC, and press the window+R at the same time. A small window will open, type cmd and click ok. A black window will open. For example, if the domain controller IP address is 10.10.10.1 then in this black window, type ping 10.10.10.1 -t and keep this running.

Step 2:
-------
Now login to your FortiGate CLI type the sniffer command and hit enter. You will see some outputs After 3-4 min, press ctrl+c in the FortiGate CLI window(where you run the sniffer command) and this should stop the commands outputs. After that run the command "get router info routing-table all" and hit enter. You will get some outputs. Now, navigate to the top right corner of the black window in the FortiGate CLI page and click the down arrow and this should download a file to your download folder. FYI, refer to the attached photos to assist you with each section of "ping", "sniffer", "route table" and "log file".

Please share this file here so that we can check this further. We aim to verify things one by one so as not to overwhelm the situation.

Thanks

[nunderwood]

Thank you for breaking this down for me @Atul_S .

Sniffer:

Routing table (truncated due to security reasons).  Our routing table is very large.

Please let me know if you need more info.  Thank you!

[Atul_S]

Hi There,

Thanks for this. Even though the static route is in place, we are not getting an echo reply from 192.168.60.35 private range for 198.237.189.60 public

Please confirm the below:

-Can you ping any other address within 192.168.60.0/24 from vlan 444?

Step A:

------

-Run the same ping again from 198.237.189.60 towards 192.168.60.35 and capture the below command output:

diag sys session filter clear

diag sys session filter src 198.237.189.60

diag sys session filter proto 1   // once you ready up to this point, start ping with 20 packets from 198.237.189.60 towards 192.168.60.35. Now, run the below command and share the output

diag sys session list

Step B:

-------

Once you complete the above steps, run the sniffer you ran earlier in the FortiGate and start pinging from 192.168.60.35 towards 198.237.189.60 and share the outputs.

Thanks,

[nunderwood]

diag sys session list:

I am unfortunately not currently able to test ping in the opposite direction, as I don't have anyone on site.  I will need to coordinate this portion.

**edited for spelling**

[Atul_S]

Hi There,

Based on the session list, it seems like we need more investigation(remote session), which is not scalable using a forum at this stage. Please log in to your FortiCare account and create a ticket for TAC to investigate this further. 

Thanks,