ARP issue on Firepower firewall

Started by jericho, December 01, 2017, 09:45:52 AM

Previous topic - Next topic

jericho

Hi gents,

Wondering if anyone can point me in the right direction on this one.

One of my customers has just had a firewall upgrade to some nice shiny new FP2110 firewalls. Since the upgrade there has been some minor weirdness with traffic being dropped.

Looking at the ARP tables on the FW edge, it looks as though the FP boxes are sending ARP packets for IP addresses that don't belong to them.


10.10.5.200      00:01:12  707d.b912.fa4d  Vlan5         
10.10.5.201      00:01:12  707d.b912.fa4d  Vlan5         
10.10.5.202      00:01:12  707d.b912.fa4d  Vlan5         
10.10.5.203      00:10:58  707d.b912.fa4d  Vlan5         
10.10.5.204      00:05:07  707d.b912.fa4d  Vlan5         
10.10.5.205      00:13:51  707d.b912.fa4d  Vlan5         


I've cleared the ARP cache, but they repopulate. I've had a look inside the FP management interface and I can see that within the NAT configuration there is an option to disable proxy ARP on the destination interface.

Would that sound a reasonable place to start looking at this?

Thanks in advance for any help.

Cheers

J


deanwebb

Yeah, have a look at that proxy ARP stuff and maybe also check documentation about that feature.

But traffic being dropped? I'd check the ruleset. Did something change in the rules with the upgrade? If it's a new firewall vendor, maybe the rules didn't migrate 100% accurately. Because, in a normal situation, you want the following to be true:

:notthefirewall:
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

jericho

Thanks,

The upgrade was from Checkpoint (which I kind of know my way around) to Firepower (never seen one before). I know in the old IPSO firewalls they used to use Proxy ARP as part of the NAT process, but I thought they had discontinued that. I'm wondering if whoever did the upgrade saw a proxy ARP box ticked somewhere in the old environment and migrated it without checking if it was needed.

Dropped is probably the wrong word. Not routing correctly is probably better. One of the IPs the firewall has commandeered is the HSRP address of a network segment, so stuff is going a little wonky in & out of there. It's only showing up on one of the switches, so some traffic is getting through, just not all.

Time to do some reading.

Cheers

J

deanwebb

OK, not routing properly is a different beast, you're right there.

Does adding a static route help out? Or are all the routes on the firewall static?
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.

wintermute000

you most definitely need proxy ARP if you are doing NAT on IPs that don't actually 'exist' e.g. the typical NAT range you route to the firewall, otherwise how else does anything on that ethernet segment even get to the firewall?

However I can't explain why its hijacking the ARP for HSRP unless someone's goofed and configured a static NAT for that IP.

jericho

Thanks,

All sorted now. The client had gone and 'updated' the config after the contractor had finished, adding a load of  collection of NO-NAT rules from various DMZs to the internal segment, but had left proxy ARP enabled on all of them (among other odd things).

Getting them to tick the box to disable on destination appears to have solved the issue for now.

Cheers

J

wintermute000

If in doubt, go back to first principles... and behold it was the correct diagnosis :) Good to see that sorted you out

deanwebb

Quote from: jericho on December 05, 2017, 03:25:41 AM
Thanks,

All sorted now. The client had gone and 'updated' the config after the contractor had finished, adding a load of  collection of NO-NAT rules from various DMZs to the internal segment, but had left proxy ARP enabled on all of them (among other odd things).

Getting them to tick the box to disable on destination appears to have solved the issue for now.

Cheers

J

RULE OF TROUBLESHOOTING NUMBER ONE: People lie. They lie by saying things that are not true and they also lie by leaving out things that are important to know, but which might be a bit embarrassing.
Take a baseball bat and trash all the routers, shout out "IT'S A NETWORK PROBLEM NOW, SUCKERS!" and then peel out of the parking lot in your Ferrari.
"The world could perish if people only worked on things that were easy to handle." -- Vladimir Savchenko
Вопросы есть? Вопросов нет! | BCEB: Belkin Certified Expert Baffler | "Plan B is Plan A with an element of panic." -- John Clarke
Accounting is architecture, remember that!
Air gaps are high-latency Internet connections.