NAT MGMT IP to the internet

[PA_nts]

Hi All,

Before i get shot down.. yes I know this is not recommended/best practice, but was wondering if even possible as had this conversation with a colleague the other day.

A client has a pair of HA PAN FWs (no panorama) as perimeter FWs

Management network is setup on 192.168.1.0/24 vlan. (separate from LAN)

Can you manage these FWs over the internet without IPSEC. thus, can the mgmt IPs be natted to 2x diff public IPs? then restricted based on public SRC ip etc

If so, how would the nat be setup if there is no zone for mgmt int defined?

to add this needs to reach both FWs individually so a mgmt profile on public Interface wont be enough..

thanks in adv

[OtakarKlier]

Hello,

Honestly I do this but lock down the security policy to only my known good IP's or ranges, ie data center A IP can get to data center B devices and vice versa. Several things you should do.

Set you 'Permitted IP's.' 

Set a policy that is very specific of both source and destination.

https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-networking-admin/configure-interfaces/use-inter...

Hope this helps.

[PA_nts]

to add, this is natting on the mgmt-plane and not the data-plane. so i am trying ti understand if this is even supported on NGFW. to nat the management interface IP's (RFC1918) to  public IP's via untrust. does not seem doable.

[mb_equate · Accepted solution]

Because mgmt and dataplanes are separate, the mgmt interface has its own route table and cannot forward via a dataplane interface. As long as the interface has a route to the internet (i.e. its default gateway can route to the firewall's LAN interface), you treat it as any other IP on the network in your policy and build your rules accordingly. In small environments, where this is absolutely necessary, I tend to put the mgmt interface on the same VLAN as the firewall inside (dataplane) interface and make that the default gateway for mgmt.

[PA_nts]

cool thanks all.

managed to get it working in a lab - my management interface sits on a separate vlan, and i have a route van lan zone on the FW to that mgmt vlan,  so was able to do a nat from wan to lan zones which worked.. initially tried to nat directly to the management plane but as mb_equate posted, this is not possible..

anyways.. happy fw-ing.

[OtakarKlier]

Hello,

Plug your management interface into a port on the PAN on a different vlan/zone and secure it and then NAT that.

Regards,

[BPry]

@PA_nts,

While what @OtakarKlier mentioned works perfectly fine, I'm personally wondering why you wouldn't just assign a custom interface-management-profile to your untrust interface with the same heavily restricted permitted-ip list assigned.

That would functionally accomplish the same thing and doesn't demand that you're consuming additional dataplane interfaces to get the same functionality. Just not seeing the benefit of that setup unless you absolutely need to allow ICMP requests on your untrust interfaces for some reason. 

[mb_equate]

I think the elitists are missing the point 😉

With HA @OtakarKlier's approach would only provide access to the active device even if you did this on both, as there is no path from the active device to standby management. @BPry's method again works great for standalone devices (I'm deploying this as we speak) but again will not provide access to the standby device in an HA pair other than what you can do from the active (shared config sync, content sync, HA op commands etc.), as the standby device does not have an IP on the outside network.

On a standby device in an HA pair, only the mgmt interface is reachable on the network. If you want to manage both devices without a VPN, you must connect mgmt on both appliances to a separate device (router/switch) to allow your connection through the active firewall to reach standby mgmt. They don't have to be on the same VLAN, as long as they are reachable from the inside/trust/LAN interface.

1337.

[BPry]

@mb_equate You expect me to actually fully read something instead of skimming it, now who’s being unreasonable 😉

In that case I’d actually still point towards the method thay i mentioned above being viable and I’d stand by it with a bit more context.

While you will only directly have access to the active unit in the HA pair, there’s nothing stoping you from using SSH to get to the passive member from the CLI on the active device. You’d have a management connection you could still SSH into directly from your active firewall to do anything you needed bar accessing the GUI without using a jumpbox.

Okay i have to edit this because even after you called my lack of reading the question out, I still didn’t actually go fully read @PA_nts original post.

@PA_nts your client is putting way too many restrictions on this. You can’t use a tunnel for access and you can’t make your MGMT VLAN routable? Something has to give there; you either live with only having access to a single device at a time, you make MGMT accessible, or you do a very extended version of what @OtakarKlier already mentioned and was likely alluding too to begin with.

The only way this works with your limitations are expanding on what @OtakarKlier mentioned already. You’ll need to sacrafice the MGMT port on both to have access to the passive unit with these restrictions and plug it into a dataplane port and NAT it or isolate it into a routable zone.

Importantly this requires that you enable a management profile on the untrust interface (or any other public interface) as well as that additional MGMT connection we just plugged in from each firewall peer. One public IP becomes the active firewall and the other (or a port if you dont have IPs to spare) becomes the passive unit. 

This would work given your limitations, but it’s very dumb and adds comolexity. The client should just be willing to make some concessions here.

[mb_equate]

I had to read the OP again...

---

@PA_nts wrote:

to add this needs to reach both FWs individually so a mgmt profile on public Interface wont be enough..

It depends on what we mean by 'manage'; our SOC requires machine-based access to monitor, backup and remotely admin which means the management toolset must reach all devices to meet SLAs. Having said that, we deploy an appliance (Linux jumpbox) on the inside that punches an outbound SSL VPN through which the toolset and admins can reach the devices internally, the only NAT required is outbound (DIPP).

I'm often busy thinking of what to say next rather than listening to (reading) what others have to say, it's a common problem with us A-types! 😉

[mb_equate]

I see what you did there... I think in @PA_nts case the mgmt interface connects to a separate router/switch which can reach the inside interface, so a Frankenstein solution can be avoided.

I had a dog called Pants once, thanks for the memories 😉

[PA_nts]

Yes just to clarify and should maybe have added this to my original post... i have a SNMP poller on the untrust internet that needs to poll both my Active AND Standby FW on snmp/ping for uptime monitoring etc (without IPSEC).. a mngmt profile wont work as only one device is reachable from internet. as such the solution i did was as follows:

example:

Active FW1 mgmt IP 192.168.0.1 / public IP 1.2.3.4/29

Standby FW2 mgmt IP 192.168.0.2 / public IP 1.2.3.5/29

1. add a static route to my mngmt vlan via my TRUST Zone (10.0.0.0/24) to point 192.168.1.1/24 towards my LAN gateway behind my TRUST zone..

2. add a static nat with bi-direction (to send traps) enabled for my poller public IP (5.5.5.5) towards my active FW mgmt int IP (1.2.3.4 / 192.168.0.1)

3. add a static nat with bi-direction (to send traps) enabled for my poller public IP (5.5.5.5) towards my standby FW mgmt int IP (1.2.3.5 / 192.168.0.2)

4. Added Security rules to restrict based on source/dest/application

so in essence - should be treated like a normal nat config.. as long as the FW has a route to the dest network ie mgmt vlan via the dataplane as in my case
What i did learn from this is that you cannot do a nat directly to the mgmt interface because of the limitation between the dataplane and the managementplane as per MB_equate's post.

thanks all for the responses.

[mb_equate]

---

@PA_nts wrote:

i have a SNMP poller on the untrust internet

---

Oof! Just make sure you're using v3 unless you don't mind sharing secrets...

[PA_nts]

yup.. using SNMPv3.