If that is all you have configured, there is probably no route to non local networks. So you would need an ip route to your remote network(s) through the inside interface-
route inside 192.168.10.0 255.255.255.0 10.128.65.1
That obviously assumes that 192.168.10.x is the remote network and 10.128.65.1 is the gateway.
You will need to do a "route management" route as well to the network that will manage your ASA-
route management 192.168.20.0 255.255.255.0 10.128.128.1
This assumes 192.168.20.x is the management network and 10.128.128.1 is the gateway attached to the management interface. A word of warning on the management route, I'm not sure how the ASA differentiates routing for management and transit traffic. I assume transit traffic would still work based on connections that are built on the non management interface. Again, that is an assumption
When you connect to the internet, you will also need a default gateway that may look like this-
route outside 0.0.0.0 0.0.0.0 220.127.116.11
I will answer to both replies in the same post...
This is not the solution, because I tried with and without "management-only" command. And, I said that I can't ping the inside interface either - from the management subnet.
Again, this won't do. Let me clear out my network config:
inside_host = 10.128.65.225
mgmt_host = 10.128.128.34
inside_ASA = 10.128.65.5
mgmt_ASA = 10.128.128.102
Gateways are indeed numbered as .1 as you suggested.
So, I CAN PING:
inside_host -> inside_ASA
mgmt_host -> mgmt_ASA
BUT I CAN'T PING:
inside_host -> mgmt_ASA
mgmt_host -> inside_ASA
So routing on ASA isn't the problem at all. I know you thought that return traffic can't get to my hosts, but as you see these are all 'connected' networks, and od course they exist in the ASA's routing table.
I am rather experienced in the cisco/networking world, but still new to ASAs, so maybe there is something I am not quite seeing here...
Consider the situation: pinging from mgmt_host to the inside_ASA:
Is it possible that ASA is receiving the traffic on one interface (inside), but sending the return traffic on the other interface (mgmt) because it sees the source IP address? It is rather silly thought, because it is not the transit traffic, it should return it on the same interface, but I am wondering - again I am still getting used to the ASA. Could it be that is the problem, maybe because it has something to do with the management interface?
I didn't try to put up another "regular" interface, and then try pinging... I will do that on Monday and see what will happen.
Anyway, thanks guys for the help and your time. I will post the Monday's result.
I think there are two issues here. The first issue is the fact that management-only takes the interface out of band like an OOB management plane. Traffic received on management interface will only work on that interface. No traffic received by another interface will be forwarded to the management interface.
The other issue is, as you suggested, within the logic. I don’t think the ASA will not allow you to connect to one interface and communicate with the address on another one.
In the old days, you couldn't even configure a host to use the ASA interface as a default gateway for hosts when there are other internal gateways the hosts should reach. There was a long standing rule that if a packet came in one interface it had to leave another. This is irrelevant to the issue you are talking about. However, it illustrates the fact that there are some natural rigid tendencies to the ASA Algorithm.
In other words, what you are seeing is normal. Is there some reason that this is a problem?
Well, I think that WOULD be normal, if it wasn't for the fact that the same thing happens if I put MGMT interface in "normal" mode - I mean without "management-only" command.
Anyway, I thought I could access the MGMT interface from my own IP address (different subnet), but it seems I can't. It is not needed, but it is convenient. But it would deny logic that mgmt traffic should be separated from the regular traffic, so this is not a good idea anyway.
So, to answer your Q, I don't have any particular reason to complain, I just want to straighten things out and to understand what is going on. It was a busy day today on the job and I didn't manage to test things I mentioned before. I will try tomorrow.
The ASA's logic is quite different from a router. You will get a response when you send management traffic to the address on the interface that receives the traffic. So if your mgmt traffic is going in E0/0, you need to use the address hooked to that interface. The management-only command further segregates this to really an out of band scenario. There are a few organizations that have built up separate management networks, and this is where that becomes applicable. Don't think of the ASA as a router. It does some routing functions (and now far more than in the PIX), but it thinks differently than your IOS devices.
I have gone through your question and found that you are not able to ping the interface ip address of E0/3 when connected to management interface and vice-versa. Please correct me if, I am wrong.
This behaviour in normal. We can not ping the different interface from the host sitting behind the other interface of the firewall this is by-design. We can only ping directly connected interface from the host.
Let me know if this answers your question.
Deepankar Rohatgi (CCIE Security 23029)
Thanks for the final clarification. But I would like to add an observation:
"To allow management access to an interface other than the one from which you entered the security appliance when using IPSec VPN, use the management-access command in global configuration mode."
I tried this command when I did not even know what it is all about. And the result was unusual. When I entered "management-access my_mgmt_if", from this point forward I was able to ping mgmt interface from the inside interface! But not vice-versa, of course. I could not gain access through telnet/ssh or ASDM, I was just able to ping it.
Is this a bug then? I was not using any VPN, just plain old icmp.
So, to wrap things up, the behavior that puzzled me is normal, that's ok. But what do you think about the successful pinging after the management-access command was entered?
The main purpose for that command is to allow you to access the private IP address that you may normally manage your appliance with through a vpn tunnel. For example, if you wanted to manage it from the outside, you would have to do one of the following:
1). connect directly to the outside interface with ssh
2). build a transport tunnel that allows you to connect to the outside interface.
3). use your normal existing data vpn and connect to the internal *
Method 3 seems to make the most sense. However if you are using the ASA itself to terminate the tunnel, this will not work due to the way the ASA functions (it will not allow you to connect to an interface opposite where the packet was received). The management-interface changes this behavior. I don't think it should when you are using a dedicated management interface, but I can see how that could a side effect. Cisco considers snmp, icmp, telnet, ssh, http, management traffic in regards to this. I'm curious if anything other than ping can jump to the dedicate management interface when this is configured this way.