Using firewall's own loopbacks as dummy Panorama servers

[salzmant]

Hello,

was trying to find if anyone has ever dealt with something similar, but couldn't find anything (so, hopefully this isn't a duplicate post).

Some info to put things into perspective:

I was tasked to migrate 6 HA (active-passive) clusters from soon-to-be-decommissioned Panorama (hosted in Azure) to our on-prem Panorama (hosted in DC) - all the device groups, templates, template-stacks, etc. were successfully migrated and prepared already. All the firewalls, have their own public IP and right now connect to the current Panorama via public IP (through the internet). Management and Untrust (internet facing) dataplane interfaces have IPs from the same subnet.

The new Panorama is not publicly accessible from the internet due to company policies (MGMT network, where Panorama and jump servers are, not being opened from the internet). I have built an IPSec tunnel between the firewalls and VPN GW (hosted in the same MGMT network as Panorama) to route the FW->Panorama traffic through it.

Now, since the new Panorama IP address is not routed towards the firewall (to then continue into the IPsec tunnel), but instead goes via default route into the internet and the customer/their ISPs were not keen to route it to my firewall (due to some concerns about it being propagated further, etc.) I have been given IP, from the same public subnet as where the FW management and dataplane Untrust interfaces are so that I would use it to DNAT that Panorama IP. Meaning, I created loopback interface on the firewall, which would be reachable from the management interface and created NAT policies.

Example IP addresses:

FW Management interface IP -> 11.11.11.1

Loopback IP -> 11.11.11.2

Real Panorama IP -> 192.168.0.1

Logic is that on the firewall I'd configure Panorama server to be (11.11.11.2) and I'd have a NAT (both SNAT+DNAT) policy to then translate the 11.11.11.2 (Loopback) to 192.168.0.1 (Panorama), which would be then routed into the tunnel (as I can't use 192.168.0.1 directly for Panorama on the firewall).

When I however try this approach, it doesn't seem to work -> I can't see anything in the dataplane traffic logs and also when I tried packet capture directly on the management interface.

The only thing I can see is this in ms.log (IP changed to reflect example IPs above):

2026-08-27 06:13:13.154 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30
2026-08-27 06:15:32.418 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30
2026-08-27 06:17:51.682 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30
2026-08-27 06:20:10.946 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30
2026-08-27 06:22:30.210 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=31
2026-08-27 06:24:49.474 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30
2026-08-27 06:27:08.738 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30
2026-08-27 06:29:28.003 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30
2026-08-27 06:31:47.266 -0400 Error: pan_comm_get_tcp_conn_gen(comm_utils.c:881): COMM: cannot connect. remote ip=11.11.11.2 port=3978 err=Connection timed out(110) sock=30

So, TLDR my question is - is it not possible to use firewall's own interface IP address to serve as a "dummy" Panorama server? Even though management plane and dataplane are split, so I'd assume it wouldn't care about that?

Also - changing service routes from the default (management) interface to some of the dataplane interfaces is not really preferred as then the Passive firewall node wouldn't be connected to Panorama.

Thank you all in advance. Might be quite dirty approach, but given the topology, etc. this seemed to be the best one. Also I am aware that I might have described the situation confusingly, so sorry about that, but I'm quite lost with this case.

[TomYoung]

Hi @salzmant ,

I manage multiple remote NGFWs from Panorama in a data center over IPsec tunnels.  It works great.  I don't NAT or do anything fancy.  The NGFWs connect from the management interface to the Panorama private IP address.  I don't understand why "the new Panorama IP address is not routed" over the IPsec tunnel.  Why would a private IP address be routed to the Internet anyway?  A great design principle is simplicity as complexity decreases availability.  I tried to read through your post to understand the reason, but I couldn't.

Thanks,

Tom

[salzmant]

Hello @TomYoung,

"Why would a private IP address be routed to the Internet anyway?"

sorry, giving the Panorama address 192.168.0.1 was a bad example, wanted it just to distinguish that it's something else. (Also some NATs are needed, because it's a specific-customer dedicated firewall and there are things what can and what can't be routed in our company management network (keep production and management separated)).

For firewalls, which are not hosted in our DC, but e.g. in customer's own network, the Panorama has public NAT IP, but it's not allowed to be opened from the internet, hence direct connection (from management interface of the firewall) through the is not possible. All the other firewalls, which we are managing (and do not have management interface directly in the same, separate, management network as Panorama) don't have this issue, because default routing towards the Panorama would go through the firewall anyway, so it's not an issue to catch it and route it into the tunnel.

So, my issue here is that since management interface of the firewall is a public IP (restricted to specific jump/VPN IP ranges) and the service traffic isn't routed through the firewall dataplane at all (service traffic like DNS, NTP, PAN services, etc. are going through some other 3rd party/ISPs firewalls), I had to use something (in this case loopback) to force it go through the firewall.

"A great design principle is simplicity as complexity decreases availability."

I agree with you that simplicity is the best, but I couldn't actually think of anything better than this considering situation I've been put into. The only other approaches, which I was thinking of are:

1) using service routes won't let us push Panorama config into passive node (if what I've read what true, that only local config can be synced, but not the one pushed from Panorama)

2) there might be a plan in the future to change the management interface IPs to something non-public, which would solve the current issue and that the management traffic would flow through the firewall, but that's something which is most likely not gonna be in a near future

So, TLDR: I can't put into the firewall's config the public NAT IP of Panorama as it's not allowed to be directly opened from the internet and since the management traffic (services) isn't routed through PA itself, but through some 3rd party ISPs, I can't really make it to go into the tunnel other than what I've tried and what failed for me -> to use firewall's own Loopback interface as Panorama server, then DNAT it and send into the tunnel.

Hopefully I tried to make the picture a little bit clearer now, what my limitations are. If it still doesn't make sense, then I'll try to explain it further (just trying to avoid any sensitive info).

Thank you.

Antonin