management vs data interface for FTD management

[tato386]

I am planning on setting up a couple FTDs that will talk to their FMC via a public IP. From what I can see I can use any interface for management as long as it is correctly configured. Since one of the data interfaces is also the "outside" interface it seems logical to just use this IP/interface and leave the management interface unused and this is the way I am leaning. However, how about if I use a second public IP and assign it directly to the management interface? Is there any positive or negatives associated with this approach?

I think in the past I have seen situations where FTD doesn't allow having two interfaces on the same subnet. What about routing for the management interface which also seems tricky sometimes? Does each interface need its own default route, or do they share a routing table because they are on the same subnet?

TIA,
Diego

[Marvin Rhoads]

You can have the management interface address in the same subnet as a data interface. It uses a separate routing table based on the default gateway set in the "configure network..." command. I don't see any particular advantage to that however and one could argue it adds unnecessary complexity. The remote FMC is presumably behind a firewall so it will need to allow incoming connections on tcp/8305 for the sftunnel management process to communicate inbound from the remote managed devices.

[MHM Cisco World]

using data interface is for connect FMC to FTD 
if you using mgmt and INside as GW of mgmt and connect FMC to mgmt, then the traffic will pass through FTD policy 

if you using OUTside data interface to connect to FMC then the traffic will pass without any inspect by FTD policy 

Note:- the mgmt have RIB totally separate than data RIB

MHM

[Rob Ingram]

@tato386 I agree with @Marvin Rhoads I would not use the management interface for remote site FTDs, use the outside data interface for mgmt purposes.

In the past some customers I've worked with connected the outside and mgmt interfaces to a switch, with both interfaces having public IP addresses, not feasible in some circumstances. On the other hand if you connect the mgmt interface to the inside network, you have to somehow pre-prep the firewall to route the mgmt traffic through the inside interface of the remote and rely on the traffic not being dropped by the ACP. Another scenario that I heard some partners suggest in the past was connect mgmt interface to a different circuit that wasn't routed through the FTD.

[tato386]

I agree with @Marvin Rhoads that using the management interface adds complexity but what I find attractive is that it eliminates the risk of "sawing off the limb you are standing on" if I accidently deploy a bad rule, NAT, policy or whatever to the FTD which causes me to get cut off from managing the FTD from the outside data interface.

The plan would be to connect both interfaces via switch (or DMZ VLAN) directly to the ISP similar to how @Rob Ingram mentioned.  In this manner I would not have to worry about any FTD functions interfering with management traffic to/from FMC as @MHM Cisco World mentioned.

I would however like to apply some kind of ACL to the management interface.  In the GUI I see an option for adding ACL to a data interface that is being used for management but not for management interface itself.  Seems like there is very little to nothing that can be done to mgmnt interface on the GUI.  Hopefully I can add said ACL via CLI. 

[Rob Ingram]

@tato386 for the management interface use "configure ssh-access-list <network>" from the FTD CLI.

[tato386]

Are there any other open ports on this interface?  How does FMC traffic access the FTD?  I was thinking of using something like a permit all for my FMC public IP(s) followed by deny all after that so that no other access is allowed to the mgmnt interface.

[MHM Cisco World]

Fastpath you need for this traffic since it ssl encrypted traffic.

MHM

[tato386]

@MHM Cisco World the management interface will be connected directly to the public Internet and as such no rules will be needed as traffic to/from this interface will not be processed by the FTD

[Rob Ingram]

@tato386 the FTD also listens on tcp/8305 for communication to the FMC via the secure sftunnel. I am not aware this can be restricted tbh.

[tvotna]

Good point. Shouldn't "configure manage add" put entries into iptables as "configure ssh-access-list" does? Can you verify?

[Marvin Rhoads]

Yes, sftunnel.conf is updated by "configure manager..." commands. Only when a manager has been defined there will the FTD device accept incoming tcp/8305 traffic to establish the channels for management and eventing.

[tato386]

so does this mean that maybe there is a "defacto" ACL that will filter tcp/8305 to defined managers only?  that would be great.

[Marvin Rhoads]

I have not tested it personally but I believe tcp/8305 may continue to respond to a scan (not sure if the TCP 3-way handshake will actually complete). However the listening process (sftunnel daemon) will definitely not allow establishment of a connection to an address not registered as a manager.

[tato386]

the open tcp/8305 might be a problem when auditors scan public IP for vulnerabilities.  They are quite picky at times.  I guess I can use an ACL on the switchport if need be but I would much prefer to do it straight on the mgmnt interface