<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: management vs data interface for FTD management in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010420#M1108678</link>
    <description>&lt;P&gt;Good point. Shouldn't "configure manage add" put entries into iptables as "configure ssh-access-list" does? Can you verify?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 31 Jan 2024 16:08:24 GMT</pubDate>
    <dc:creator>tvotna</dc:creator>
    <dc:date>2024-01-31T16:08:24Z</dc:date>
    <item>
      <title>management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5009523#M1108630</link>
      <description>&lt;P&gt;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?&lt;/P&gt;&lt;P&gt;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?&lt;/P&gt;&lt;P&gt;TIA,&lt;BR /&gt;Diego&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 00:47:47 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5009523#M1108630</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2024-01-31T00:47:47Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5009613#M1108631</link>
      <description>&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 03:28:59 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5009613#M1108631</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2024-01-31T03:28:59Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010085#M1108640</link>
      <description>&lt;P&gt;using data interface is for connect FMC to FTD&amp;nbsp;&lt;BR /&gt;if you using mgmt and INside as GW of mgmt and connect FMC to mgmt, then the traffic will pass through FTD policy&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;BR /&gt;if you using OUTside data interface to connect to FMC then the traffic will pass without any inspect by FTD policy&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="Screenshot (100).png" style="width: 999px;"&gt;&lt;img src="https://community.cisco.com/t5/image/serverpage/image-id/209270i22E11792D0F749AA/image-size/large?v=v2&amp;amp;px=999" role="button" title="Screenshot (100).png" alt="Screenshot (100).png" /&gt;&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;Note:- the mgmt have RIB totally separate than data RIB&lt;/P&gt;
&lt;P&gt;MHM&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 12:52:38 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010085#M1108640</guid>
      <dc:creator>MHM Cisco World</dc:creator>
      <dc:date>2024-01-31T12:52:38Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010116#M1108643</link>
      <description>&lt;P&gt;&lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/317180"&gt;@tato386&lt;/a&gt; I agree with &lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/326046"&gt;@Marvin Rhoads&lt;/a&gt; I would not use the management interface for remote site FTDs, use the outside data interface for mgmt purposes.&lt;/P&gt;
&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 09:53:29 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010116#M1108643</guid>
      <dc:creator>Rob Ingram</dc:creator>
      <dc:date>2024-01-31T09:53:29Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010359#M1108663</link>
      <description>&lt;P&gt;I agree with&amp;nbsp;&lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/326046"&gt;@Marvin Rhoads&lt;/a&gt;&amp;nbsp;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.&lt;/P&gt;&lt;P&gt;The plan would be to connect both interfaces via switch (or DMZ VLAN) directly to the ISP similar to how&amp;nbsp;&lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/97036"&gt;@Rob Ingram&lt;/a&gt;&amp;nbsp;mentioned.&amp;nbsp; In this manner I would not have to worry about any FTD functions interfering with management traffic to/from FMC as &lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/1065752"&gt;@MHM Cisco World&lt;/a&gt;&amp;nbsp;mentioned.&lt;/P&gt;&lt;P&gt;I would however like to apply some kind of ACL to the management interface.&amp;nbsp;&amp;nbsp;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.&amp;nbsp; Seems like there is very little to nothing that can be done to mgmnt interface on the GUI.&amp;nbsp; Hopefully I can add said ACL via CLI.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 14:48:24 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010359#M1108663</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2024-01-31T14:48:24Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010364#M1108665</link>
      <description>&lt;P&gt;&lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/317180"&gt;@tato386&lt;/a&gt; for the management interface use "&lt;SPAN class="ph synph"&gt;&lt;SPAN class="keyword kwd"&gt;configure ssh-access-list&lt;/SPAN&gt;&lt;/SPAN&gt; &amp;lt;network&amp;gt;" from the FTD CLI.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 14:55:59 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010364#M1108665</guid>
      <dc:creator>Rob Ingram</dc:creator>
      <dc:date>2024-01-31T14:55:59Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010390#M1108673</link>
      <description>&lt;P&gt;Are there any other open ports on this interface?&amp;nbsp; How does FMC traffic access the FTD?&amp;nbsp; 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.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 15:25:05 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010390#M1108673</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2024-01-31T15:25:05Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010400#M1108676</link>
      <description>&lt;P&gt;Fastpath you need for this traffic since it ssl encrypted traffic.&lt;/P&gt;
&lt;P&gt;MHM&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 15:33:45 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010400#M1108676</guid>
      <dc:creator>MHM Cisco World</dc:creator>
      <dc:date>2024-01-31T15:33:45Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010404#M1108677</link>
      <description>&lt;P&gt;&lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/317180"&gt;@tato386&lt;/a&gt; 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.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 15:42:05 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010404#M1108677</guid>
      <dc:creator>Rob Ingram</dc:creator>
      <dc:date>2024-01-31T15:42:05Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010420#M1108678</link>
      <description>&lt;P&gt;Good point. Shouldn't "configure manage add" put entries into iptables as "configure ssh-access-list" does? Can you verify?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 16:08:24 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010420#M1108678</guid>
      <dc:creator>tvotna</dc:creator>
      <dc:date>2024-01-31T16:08:24Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010423#M1108679</link>
      <description>&lt;P&gt;&lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/1065752"&gt;@MHM Cisco World&lt;/a&gt;&amp;nbsp;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&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 16:16:44 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010423#M1108679</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2024-01-31T16:16:44Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010424#M1108680</link>
      <description>&lt;P&gt;the open tcp/8305 might be a problem when auditors scan public IP for vulnerabilities.&amp;nbsp; They are quite picky at times.&amp;nbsp; 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&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 16:21:58 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010424#M1108680</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2024-01-31T16:21:58Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010427#M1108681</link>
      <description>&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 16:23:16 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010427#M1108681</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2024-01-31T16:23:16Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010435#M1108682</link>
      <description>&lt;P&gt;so does this mean that maybe there is a "defacto" ACL that will filter tcp/8305 to defined managers only?&amp;nbsp; that would be great.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 16:31:01 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010435#M1108682</guid>
      <dc:creator>tato386</dc:creator>
      <dc:date>2024-01-31T16:31:01Z</dc:date>
    </item>
    <item>
      <title>Re: management vs data interface for FTD management</title>
      <link>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010441#M1108685</link>
      <description>&lt;P&gt;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.&lt;/P&gt;</description>
      <pubDate>Wed, 31 Jan 2024 16:38:51 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/management-vs-data-interface-for-ftd-management/m-p/5010441#M1108685</guid>
      <dc:creator>Marvin Rhoads</dc:creator>
      <dc:date>2024-01-31T16:38:51Z</dc:date>
    </item>
  </channel>
</rss>

