Firepower 1150 question

[GatLMCO]

Host-A can ping firepower from inside to outside in range (10.10.10.0/25) but not in range of (10.10.10.128/25). If wild card 'ip route' at core-switch is set to follow (10.10.10.10.128/25) then Host-A can ping all ip's in that range. But all ip's in range from 1-126 become unreachable. what could possibly cause this toggling problem?

[Flavio Miranda]

@GatLMCO 

 Seems to be a route problem. Why dont you use 10.10.10.0/24 in the route config?

[GatLMCO]

I think I tried this, since it opens network to all 1-254 and it did not help. The question is if perhaps in making that change on the FW there will be a need to do the same on all associated connected devices?
thanks

[Flavio Miranda]

If the firewall is the gateway for 10.10.10.0/25 and 10.10.10.128/25, you probably have an interface or interface vlan on this networks, right?

 From routing point of view, using the mask /24 should be enaough to fix it. If the firewall have interface on those networks, it will know how to send the traffic to the specific host.

 Now, if the firewall does not have interface on those networks then the firewall also must have routes pointing to those networks and on this case, yes, you should also use /24 or add two static network with /25

[MHM Cisco World]

Can you more elaborate 

MHM

[GatLMCO]

I would elaborate except that is very much the issue I am having. ACLs are inside to outside and outside to inside with nat exempt. The setup appears simple enough, but result complicated. I ran packet tracer from outside to inside on non-reachable ips and there seems to be some drop. Like 'snp_fp_tracer_drop' in another instance drop reason (no-v4-adjacency) no valid v4 adjacency. Check arp table. Checked arp table, but the adjacency ip is shown.
thanks

[MHM Cisco World]

Sorry can you share the topology if you please 

MHM

[GatLMCO]

Thanks for your response,

-Just so you understand, the toggling only happens if I manually change on core switch wild card route. For instance remove/replace 'ip route 0.0.0.0 0.0.0.0 10.10.10.124' with 'ip route 0.0.0.0 0.0.0.0 10.10.10.145' then only able to ping those ip's on upper subnet.

There was a suggestion to try 10.10.10.0/24, and I have tried that in the past and that did not correct the problem. So now the configuration is back to normal. Crazy normal maybe, but no ip misconfig that might give way to overlapping ip's or vlan mismatches.

I like your suggestions for 'incorrect longest prefix match (lpm)' and as such that could be the case. Assuming that were true, then how would you ensure that all traffic destined for 10.10.10.0/25 and 10.10.10.128/25 gets through the trunk and reaches the firewall in any direction?

[MHM Cisco World]

Still waiting topolgy 

MHM

[GatLMCO]

If the firewall is the gateway for 10.10.10.0/25 and 10.10.10.128/25, you probably have an interface or interface vlan on this networks, right?

* Yes, that is correct the core switch has a 'L3 vlan interface' that points towards 10.10.10.0/25 and 10.10.10.128/25 that splits vlan to two subnets on those networks.

From routing point of view, using the mask /24 should be enaough to fix it. If the firewall have interface on those networks, it will know how to send the traffic to the specific host.

* As I thought as well, using mask /24 on firewall could fix but it does not. Strange and confusing. The core swihas a route 'ip route 0.0.0.0 0.0.0.0 10.10.10.124 that points to firewall inside sub interfaces.

Now, if the firewall does not have interface on those networks then the firewall also must have routes pointing to those networks and on this case, yes, you should also use /24 or add two static network with /25

* The firewall has a ½ interface that is sub interface into multiple vlan's with respective ip's. And in that case two static networks /25.
Thanks

[Flavio Miranda]

@GatLMCO 

 if you have a route "ip route 0.0.0.0 0.0.0.0 10.10.10.124" on the core. all the traffic will be sent to 10.10.10.124, which is first network.  You need to have specific routes on the core instead.

ip route 10.10.10.0 255.255.255.128  <gateway>

ip route 10.10.10.128  255.255.255.128  <gateway>

[GatLMCO]

Yes, as I thought so too. So I tried, the problem is the firewall is not responsive to it. On that flip side of that, if I toggle the route on core switch to 'ip route 0.0.0.0 0.0.0.0 10.10.10.145' then firewall only response to upper subnet ip's in range of 126-254.

[vishalbhandari]

This toggling issue is likely caused by an incorrect routing configuration that is leading to overlapping or conflicting routes between the two subnets (10.10.10.0/25 and 10.10.10.128/25). Here's a breakdown of the potential causes:

1. Incorrect Longest Prefix Match (LPM): When you configure a wildcard route, the router follows the longest prefix match rule, meaning it chooses the most specific route to forward traffic. By adding the wildcard route for 10.10.10.128/25, the router now routes all traffic matching that range, but this might override the routing for 10.10.10.0/25. As a result, traffic destined for IPs in the 10.10.10.0/25 range is being misrouted or not routed at all.

2. Subnet Overlap or Improper Route Summarization: If there’s a routing table entry for 10.10.10.0/24, it might be overriding your specific /25 routes. Adding 10.10.10.128/25 could cause the router to prefer the newly defined route for 10.10.10.128/25, making the lower half (10.10.10.1-10.10.10.126) unreachable due to this route mismatch.

3. Routing Table Conflicts: Check the core-switch routing table for both direct and static routes. There might be a static route incorrectly pointing to 10.10.10.128/25 while the dynamic or connected routes are properly defined for 10.10.10.0/25. This would cause traffic to follow the wrong path depending on the more specific or less specific route.

Solutions:

• Check for Overlapping Routes: Look for any static or dynamic routes that might be conflicting between the two ranges.
• Use Route Summarization Carefully: If you are summarizing routes or using wildcards, ensure that the summary doesn’t inadvertently overlap or override more specific routes.
• Verify Route Preference and Administrative Distance: Make sure the routes for both subnets have the correct administrative distance and metrics so that the router prefers the correct paths without causing toggle issues.

In short, it seems like a routing conflict or improper route summarization is causing the router to either forward all traffic to one side or the other, depending on the wildcard routing configurations.