I've bought a 4215 IDS (2 interfaces) with the 4.1 image some years ago. I want to use it in inline mode. I will buy a 4FE card and an upgrade for the image to the latest version.
My question is if there is any posibility to use a pair of interfaces in bridging mode before a nat device and another pair of interfaces in bridging mode after the nat device, in order to see the traffic with the real ip addresses.
I also want, for the above configuration, to use the sensor to check:
- only the inbound traffic from the Internet on the first pair of interfaces (before this traffic passes the nat device):
Internet ---> IPS(pair1-checking) ---> NAT ---> IPS(pair2-not checking) ---> LAN
- only the outbound traffic from the LAN to the Internet on the second pair of interfaces (before this traffic passes the nat device):
LAN ---> IPS(pair2-checking) ---> NAT ---> IPS(pair1-not checking) --->Internet
I want to do this in order not to doublecheck the traffic.
Has somebody tried this configuration or has any idea if it works?
The sensor can perform inline sensing between one or more VLAN pairs on a single sensor interface. Cisco Catalyst line cards that connect directly to the switch backplane and appliances that connect to an external port of the switch can use this feature.
You can use a sensor with 4 interfaces to monitor the Internet side of the firewall with one pair of interfaces, and monitor the InSide of the firewall with a 2nd pair of Interfaces.
What you can not do is configure the sensor to only monitor InBound traffic on the Internet pair, and only monitor OutBound traffic on the InSide pair.
The version 5.0 and 5.1 sensors support only a single virtual sensor. What this means is that even though you are using 2 InLine Interface Pairs the sensor will treat it as one network, and will use one set of signature settings and one set of filters for the monitoring of that one network. You can not configure one pair of interfaces to monitor different traffic than the 2nd pair of interfaces.
In the future when multiple virtual sensors are supported, then there is some wiggle room, but still won't get exactly what you want.
Each pair of interfaces could be placed in a separate virtual sensor.
This way you could have one set of signatures and filters on one pair, and a separate set of signatures and filters on the second pair.
The problem is that the sensor will still monitor all of the traffic and so will actually monitor eadch packet twice (once on each pair, and therefore once in each of the 2 virtual sensors).
So from a monitoring aspect you can not prevent the sensor from monitoring the traffic.
HOWEVER, you can prevent the sensor from generating alerts where the source Address is the NAT/PAT address(es) of the firewall for the virtual sensor monitoring the pair on the Interent side of the Firewall by creating a Filter. The sensor will still be monitoring the packets, but any alerts that are seen will be Filtered out and won't be sent to your monitoring tool.
Similarly you could add a filter on the virtual sensor monitoring the InSide pair to fitler out any alerts where the source address is on the OUTside ($OUT is a variable that you can use to say all address that are not on my INside network that I configured as part of the $IN variable). The sensor would still monitor those Internet to InSide connections, but any alerts would be filtered and not be sent to your monitoring station.
Those same filters could be used to not only prevent the alert, but also prevent other actions like denying the packet.
BUT you would need to wait until multiple virtual sensors are supported in order to try this filtering technique because you would need separate filters per interface pair that are not supported in the current versions that support only a single virtual sensor.
Thank you very much. I think I shall design another scenario. Maybe I shall use 2 separate interfaces for the inbound traffic (one for the tx and one for the rx), and 2 separate interfaces for the outbound traffic one for the tx and one for the rx), and let the sensor see only one side of the connection form each part.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...