default route for management traffic

[BoomShakaLak]

We have an FTD managed by FMC on data interfaces.  The FTD device is not able to reach the internet via the management interface and I am assuming it has to do with the following:

FTD:~$ route | grep 169.254.
default 169.254.1.1 0.0.0.0 UG 0 0 0 tun1  <--- Default route is pointing to tun1 and not tap_nlp
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun1
169.254.1.0 0.0.0.0 255.255.255.248 U 0 0 0 tap_nlp

Has anyone seen this and knows how to fix this without breaking management access in the process.

[MHM Cisco World]

No friend 

Interconnect mgmt interface to any data interface' config both in same subnet 

Then config mgmt interface to use data interface as GW 

Config NAT in ftd to NATing traffic

That what you need 

MHM

[BoomShakaLak]

NAT and access rules (permitting all traffic from management subnet until this is sorted) are in place. If I compare the configuration to a site where everything is working as expected I see this:

ftd2:~$ route | grep 169.254.
default 169.254.1.1 0.0.0.0 UG 0 0 0 tap_nlp  <--- interface associated with correct subnet interface
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tun1
169.254.1.0 0.0.0.0 255.255.255.248 U 0 0 0 tap_nlp  <--- subnet

Is changing this in the problem FTD as simple as adding the route in expert mode / linux shell?

I would agree that adding a static route would most probably solve the issue, but it will not solve the underlying issue as to why this has happened.  I would much rather solve the underlying issue than just put a band-aid on it.

[BoomShakaLak]

From this output it is clear that the issue is the incorrect inter face being referenced in the routing table

> sftunnel-status-brief

PEER:aaa.bbb.ccc.ddd
Peer channel Channel-A is valid type (CONTROL), using 'tap_nlp', connected to 'aaa.bbb.ccc.ddd' via '169.254.1.3'
Peer channel Channel-B is valid type (EVENT), using 'tap_nlp', connected to 'aaa.bbb.ccc.ddd' via '169.254.1.3'

[Marvin Rhoads]

What does the output of "show network" tell you?

We should never need to manipulate the routing table from the expert cli (Linux shell).

[BoomShakaLak]

So, I opened a TAC case on this and they claim that we are hitting the below bug.  I disagree on this as we have not lost connection to the management interface.  We have several other installations where we have the same setup (different hardware though) and each time we have had to specify what traffic is to be sent via the management interface. 

According to the bug notes, the solutions are to either upgrade to version 7.4.2 or delete and configure the management interface IP.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwj55081

Show network shows correct information, but when we inspect the routing table in expert mode we see that the route is pointing to wrong internal interface.

> show network
===============[ System Information ]===============
Hostname : FTD
DNS Servers : 10.1.5.33
10.1.5.22
DNS from router : enabled
Management port : 8444
IPv4 Default route
Gateway : data-interfaces

==================[ management0 ]===================
Admin State : enabled
Admin Speed : sfpDetect
Operation Speed : 1gbps
Link : up
Channels : Management & Events
Mode : Non-Autonegotiation
MDI/MDIX : Auto/MDIX
MTU : 1500
MAC Address : BB:19:2B:9B:B3:00
----------------------[ IPv4 ]----------------------
Configuration : Manual
Address : 10.0.2.2
Netmask : 255.255.255.0
Gateway : 169.254.1.1

IPv4 Static route
Destination : 10.1.5.0
Gateway : 10.0.2.1
Netmask : 255.255.255.0

Destination : 10.1.1.0
Gateway : 10.0.2.1
Netmask : 255.255.255.0

----------------------[ IPv6 ]----------------------
Configuration : Disabled

===============[ Proxy Information ]================
State : Disabled
Authentication : Disabled

======[ System Information - Data Interfaces ]======
DNS Servers :
Interfaces : Ethernet1/1

==================[ Ethernet1/1 ]===================
State : Enabled
Link : Up
Name : Outside
MTU : 1500
MAC Address : BB:19:2B:BB:B3:1B
----------------------[ IPv4 ]----------------------
Configuration : Manual
Address : 6.1.1.2
Netmask : 255.255.255.248
Gateway : 6.1.1.1
----------------------[ IPv6 ]----------------------
Configuration : Disabled

[Marvin Rhoads]

Have you tried reconfiguring the network to specify the correct gateway address? 169.254.1.1 is an APIPA and obviously incorrect.