03-08-2019 03:06 AM - edited 02-21-2020 08:55 AM
Hello!
Just had to troubleshoot an issue where an internal firewall messed upp the network on its outside interface. The clients could not get addresses from the local DHCP server.
This is the network Layout:
On the "Internal ASA" there was this NAT rule:
nat (inside,outside) source static any any no-proxy-arp route-lookup
which caused the clients on the 192.168.5.0 network to not get any addresses from the DHCP server.
default route on Internal ASA is configured as:
route outside 0.0.0.0 0.0.0.0 192.168.5.1
Why is that?
The key here is that the 172.16.0.0 network behind Internal ASA should not be accessible from 192.168.5.0 network at all.
Actually, that 172.16.0.0 network is an remote network for a site to site VPN Connection which is only used for lab purposes.
I cannot see why the Internal ASA would cause the DHCP server not being able to respond to broadcast DHCP requests..??
03-08-2019 04:23 AM
03-08-2019 05:28 AM
03-08-2019 05:53 AM
Hi,
Normally asa not passing broadcasts to other side. I guess you have configured the dhcp relay.
In your case you can block these subnet communication with ACLs. Also asa will not reply to arp request because of 'no proxy arp'
I am not sure whether it is having some affect. You can try removing that command and 'route lookup' too for testing.
03-08-2019 06:35 AM
03-08-2019 01:27 PM
03-09-2019 12:42 AM
03-10-2019 03:04 AM
03-12-2019 03:08 PM
07-09-2024 08:48 PM
I had similar issue but in my topology I had ISP routers between my firewalls. The DHCP offer was being dropped by Branch Firewall. I saw the advice above to remove the NAT statement and once I did such my PC got its IP assignment. I could the dhcp binding on the DHCP and the DHCP offer traversed from HQ FW to Branch FW.. However, when I set up the lab in packet tracer, I had no issues at all so just curious as to why it worked in packet tracer. I used gns3 and eveng to determined if it was a issue with my simulation environment but results was the same. Again, once I removed the NAT statement it works fine.
p.s. HQ FW has two internal zones, a dmz zone and outside zone. Branch only has inside and outside zones so it this the case as to why NAT was not needed on the Branch firewall?
09-03-2024 11:45 AM
In my topology, the internal firewall was setting up a policy based site-to-site VPN to a off site firewall.
There was no route pointing to the 172.16.0.0/29 network.
This was some years ago now, and this network is now decommissoned.
But a too generous (any, any) NAT rule will cause the firewall to respond to ARPs. I think you would need to make the global address more precise or use another subnet for the global addresses.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide