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