Mangement interface

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Mangement interface

L4 Transporter

Hi,

 

i have distribution , core ,access layer 

data center are connected to core  , Need to setup data center firewall 

In data center we are  following 192.168.0.0 /16 

in distribution 10.0.0.0/8 

So what should be my  managemnt interface ip address . 

I should choose one of the  datacenter network ip address ?

 

Thanks 

 

1 accepted solution

Accepted Solutions

@simsim,

So I've deployed enough firewalls to see every possible management interface deployment I think you could possibly have, from amazing isolated MGMT networks which have no connection to the outside world and are trully isolated to the flat network just adding the management interface in with everything else.

There's a lot of different ways you can do this, and what method you use is going to be determined by your companies risk assessment and regulatory requirements. A lot of the DOD, healthcare, and financial sector will actually have dedicated management networks which isn't allowed to be accessed, or access, anything not residing in said management network. You would have a dedicated management computer, and all your management tasks would be carried out from that machine. 

A more common deployment is when companies will use a separate VRF (or just a VLAN depending on setup) and just logically separate out a management network on their existing equipment and highly control what and who is allowed to communicate to/from this zone/vlan. Sometimes you have a dedicated management host in this scenario, but more often you simply have tightly controlled access from specific machines and people allowed access to these resources. In this scenario no traffic should be able to communicate to or from one of your management hosts without it being logged and recorded by something. 

The most common deployment that you'll see that actually follows best practices is simply securing the management interface via the permitted-ip restrictions. IE: You're setting up a list of hosts that can communicate to the firewalls management interface, everything else will simply be denied access.

Lastly, sadly, if you look at it from a pure numbers standpoint the most common deployment across all PAN environments is when the organization really isn't doing anything to secure the management interface. They aren't limited access to it, or its in the same l2 networks as everything else on the same vlan, and they haven't setup any restrictions outside of username/password security. Don't do this, as it's incredibly insecure. You should at the absolute minimum setup permitted-ips so that the management interface can only communicate to hosts that you've expressly specified within your configuration.

 

 

As to your earlier concern about someone creating a policy that locked you out of your management interface, as @Brandon_Wertz mentioned this really shouldn't be possible. Even if you have the management traffic traversing the firewall within your network, you should still be able to configure a host on the same vlan/vrf and access the management interface. The management interface on your firewall is completely separate from your dataplane, so the only way you can really lock yourself out of it is if you mess up the permitted-ip configuration and you somehow enter the wrong IP information here and create a situation where you physically need to configure a devices NIC and do a device -> management interface direct connection or access the device from the console port to regain access and correct the permitted-ip configuration. 

 

Hopefully that helps, but generally your management interface or management network as a whole rather is going to depend a lot on your organization and its requirements and regulatory bodies. 

View solution in original post

9 REPLIES 9

Cyber Elite
Cyber Elite

@simsim,

Generally speaking your management network would be completely separate from your other networks, or at the very least an isolated VLAN. If you don't have anything like that setup I would suggest doing so, but in the end it really wouldn't matter in your environment from the sounds of it. You would just want to really make sure that you secure it and ensure that you have permitted-ips configured so that you're limiting access to the management interface.

Hi,

Thank you for the reply 

"Generally speaking your management network would be completely separate from your other networks, or at the very least an isolated VLAN "

When you  say completely separate from other network ,How the routing between  other network for access.

Can you give an example 

Thanks 

 

Hi @simsim ,

 

I am fully agreed with @BPry . You should secure your device management access as much as possible. When you create isolated MGMT VLAN, the access to devices will be only through that VLAN in other words Administrator would be accessing it from that VLAN only. And rest network would be isolated from that VLAN. Now if its not possible for you, you can at least permit access management interface from required IP address/network only. Same as mentioned by @BPry .This will help to restrict access to management interface from other networks.

M

hI @BPry   @SutareMayur 

Thanks for the reply . I can a create a separate vlan .  when you say an isolated vlan  what about the  inter vlan routing . 

It would be great if you give a  diagram 

Thanks


@simsim wrote:

hI @BPry   @SutareMayur 

Thanks for the reply . I can a create a separate vlan .  when you say an isolated vlan  what about the  inter vlan routing . 

It would be great if you give a  diagram 

Thanks


Routing between routers is accomplished via routing protocols which you run in your network, either OSPF, BGP, EIGRP or something else.  Networks (VLANs) owned by the respective routers are shared via those routing protocols.

 

You have have a single router, for your DC, which controls the routing for all your networks (VLANs) including the management network or you can chose to break that apart.  Given what you've shared thus far, it seems a simpler solution might be easier for you to manage and implement.  That said as @BPry suggested the simplest and best way for you to apply security to your FW management is to apply "allowed IPs" that are allowed to communicate with the management interface (Seen in the right hand of the screenshot.)

 

FW_MGMT.png

Hi @Brandon_Wertz 

Currently I am using the simple solution as you shown in the screen shot .That is permitted ip . 

I am trying to learn something new  . 

I can just creat  a vlan in dc  . 

But my worry is if someone put a deny policy and he can  deny management network also ?

Thanks

 


@simsim wrote:

Hi @Brandon_Wertz 

Currently I am using the simple solution as you shown in the screen shot .That is permitted ip . 

I am trying to learn something new  . 

I can just creat  a vlan in dc  . 

But my worry is if someone put a deny policy and he can  deny management network also ?

Thanks

 


Under normal circumstances you really can't create security policy which will block access to the management interface and prevent access.

Thanks @Brandon_Wertz  @BPry @SutareMayur 

It would be great if you experts  can share your setup regarding management interface 

 

@simsim,

So I've deployed enough firewalls to see every possible management interface deployment I think you could possibly have, from amazing isolated MGMT networks which have no connection to the outside world and are trully isolated to the flat network just adding the management interface in with everything else.

There's a lot of different ways you can do this, and what method you use is going to be determined by your companies risk assessment and regulatory requirements. A lot of the DOD, healthcare, and financial sector will actually have dedicated management networks which isn't allowed to be accessed, or access, anything not residing in said management network. You would have a dedicated management computer, and all your management tasks would be carried out from that machine. 

A more common deployment is when companies will use a separate VRF (or just a VLAN depending on setup) and just logically separate out a management network on their existing equipment and highly control what and who is allowed to communicate to/from this zone/vlan. Sometimes you have a dedicated management host in this scenario, but more often you simply have tightly controlled access from specific machines and people allowed access to these resources. In this scenario no traffic should be able to communicate to or from one of your management hosts without it being logged and recorded by something. 

The most common deployment that you'll see that actually follows best practices is simply securing the management interface via the permitted-ip restrictions. IE: You're setting up a list of hosts that can communicate to the firewalls management interface, everything else will simply be denied access.

Lastly, sadly, if you look at it from a pure numbers standpoint the most common deployment across all PAN environments is when the organization really isn't doing anything to secure the management interface. They aren't limited access to it, or its in the same l2 networks as everything else on the same vlan, and they haven't setup any restrictions outside of username/password security. Don't do this, as it's incredibly insecure. You should at the absolute minimum setup permitted-ips so that the management interface can only communicate to hosts that you've expressly specified within your configuration.

 

 

As to your earlier concern about someone creating a policy that locked you out of your management interface, as @Brandon_Wertz mentioned this really shouldn't be possible. Even if you have the management traffic traversing the firewall within your network, you should still be able to configure a host on the same vlan/vrf and access the management interface. The management interface on your firewall is completely separate from your dataplane, so the only way you can really lock yourself out of it is if you mess up the permitted-ip configuration and you somehow enter the wrong IP information here and create a situation where you physically need to configure a devices NIC and do a device -> management interface direct connection or access the device from the console port to regain access and correct the permitted-ip configuration. 

 

Hopefully that helps, but generally your management interface or management network as a whole rather is going to depend a lot on your organization and its requirements and regulatory bodies. 

  • 1 accepted solution
  • 5047 Views
  • 9 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!