Manage remote gateway behind a local GWY

[Matthew_Do]

Policy can be successfully installed on the remote gateway (Br-FW2) from SmartDashboard PC in the local network behind another gateway (HQ-FW1).

However, ssh and https from SmartDashboard PC to remote gateway (Br-FW2) fails, although policy rule 1 allows these traffic.

SmartDashboard PC is in subnet 172.16.0.0/24 which is hidden behind its default GWY HQ-FW1 (external IP 10.0.0.111)

Can someone see what's wrong?

;[cpu_1];[fw4_2];fw_log_drop_ex: Packet proto=6 10.0.0.111:10182 -> 10.0.0.112:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW2a Network" rule 2;
;[cpu_1];[fw4_2];fw_log_drop_ex: Packet proto=6 10.0.0.111:10182 -> 10.0.0.112:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW2a Network" rule 2;
;[cpu_3];[fw4_0];fw_log_drop_ex: Packet proto=6 10.0.0.111:10182 -> 10.0.0.112:443 dropped by fw_send_log_drop Reason: Rulebase drop - on layer "FW2a Network" rule 2;

[Danny]

The rule in your screen shot is for the policy installation target Br-FW2 only. As there is a rulebase drop on rule #2 I recommend you to add HQ-FW1 as policy installation target to that rule as well. If HQ-FW1 has it's own security policy, make sure to allow the access there.

[Matthew_Do]

SmartConsole is hidden behinds HQ-FW1, when it tried https to Br-FW2, it was seen at Br-FW2 as HQ-FW1 (external IP) and was rejected.

Adding HQ-FW1 to the list of allowed host resolves the issue. I can manage remote Br-FW2 from SmartConsole PC.

[Aidan_Luby1]

That makes sense because from Br-FW2 the source it sees is the Natted Public IP of HQ-FW1, not the internal IP of your pc. I believe you could even be more specific by making a Network Host Object for your HQ-FW1 external IP (or range of IP's if you have multiple nat IP's) and setting that as your source, with the destination being another host object for the external IP of Br-FW2 (or again a network/IP Range object if you have multiple external IP's).