Perhaps, someone has already brought this question up but I was unable to find something relevant. We have an ASA with an unused interface (gig0/3). The AIP-SSM sensor is physically connected to this interface with the following IP settings:
Sensor (192.168.2.2/30,192.168.2.1) --- ASA interface (192.168.2.1/30)
It's basically point-to-point connectivity and I can reach the ASA from the sensor and the other way around.
This design is dictated by the lack of a free port on the switch.
Technically it should work without any problems, but I can't seem to be able to reach the sensor. There's a switch between my PC and the sensor and the switch has the corresponding static route added. I can reach the sensor from the switch.
Is there any hidden security feature that I don't know of which prevent communication with the sensor.
And the sensor's ACL allows traffic from all networks (0.0.0.0/0)
With the sensor ACl set to 0.0.0.0/0 the sensor should be allowing the connectivity.
You can use the "packet display" commmand on the sensor to watch the packets on its command and control interface to see if the packets are making it to the sensor.
You say you have a static route on your switch for the switch to reach your sensor. Do you know if your PC is setup to use the switch as the PC's default router. If the PC is using a different default router, then the other router would also need the static route.
The other possibility is that the ASA itself may be denying the traffic.
Since it is an ASA interface connected to the SSM, the traffic has to be routed through the ASA. Standard firewall rules will apply to this traffic. The security level of the interfaces may be preventing the traffic, and an ACL may be necessary in order to allow your PC's traffic to be routed to the SSM.
NOTE: If you didn't want to have to worry about routes, the other alternative is to make the network between the ASA and SSM be an isolated network that only those 2 machines know about.
You could then use static PAT to map an a port on the ASA's inside interface to the https port 443 of the SSM's address, and map a second port on the ASA's inside interfaces to the SSH port of the SSM's address.
This way your inside PC would just connect to the ASA IP using those specific ports and the ASA would do the port translation and forward them on to the SSM.
The SSM's address could also be dynamically PAT'd on the ASA's inside address so the SSM could initiate connection to other machines on the inside network.
Another alternative if you have IPs available on your inside network is to use static NAT instead of PAT. And just go ahead and have the ASA statically map an IP on the inside network to the SSM's IP on the network that only the ASA and SSM would know about.
In either case the network between the ASA and SSM would not be routable to, and you wouldn't have to worry about propogating static routes anywhere.
SIDE NOTE: Becase you have a separate network for the SSM you will also need to NAT or PAT the SSM's address for the ASA's Outside interface. This way the SSM will be able to connect to the Internet for downloading auto updates from cisco.com, and/or pull Global Correlation information from cisco servers. This is likely the same configuration you would already be doing for other internal addresses, and just to be sure you cover the SSM since you have it on a seperate subnet.