Connectivity Issue Between 2 Fortigate ?!

[huud]

Hi,

I have 2 Fortigate setup as below, and the issue as follows.

FW1 cannot ping anything on FW2. network, but FW2 can ping FW1's 10.11.30 and 10.11.40 network.

BGP is setup between the 2 and is working fine, with RouteMap and Prefix List, so traffic from 10.11.30.0 flows through port1 (192.168.9.181) and 10.11.40.0 through port2 (192.168.9.182), smae configuration is on FW2 for 10.21 network.

FW1

Routing table for VRF=0
C 10.11.30.0/24 is directly connected, VLAN30
C 10.11.40.0/24 is directly connected, VLAN40
B 10.21.30.0/24 [20/0] via 192.168.9.182 (recursive is directly connected, port1), 00:18:07, [1/0]
B 10.21.40.0/24 [20/0] via 192.168.10.182 (recursive is directly connected, port2), 00:17:40, [1/0]
C 192.168.9.0/24 is directly connected, port1
C 192.168.10.0/24 is directly connected, port2

FW2

Routing table for VRF=0
B 10.11.30.0/24 [20/0] via 192.168.9.181 (recursive is directly connected, port1), 00:18:47, [1/0]
B 10.11.40.0/24 [20/0] via 192.168.10.181 (recursive is directly connected, port2), 00:18:15, [1/0]
C 10.21.30.0/24 is directly connected, VLAN2130
C 10.21.40.0/24 is directly connected, VLAN2140
C 192.168.9.0/24 is directly connected, port1
C 192.168.10.0/24 is directly connected, port2

I ran sniffer on FW2 to capture the traffic and this is all no icmp reply

FW2 # diagnose sniffer packet any 'host 192.168.9.181' 4 0 1 interfaces=[any]
Using Original Sniffing Mode
interfaces=[any]
filters=[host 192.168.9.181]
pcap_snapshot: snaplen raised from 0 to 262144
0.696750 port1 in 192.168.9.181 -> 10.21.30.100: icmp: echo request
1.696916 port1 in 192.168.9.181 -> 10.21.30.100: icmp: echo request
2.697103 port1 in 192.168.9.181 -> 10.21.30.100: icmp: echo request
3.697244 port1 in 192.168.9.181 -> 10.21.30.100: icmp: echo request
4.696819 port1 in arp who-has 192.168.9.182 tell 192.168.9.181
4.696838 port1 out arp reply 192.168.9.182 is-at 00:0c:29:a3:9f:f6
25.959741 port1 in 192.168.9.181.10737 -> 192.168.9.182.179: psh 1515141430 ack 1109234650
25.959852 port1 out 192.168.9.182.179 -> 192.168.9.181.10737: ack 1515141449
26.637436 port1 out 192.168.9.182.179 -> 192.168.9.181.10737: psh 1109234650 ack 1515141449
26.638116 port1 in 192.168.9.181.10737 -> 192.168.9.182.179: ack 1109234669
30.977359 port1 out arp who-has 192.168.9.181 tell 192.168.9.182
30.977987 port1 in arp reply 192.168.9.181 is-at 00:0c:29:ef:3e:b4

The policies are the same on both.

Not sure what is going on, any thoughts ?

Thank you

[huud]

Apologies, not a firewall guy..

The Firewall VLAN interfaces 10.11.30.100 on FW1 is the gateway for the VM, and is what is set in the VM, same on the FW2 and VMs connected to it as well.

[ede_pfau]

and you've got policies between the gateway ports and the VLANs?

for instance, on FW2, between port1 and VLAN2130?

I apologize, the routing seems to be correct from the routing table you show in your request.

[huud]

I have added for port and VLAN 2 policies each.

Port1 to VLAN2130

VLAN2130 to Port1 ---> NAT only on this policy

Port2 to VLAN2140

VLAN2140 to Port2 ---> NAT only on this policy

The same on FW1 as well.

[huud]

This is how I understood it and implemented on both sides VLAN.

[ede_pfau · Accepted solution]

For example, you're missing VL30 > p2, if VL30 is sending traffic to VL2140. You've got only half of the required policies.

[huud]

Thanks this solves the issue, ping now reaching from both side to both interfaces..

I'm understanding I need to enable NAT on every VLAn interface is that correct ?

[ede_pfau]

No, you don't. You should only need and apply NAT on policies to the WAN.

If traffic stops without NAT then your routing is flawed.

[huud]

If you are referring to WAN as Internet then in my case both VMs are on private networks, and not accessing internet.

I disabled NAT on policies and the traffic stopped, but then my routing seems to be fine, this then means some issue within the RouteMap and Prefix List, will remove them and check.

[ede_pfau]

No, the routing table looks fine (in your original post starter). Check that the VMs know where to send traffic regardless of it's origin.

If still stuck, run the "diag deb flow" analysis as already shown.

[huud]

Thanks, not sure I understand check that the VMs know where to send traffic regardless of it's origin, the VM is one of those small Void Linux, it jus thas a Gateway configured on it, I'm running debug flow and checking it..