Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

NAT MGMT IP to the internet

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

NAT MGMT IP to the internet

L3 Networker

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

 

 

1 accepted solution

Accepted Solutions

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.

View solution in original post

13 REPLIES 13

Cyber Elite
Cyber Elite

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.

L3 Networker

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.

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.

L3 Networker

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.

Cyber Elite
Cyber Elite

Hello,

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

Regards,

Cyber Elite
Cyber Elite

@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. 

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.

@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.

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! 😉

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 😉

L3 Networker

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.


@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...

L3 Networker

yup.. using SNMPv3.

  • 1 accepted solution
  • 3006 Views
  • 13 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!