I am starting this thread because we are experiencing a problem with a 'brandnew' cisco ASA 5525x firewall.
We never configured these firewalls before but since the setup is quite simple, we don't know what is going wrong.
This is getting quite urgent because we need this firewall in production fast.
The type is ASA5525-IPS-K9.
IPS license is not yet installed.
We have simplified our testing setup as in the image bellow (basically this is all we configured, standby firewall was switched off)).
We are firewalling from enterprise dekstops to production servers (no internet involved).
We have set all 'ACLs' open with any to any as much as possible, no blocked traffic is reported in debug mode of the logging.
We have also put all interfaces in the same 'zone' namely 100.
Ping request FAILS:
10.240.20.11 to 192.168.0.x
10.240.20.11 to 10.240.29.1 (I guess this is normal firewall behavior)
10.240.20.11 to 10.24.29.2
192.168.0.11 to 10.240.20.2 (I guess this is normal firewall behavior)
192.168.0.11 to 10.240.20.11
(same thing for 10.240.21.11)
Ping request OK:
192.168.0.11 to 10.240.29.1
192.168.0.11 to 10.240.29.2
10.240.20.11 to 10.240.21.11 (routed over the firewall)
We do not see any 'blocked' messages in the logging that is put to debug mode.
If we replace the 'w2008r2 router' by a single laptop with 1 connection and IP 10.240.29.1 GW 10.240.29.2 and connect in the same port, then we are able to ping from 10.240.29.1 to 10.240.20.11 and vice versa.
If we replace the Cisco firewall by a L3 Cisco 3750X with similar routing configuration, we can ping from 10.240.20.11 to the entire 192.168.0.0/23 network and vice versa.
These findings are making us very desperate in finding a solution because the findings do not make sense to me?
Can anyone please give some input on this?
If required I can upload the configuration file here.
Thank you very much in advance,
Solved! Go to Solution.
We have done the ARP resetting and all mac addresses seemed to be fine after.
Still our uplink to the 2008r2 router does not work while everything seems OK.
This is really worrying me.
But thanks for the input..
I would still suggest as an easy way to confirm the section from LAN/DMZ host to the firewall external interface with the ICMP capture (or whatever traffic you want to capture, the capture can be modified to pretty much any setup needed).
With the capture you could confirm if
This way you would probably be able to narrow down the problem to a certain section without constantly changing the network setup that might give false results if the ARP doesnt happen to refresh to the current test setup.
Your original setup seemed to point to a situation that you were able to ICMP from the ASA directly to the remote network 192.168.0.0/23 but not from behind the ASA?
This thread is about ARP problems with ASA switches could this be related?
It is quite technical to me.
(edited post above)
As Jouni has mentioned the packet capture will give us a 100% confirmation that the traffic is passing through the ASA.
Then, we started a ping from the laptop to the other, so started a ping from 10.240.29.1 to 10.240.10.11, this worked.
After this, the ping from 10.240.10.11 to 10.240.29.1 started succeeding, without any config change ???
OK, I don't see 10.240.10.11 in your diagram further up, though I do see that the ASA has an interface in this subnet. Are you experiencing this problem from all subnets attached to the ASA?
I am starting to wonder if the 2008r2 router is missing some routes maybe. Is this a Cisco router? Could you post the router configuration please?
Please remember to rate and select a correct answer
First of all , thank you all for the responses and tips.
The 2008r2 router is not a Cisco router, it is a Windows Server 2008 R2 virtual machine that has 2 NIC's, and has the "LAN Routing" role activated. It has static routes that seemed OK.
We solved the problem by leaving out this 2008r2 "router" and by giving the firewall 1 IP address in the Enterprise LAN 192.168.1.17. We then configured the enterprise router (which is a real router) to route the 10.240.0.0 traffic to the 192.168.1.17 and everything worked fine. I think the problem was caused by the "Windows Router" that was linked to the firewall, but we are unsure why this was. In the end, it doesn't matter because after integration the firewall will be connected to a 'real' router and not a Windows Server routed machine.