Reg. Cisco IPS Inline VLAN Mode

Hi
Currently my Cisco IPS 4240 version 5.1(5) , is in Promiscous mode.Soon i will be configuring it in Inline mode .i will be using only 1 IPS Interface and will be configuring VLANs in the switch and connect the trunk port to the Gig0/0 of the IPS .The issue is that if the IPS goes down , will the packet flow continue to run smoothly i.e will the "Auto bypass mode" will be applicable for this scenario too and let the traffic goes without inspection ?
Ankur

Perfectly normal. Your test does not test the Software ByPass feature.
The confusion is in how Software ByPass and Virtual Sensor assignment are related.
If ByPass is set ON (Not Auto, but specifcally ON) then the traffic will be software bypassed regardless of whether or not analysis engine is running or whether the inline pair is assigned to any virtual sensors.
The driver does the bypass, and never even attempts to send it to the analysis engine.
If Software ByPass is set to Auto OR Off, the driver will always attempt to send the packets to the analysis engine.
The only difference between Auto and Off is what happens when the analysis engine STOPS pulling new packets from the driver.
With Software ByPass Auto, the driver will start passing the packets straight through and not send them to analysis engine.
With Software ByPass Off, the driver will bring the link down on the NICs until analysis engine is able to start receiving packets again.
So you see that Software ByPass is a function of the NIC driver.
Whether or not the pair is actually assigned to a virtual sensor is UNKNOWN by the NIC driver itself.
Whether or not the inline pair is assigned to a virtual sensor is solely a function of the analysis engine. If the analysis engine is functioning is running then the driver is always going to send it the packets. The analysis engine then checks to see if the packets should be monitored. If the inline pair is assigned to a virtual sensor then it is monitored before being passed back to the driver for transmit.
IF the inline pair is NOT assigned to a virtual sensor, then the packet is STILL passed back to the driver for transmit.
So an inline pair that is NOT assigned to a virtual sensor will STILL have packets passed through if analysis engine is Running. So long as analysis engine is runninng the NIC driver in Software ByPass Auto or Off does not care whether or not it is actually monitored. The driver only knows that it must pass the packet to the analysis engine and the analysis engine will send the packet back for transmit.
So adding and removing inline pairs from virtual sensors does NOT test the Software ByPass feature. The packets will always be passed through so long as analysis engine is running.
If analysis engine stops passing traffic, then software bypass kicks in and all inline pairs (whether monitored or not) will be treated the same depending on whether bypass is Auto or Off.
The only way to really test Software ByPass is to simulate an actual failure of the analysis engine.
To do this:
create a service account
login with service account
switch to user roor (su - root)
The root password is the same as the service account password.
Execute "ps -ef" to find the pid of the sensorApp process (which is the analysis engine)
Now execute "kill -9 ###" replacing the ### with the pid of the sensorApp process.
Now the Software ByPass functionality should kick in.
You can always run "show int" to see the current running status of the Software ByPass feature in the driver.
It will be either On, Off, or Auto_On or Auto_Off
The Auto_On and Auto_Off are the 2 running states for the Auto configuration. Auto_Off is when analysis engine is working, and auto_on is when the analysis engine is not working.

Similar Messages

  • IPS Inline Interface Mode - Can you use a port-channel?

    Hi,
    I'm trying to determine if you can have a 2-gig Layer-3 Port-channel going thru an IPS 4260 appliance. See attached diagram. Is this possible?
    The client I'm working with would prefer not to break this Port-channel into equal-cost 1-gig links (I don't think there will be any performance difference...) However I'm thinking if they want the appliance inline like the diagram shows - they will need to break the port-channel. Is that a correct assumption?
    Thanks,
    Brad

    Yes this is possible.
    It will require 2 InLine Interface Pairs on the sensor and both pairs should be added into the same Virtual Sensor.
    The 4260 will not be aware that etherchannels are used on both sides, and does not need to be aware.
    This may,however, require manual enablement of the etherchannels.
    Also keep in mind that the performance in this setup will be limited to what the IPS-4260 is able to perform with that traffic.
    If the IPS is only able to monitor 1 Gbps (which is its rating for Transactional traffic tests), then having the 2 InLine Interface Pairs will not give them any more performance than a single pair would.
    If the IPS is able to monitor more than 1Gbps of their traffic (it is rated at 2Gbps for Media Rich tests), then the additional pair will allow the sensor to get to the above 1 Gbps monitoring.
    If the 4260 is not able to keep with the traffic, then an upgrade to a 4270 using the same deployment setup may be necessary.
    NOTE: This also assumes that only the left or right path are actively passing traffic at any one time. If both paths are passing traffic, then asymmetric traffic patterns can result. if asymmetric traffic is seen, then another deployment should be considered, or specifial configuration be placed on the sensors.
    NOTE: This setup only works when a single sensor is used within the etherchannel. (1 sensor on each etherchannel, 2 sensors in your diagram because you have 2 etherchannels).
    You can not place 2 sensors in the same etherchannel (would mean 4 sensors in your diagram).
    This is because the balancing being done from the lower switch can not be guaranteed to match that being done from the top switch. A mismatch in balancing could lead to asymmetric patterns.
    With a single sensor, the same virtual sensor sees all traffic regardless of which interface the packet comes in on, so a single sensor is fine. But with 2 sensors, the client traffic might get sent to a different sensor than the server traffic.

  • IDSM-2 Inline Vlan Pair - Duplicate Packets

    Dear All
    We have a setup where two IDSM-2 modules are ether-channeled together in a single 6513 Chassis.
    There is an FWSM module also, which acts as the default gateway for all internal VLANs.
    Problem: IDSM show stat virtual-sensor command is showing tons of 'Duplicate Packets'
    show statistics virtual-sensor | inc Duplic
    Duplicate Packets = 2950967
    Inline TCP Tracking Mode: Interface and VLAN
    Topology:
    Assume Client VLAN = 10 and Server VLAN = 60
    IPS Inline VLAN Pairs:
    10 >> 110 (Client VLAN)
    60 >> 160 (Server VLAN)
    Client >> Server Flow: (Layer 2):
    [ClientPC] >>>> Access Switch (VLAN 10) >>>> Core SW >>>> IDSM-2 (VLAN 10--110 Pair) >>>> Core Sw >>>> FWSM VLAN 110 >>>>
    FWSM VLAN 160 >>>> Core Sw >>>> IDSM-2 (VLAN 160--60 Pair) >>>> Server Switch (VLAN 60) >>>> [Server]
    Core Switch IPS Etherchannel Setup:
    Group 5: IDSM(A) and IDSM(B) Port x/7
    Group 6: IDSM(A) and IDSM(B) Port x/8
    Some VLAN Pair(s) are on interface x/7 and others are on x/8
    Because of the above issue, we see a lot of TCP normalization signatures being fired (as the IPS gets confused with duplicate packets seen for the same flow). Specially signatures 1330:12 :17 and :18.
    It is also causing some applications to break (e.g. Veritas Netbackup 6.5). When I removed the DENY action from these signatures, our IPS started having stability issues (This could also be due to E3 upgrade)
    Should we change the Tracking mode to 'VLAN' only, OR any other possible solution?. Should not the 'interface and vlan' setting be sufficient?.
    Regards
    Farrukh

    This will take some traffic analysis to determine what is going wrong.
    You might need to place a sniffer to watch the traffic on the client where the backup software is running at the same time that you capture the traffic on the sensor.
    Look to see if there are any differences in the traffic.
    Look for any anomalies in the traffic.
    Look to see if maybe the backup software is not using a standard TCP connection (is it jumping the tcp sequence numbers in any abnormal way?)
    You might also try some things on the sensor to determine if the sensor itself might have an issue.
    Determine if the connction passes through 2 connections (inline vlan pairs) monitored by the sensor.
    If you can, you might try removing both of the pairs from the virtual sensor. (don't delete the pairs, just remove them from the virtual sensor so they won't be analyzed)
    And see if the backup works.
    If it does then just add in one pair, and see if it keeps working.
    If it has errors with just the one pair, then the problem is likely not because of the connection being monitored twice.
    Something else must be weird about the connection.
    If the problems are only seen when having both pairs in the same virtual sensor, then try placing the pairs in different virtual sensors and see if the problem goes away.
    If the problem goes away when in different virtual sensors, then there may be an error in the inline tcp session tracking code that should track connections separately for each interface/vlan.

  • IDSM-2 inline VLAN pair mode

    My customer has voice, video and data VLAN's. Customer wants to inspect only inter VLAN traffic ONLY for data to be inspected by IDSM-2 inline while bypassing other VLAN traffic to FWSM and then to WAN.
    Is that possible with Inline VLAN pair mode?
    I read the cisco document which states as below
    "You can configure IDSM-2 to simultaneously bridge up to 255 VLAN pairs on each data port. IDSM-2 replaces the VLAN ID field in the 802.1q header of each packet with the ID of the VLAN on which the packet is forwarded. It drops any packets received on VLANs that are not assigned to an inline VLAN pair."
    The last statement says it will drop all other vlan traffic which are not assigned to any inline vlan pair?
    Regards
    Vinod

    You can bypass analysis engine when inline bypass is activated , allowing traffic to flow through the inline interfaces and inline VLAN pairs without inspection. Inline bypass ensures that packets continue to flow through the sensor when the sensor processes are temporarily stopped for upgrades or when the sensor monitoring processes fail. But not always.

  • 6509 - IDSM-2 inline vlan pair mode at layer 3

    I am a little green, so be nice.
    wondering how to get an IDSM-2 module inline on a 6509. my issue is that the traffic comes into the 6509 at layer3 (routed) so I'm not sure how the config works. (e.g. do I use a trunk, or do I have to add a in a hop somehow)
    6509 conf snippet:
    intrusion-detection module 7 data-port 1 trunk allowed-vlan 3127,3128
    vlan 3127
    name FIREWALL-IPS
    vlan 3128
    name FIREWALL
    interface Port-channel2
    description CAB2
    ip address 10.30.2.2 255.255.255.0
    ip helper-address 10.10.20.11
    ip helper-address 10.10.20.13
    ip helper-address 10.30.123.11
    no ip redirects
    no ip unreachables
    no ip proxy-arp
    ip flow ingress
    glbp 2 ip 10.30.2.1
    glbp 2 timers msec 250 msec 750
    glbp 2 priority 120
    glbp 2 preempt delay minimum 60
    glbp 2 load-balancing weighted
    glbp 2 weighting track 89 decrement 50
    glbp 2 weighting track 99 decrement 50
    glbp 2 forwarder preempt delay minimum 60
    interface GigabitEthernet1/9
    description FIREWALL
    switchport
    switchport access vlan 3128
    switchport mode access
    no ip address
    interface GigabitEthernet8/9
    description CAB2SW1-Gi1/0/49
    no ip address
    channel-group 2 mode on
    interface GigabitEthernet9/9
    description CAB2SW1-Gi1/0/50
    no ip address
    channel-group 2 mode on
    interface Vlan3128
    description FIREWALL
    ip address 10.30.128.2 255.255.255.0
    no ip redirects
    no ip unreachables
    ip flow ingress
    no ip igmp snooping
    glbp 128 ip 10.30.128.1
    glbp 128 timers msec 250 msec 750
    glbp 128 priority 120
    glbp 128 preempt delay minimum 60
    glbp 128 load-balancing weighted
    glbp 128 forwarder preempt delay minimum 60
    IDSM-2 conf snippet:
    service interface
    physical-interfaces GigabitEthernet0/7
    description data-port 1
    subinterface-type inline-vlan-pair
    subinterface 1
    description FIREWALL VLAN3127<->VLAN3128
    vlan1 3127
    vlan2 3128

    A colleague of mine explained how to do this and it mostly makes sense. My only confusion is that once you remove the access vlan (3128) from the interface that gets monitored and replace it with 3127, how does traffic still traverse the 3128 vlan? What is the mechanism that controls this, is it the command "intrusion-detection module 7 data-port 1 trunk allowed-vlan 3127,3128" ??

  • Changing IPS from promiscous mode to Inline mode

    Hi Experts,
    We are changing our IPS (aip-ssm10) mode of operation from promiscous to Inline mode. Is there any caveats or anything i need to take into consideration before doing the switch? Is there a possibility to roll back incase something doesn't go the way we planned?
    I look forward to your responses.

    changing from promiscous to inline and back is done with the ips-command in the ASA MPF-config. So if you run into problems you can easily switch back.
    What you should do before changing to inline:
    - check your alerts for false positives and eliminate them first.
    - if you can't eliminate all, make sure that the risk-rating doesn't exeed the threshold for the automatic deny-action if configured.
    - and of course keep monitoring your events after the switch to inline.
    Sent from Cisco Technical Support iPad App

  • IPS Interface Pairs vs. Inline VLAN Pairs

           I've got a Cisco IPS 4240 that needs to be configured inline.  Right now I've got an ASA 5525-X with two interfaces (inside and DMZ) plugged into our Catalyst 6500 Switch that need to be monitored by the IPS.  I also plugged two interfaces from the IPS into the same Catalyst switch hoping that I could use the inline VLAN pairs to monitor that traffic.  I've got several VLANs in our DMZ and LAN that need to be monitored. The problem is that I don't understand how the inline VLAN pairs are supposed to work (Cisco's IPS documentation is almost useless), I've been fighting with it for some time with no success. 
         I'm now thinking that it might be a better idea to plug the two interfaces from the ASA directly into the IPS and then create Interface Pairs from the IPS to the switch.  My concern with doing this is that I am turning the IPS into a single point of failure, if it goes down everything goes down with it.   Also, will the Interface Pairs work with a 802.1q trunk?  Would I then need to create VLAN groups for the trunk? Would using inline VLAN pairs also create a single point of failure? 
         Basically, I'd like to know the pros and cons to the Interface Pairs vs. the Inline VLAN pairs.  Interface Pairs seems like the easiest and most comprehensive way to go, but if I can avoid the single point of failure with the inline VLAN paris I would like to go that route. 

    Hello Paul,
    I want to go with Inline vlan pair,i don't want to go with interface pairing,as this is request by customer,how i can do it,as i m having a IPS-4240 with 4 gig ports,
    I have a doubt that if we create a vlan pair then in each pair 1 be a real vlan and the other should be dummy vlan ????  ( for example vlan 2 and vlan 3 in which vlan 3 is the dummy vlan). Please suggest
    If i have a 10 vlan than i will configure the 10 pair of vlan on gig0/0 with real and dummy vlan, but what vlan pair i shld configure on gig0/1 i.e (exit interface to ASA DMZ interface.)
    Thanks
    Message was edited by: adamgibs7

  • TCP RESET - CISCO IPS 4240 in IDS Mode - Block Teamviewer

    I would like to block teamviewer in my network. we are using CISCO IPS 4240 in IDS Mode. I found that there are signatures for teamviewer in latest Signatures.
    We have only configured promiscuous interface, I read that we can issue TCP resets thru promiscuous interface as well (recommended is dedicated tcp reset interface).
    However in my case, I found that Signatures for teamviewer is not getting fired even after getting successful teamviewer connections.
    I am a beginner is IPS, Any inputs will be valuable for me.

    We're talking about sigs 15002-0, -1, -2 here. They are by default shipped disabled and retired, so you'll want to enable and activate them.
    For these, the signature settings are not hidden and what they look for is pretty clearly documented in the sig description.
    -0 looks for some specific DNS requests on TeamViewer's startup. TCP resets will have no effect on this.
    -1 looks for specific traffic to tcp port 5938 which would indicate Teamviewer's direct-connection method
    -2 looks for traffic indicating use over http when teamviewer is configured to use a proxy
    TCP resets are a best effort response, they aren't going to be a 100% effective stop

  • IDSM-2 inline vlan pair mode configs

    Dear all,
    1. Is it possible to associate 2 vlans( to be paired) on 2 different data ports on IDSM instead of pairing it on single data port on IDSM ?? & configuring these 2 ports on CAT6509 as access ports instead of trunk... Will this thing work ?
    2. Since bypass mode is ON by default(AUTO) in IDSM-2 in-line vlan pair mode but when I am testing the bypass its not happening..can any pls. guide what could be the reason for this ?
    Regards,
    Akhtar

    You can bypass analysis engine when inline bypass is activated , allowing traffic to flow through the inline interfaces and inline VLAN pairs without inspection. Inline bypass ensures that packets continue to flow through the sensor when the sensor processes are temporarily stopped for upgrades or when the sensor monitoring processes fail. But not always.

  • Filter Traffic using ISDM-2 Inline Mode and Inline VLAN Pairs

    Hi Everyone,
    I have a new ISDM-2 Module (Version 6.0(1)E1) and I?m thinking use Inline VLAN Pairs to bridge two vlans, in my case vlan 100 and vlan 101. Vlan 100 is the vlan used by MSFC and Vlan 101 is the vlan used by the outside of my FWSM . In this way, I think I can monitor all the traffic into and from Internet. My question is: can I choose what traffic I will analyze using this configuration ? Maybye with VACL or another way.
    Thanks in Advanced
    Andre Lomonaco

    If I understand your question correctly, I do not think you have the ability to selectively inspect the traffic with only a single pair of vlans. The IPS module is going to bridge your vlans together and you would want all traffic to go through that bridge...I don't know what mechanism you'd use to selectively direct traffic through some other bridge/route function.
    Within the IPS software you can turn off (disable AND retire) signatures that inspect traffic that you wish to ignore, the IPS will just forward the traffic through, but you don't have a fine level of granularity there.
    Scott

  • Issue - Inline VLAN pair IPS

    Hello everyone,
    I have an issue with an 4255 IPS using an inline VLAN pair. Here's the rough sketch of the topology:
    SW1
    port 1 access vlan 10 - PC (10.20.30.2/24)
    port 48 trunk to SW2 - all vlans allowed and forwarding
    SW2
    port 48 trunk to SW1 - all vlans allowed and forwarding
    port 1 trunk allowed vlan 10,20 to IPS g0/1 configured in inline VLAN pair; assigned to sensor etc.
    SVI vlan 20 for network 10.20.30.1/24 (up/up)
    I'm unable to ping SVI from PC. Anyone have any suggestions? Running packet display on IPS interface I only see BPDUs hitting the interface. VTP is enabled but pruning is disabled. Both vlans exist on both switches.
    I'm only seeing ARP requests from SVI on the IPS, but no replies coming from the remote switch.
    Alternatively the PC is sending ARP requests to the SVI IP, but those aren't getting resolved, nor are they getting to the IPS interface.

    Hello Yuriy
    So Topology is something like
    PC-----ACCESSPORT----SW1----TRUNK----SWITCH2
                                                                     |
                                                                     |
                                                                   IPS Inile vlan pair
    The thing is that if you already allow the vlans on the trunk link then traffic will not get inspect by the IPS,
    Do you see what I mean, you must force it to go to the IPS.
    Let me know if I was clear enough

  • Configuring the Catalyst 6500 Switch for IPS Inline Operation of the IDSM

    I understand how to configure the Catalyst 6500 switch so that the monitoring ports are access ports in two separate VLAN's for inline operation.
    However, I don't see any documentation that describes how the desired VLAN traffic gets forced through the IPS.
    In promiscuous mode, you can use VACL's to copy/capture and forward the desired traffic to the IDSM for analysis. I'm not seeing how to get the desired traffic through the IPS.
    Note that the host 6500 is running native IOS 12.2(18)SXE.
    Thanks for any assistance.

    A tranparent firewall is a fairly good comparison.
    Let's say you have vlan 10 with 100 PCs and 1 Router for the network.
    If you want to apply a transparent firewall on that vlan you can not simply put one interface of the firewall on vlan 10. Nothing would go through the firewall.
    Instead you have to create a new vlan, let's say 1010. Now you place one interface of the firewall on vlan 10 and the other on vlan 1010. Still nothing is going through the firewall. So now you move that Router from vlan 10 to vlan 1010. All you do is change the vlan, the IP Address and netmask of the router stay the same.
    The transparent firewall bridges vlan 10 and vlan 1010. The PCs on vlan 10 ae still able to communicate to and through the router, but must go through the transparent firewall to do so.
    The firewall is transparent because it does not IP Route between 2 vlans, instead the same IP subnet exists on both vlans and the firewall transparently beidges traffic between the 2 vlans.
    The transparent firewall can do firewalling between the PCs on vlan 10 and the Router on vlan 1010. But is PC A on vlan 10 talks to PC B on vlan 10, then the transparent firewall does not see and can not block that traffic.
    An InLine sensor is very similar to the transparent firewall and will bridge between the 2 vlans. And similarly an InLine sensor is able to InLine monitor traffic between PCs on vlan 10 and the Router on vlan 1010, but will not be able to monitor traffic between 2 PCs on vlan 10.
    Now the router on one vlan and the PCs on the other vlan is a typical deployment for inline sensors, but your vlans do not Have to be divided that way. You could choose to place some servers in one vlan, and desktop PCs in the other vlan. You subdivide the vlans in what ever method makes sense for your deployment.
    Now for monitoring multiple vlans the same principle still applies. You can't monitor traffic between machines on the same vlan. So for each of the vlans you want to monitor you will need to create a new vlan and split the machines between the 2 vlans.
    In your case with Native IOS you are limited to only 1 pair of vlans for InLine monitoring, but your desired deployment would require 20 vlan pairs.
    The 5.1 IPS software has now the capability to handle the 20 pairs, but the Native IOS software does not have the capability to send the 40 vlans (20 pairs) to the IDSM-2.
    The Native IOS changes are in testing right now, but I have not heard a release date for those changes.
    Now Cat OS has already made these changes. So here is a basic breakdown of what you could do in Cat OS and you can use in preparation for a Native IOS deployment when it gets released.
    For vlans 10-20, and 300-310 that you want monitored you will need to break each of those vlans in to 2 vlans.
    Let's say we make it simple and add 500 to each vlan in order to create the new vlan for each pair.
    So you have the following pairs:
    10/510, 11/511, 12/512, etc...
    300/800, 301/801, 302/802, etc....
    You set up the sensor port to trunk all 40 vlans:
    set trunk 5/7 10-20,300-310,510-520,800-810
    (Then clear all other vlans off that trunk to keep things clean)
    In the IDSM-2 configuration create the 20 inline vlan pairs on interface GigabitEthernet0/7
    Nw on each of the 20 original vlans move the default router for each vlan from the original vlan to the 500+ vlan.
    At this point you should ordinarily be good to go. The IDSM-2 won't be monitoring traffic that stays within each of the original 20 vlans, but Would monitor traffic getting routed in and out of each of the 20 vlans.
    Because of a switch bug you may have to have an additional PC moved to the same vlan as the router if the switch/MSFC is being used as the router and you are deploying with an IDSM-2.

  • Cisco IPS 4240 stops file downloads at 90%

    Hi everybody. I have a Cisco IPS 4240 with version 7.0.4 installed and upgraded to the last signature. But since it was installed i have the issue with some file downloads because the IPS stops the file at 90-99% of download percentage (in some cases, not all), The ips is inline in front of firewall, some partner say me that i have to change the mode to promiscuous for the solution of the issue, but i think that if the IPS was designed for work inline, i dont have to change anything and maybe some expert of the forum have the correct answer.  Or this issue have solution with configuration changes.
    Sorry by my write english.... I try to find some signature that causes the issue but if i disabled the sensor, the issue occurs. The firewall is not the problem because if i connect a laptop in front of the firewall and behind of IPS the issue occurs too. Well i have now some months trying of find a solution. In the page of Cisco not find some similar.... [:-(
    Pd. An example of files that stop when downloads is Apple Itunes... or Microsoft Patch, or Vmware software by example.
    Thanks for your response are greatly appreciated.

    Thnaks for your help this is the last packets before freeze the download:
    The size of the download with problems is random, sometimes ocurrs with small size downloads sometimes ocurrs with large downloads. The download of the example have 47 MB, I think that the traffic is dropped and the tcp conn timeout. Do you see some anomalies in this traffic portion?.
    14:55:20.536119 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.536122 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.536420 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.536718 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.536820 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.537123 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.537125 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.537517 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.537520 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.537522 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.537821 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.537823 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.538116 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.538118 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.538415 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.538418 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.544207 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.544307 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.638362 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.638365 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.638463 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.638562 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.638862 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.638864 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.638866 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.639164 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.639166 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.639560 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.639562 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.639564 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.639960 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.640260 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.640263 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.640568 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.641958 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.641960 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.642158 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.742304 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.742603 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.742605 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.742607 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.742903 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.743202 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.743302 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.743601 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.745000 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.745100 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.845347 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.845548 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.845550 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.845647 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.845845 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.846245 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.846247 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.846544 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 47929166 win 65335
    14:55:20.849040 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48010926 win 65335
    14:55:20.849439 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48012386 win 65335
    14:55:20.948787 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48015306 win 65335
    14:55:20.948789 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48018226 win 65335
    14:55:20.952982 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48021146 win 65335
    14:55:20.953679 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48024066 win 65335
    14:55:21.055723 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48029906 win 65335
    14:55:21.055725 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48032826 win 65335
    14:55:21.055930 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48035746 win 65178
    14:55:21.058919 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48037206 win 65335
    14:55:21.068809 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48040126 win 65335
    14:55:21.068812 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48043046 win 65335
    14:55:21.069006 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48045966 win 65335
    14:55:21.070103 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48048886 win 65335
    14:55:21.158967 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48051806 win 65335
    14:55:21.159265 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48054726 win 65335
    14:55:21.159465 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48057646 win 65335
    14:55:21.159864 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48060566 win 65335
    14:55:21.159867 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48063486 win 64605
    14:55:21.162162 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48066406 win 63875
    14:55:21.162260 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48066406 win 65335
    14:55:21.172245 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48069326 win 65335
    14:55:21.172248 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48072246 win 65335
    14:55:21.172545 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48075166 win 65335
    14:55:21.172645 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48078086 win 64605
    14:55:21.172744 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48078086 win 65335
    14:55:21.172844 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48081006 win 65335
    14:55:21.173144 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48083926 win 64605
    14:55:21.185225 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48083926 win 65335
    14:55:21.572333 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48116046 win 65335
    14:55:21.585313 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48151086 win 65335
    14:55:21.585315 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48151086 win 65335
    14:55:21.585414 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48151086 win 65335
    14:55:21.585417 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48151086 win 65335
    14:55:21.585512 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48151086 win 65335
    14:55:21.677172 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48151086 win 65335
    14:55:21.688654 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48151086 win 65335
    14:55:21.688657 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48158386 win 65335
    14:55:21.688757 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48158386 win 65335
    14:55:21.780613 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48170066 win 65335
    14:55:21.883755 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48170066 win 65335
    14:55:21.986998 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48170066 win 65335
    14:55:22.090639 IP 10.0.0.1.56109 > apollo.fileburst.net.80: . ack 48170066 win 65335

  • Only some of the traffic passing through inline vlan pair

    Here is my network setup
       firewall<---- >(g1/2)Coreswitch 6500 with IDSM(TG9/1)<-----> (TG9/1) Distrib switch with FWSM---------Accessswitch
    configuration in core switch
    interface GigabitEthernet1/2.11
    description **** ****
    encapsulation dot1Q 211
    ip vrf forwarding VRF11
    ip address 10.2.11.73 255.255.255.248
    ip ospf network point-to-point
    standby 1 ip 10.2.11.75
    standby 1 priority 110
    standby 1 preempt
    interface GigabitEthernet1/2.37
    description **** ****
    encapsulation dot1Q 237
    ip vrf forwarding VRF37
    ip address 10.2.37.73 255.255.255.248
    ip ospf network point-to-point
    standby 1 ip 10.2.37.75
    standby 1 priority 110
    standby 1 preempt
    interface TenGigabitEthernet9/1.11
    description ****   ****
    encapsulation dot1Q 311
    ip vrf forwarding VRF11
    ip address 10.2.11.2 255.255.255.252
    ip ospf network point-to-point
    interface TenGigabitEthernet9/1.12
    description ****   ****
    encapsulation dot1Q 312
    ip vrf forwarding VRF12
    ip address 10.2.12.2 255.255.255.252
    ip ospf network point-to-point
    configuration in Distribution switch:
    interface TenGigabitEthernet9/1.11
    description ****  ****
    encapsulation dot1Q 311
    ip vrf forwarding VRF11
    ip address 10.2.11.1 255.255.255.252
    no ip route-cache
    ip ospf network point-to-point
    interface TenGigabitEthernet9/1.37
    description ********
    encapsulation dot1Q 337
    ip vrf forwarding VRF37
    ip address 10.2.37.1 255.255.255.252
    no ip route-cache
    ip ospf network point-to-point
    i  have seggregated  n/w like this. i am using inline vlan  pair , to pass all the traffic through the IDSM module ,
    i am using the monitoring port gi0/8
    config in core switch
    intrusion-detection module 8 data-port 2 trunk allowed-vlan 211-260,311-360
    IDSM
    physical-interfaces GigabitEthernet0/8
    subinterface-type inline-vlan-pair
    subinterface 11
    description
    vlan1 211
    vlan2 311
    exit
    subinterface 37
    description
    vlan1 237
    vlan2 337
    exit
    Problem i am facing is , some of the vlan-pair traffic passing through the IDSM some of the traffic are not passing , here i have given the statistics
    MAC statistics from interface GigabitEthernet0/8
       Statistics From Subinterface 11
          Statistics From Vlan 211
             Total Packets Received On This Vlan = 0
             Total Bytes Received On This Vlan = 0
             Total Packets Transmitted On This Vlan = 0
             Total Bytes Transmitted On This Vlan = 0
          Statistics From Vlan 311
             Total Packets Received On This Vlan = 0
             Total Bytes Received On This Vlan = 0
             Total Packets Transmitted On This Vlan = 0
             Total Bytes Transmitted On This Vlan = 0
    Statistics From Subinterface 37
          Statistics From Vlan 237
             Total Packets Received On This Vlan = 3189658726
             Total Bytes Received On This Vlan = 64165872092928
             Total Packets Transmitted On This Vlan = 3549575166
             Total Bytes Transmitted On This Vlan = 64165872092928
          Statistics From Vlan 337
             Total Packets Received On This Vlan = 3549575166
             Total Bytes Received On This Vlan = 64165872092928
             Total Packets Transmitted On This Vlan = 3189658726
             Total Bytes Transmitted On This Vlan = 64165872092928
       Statistics From Subinterface 38
          Statistics From Vlan 238
             Total Packets Received On This Vlan = 2215151150
             Total Bytes Received On This Vlan = 64165872092928
             Total Packets Transmitted On This Vlan = 126546964
             Total Bytes Transmitted On This Vlan = 64165866995200
          Statistics From Vlan 338
             Total Packets Received On This Vlan = 126546964
             Total Bytes Received On This Vlan = 64165866995200
             Total Packets Transmitted On This Vlan = 2215151150
             Total Bytes Transmitted On This Vlan = 64165872092928
    Give me idea experts , so that i can resolve this issue.
    Help me thanks in advance

    I believe the issue is because of the config below:
    interface GigabitEthernet1/2.11
    description **** ****
    encapsulation dot1Q 211
    ip vrf forwarding VRF11
    ip address 10.2.11.73 255.255.255.248
    ip ospf network point-to-point
    standby 1 ip 10.2.11.75
    standby 1 priority 110
    standby 1 preempt
    encapsulation dot1Q 311
    ip vrf forwarding VRF11
    ip address 10.2.11.2 255.255.255.252
    ip ospf network point-to-point
    interface TenGigabitEthernet9/1.12
    description ****   ****
    encapsulation dot1Q 312
    ip vrf forwarding VRF12
    ip address 10.2.12.2 255.255.255.252
    ip ospf network point-to-point
    As you can see we have 2 ip subnets in the VRF 11 .73 &  .2 in vlan 211 & 311 respectively.
    The switch is doing intervlan routing directly without having to go through the IDSM for VRF 11.
    What we need to remember is IDSM does not do routing, and it can only bridge vlans.
    Hence we have to force to packet to go through the IDSM.
    Here is what we do when we use IDSM to see traffic going between vlans.:
    Normally, with vlans, and IDSM inline mode, we have one IP subnet and 2 Vlans.
    IDSM2 in inline mode necessitates an additional artificial Vlan on the  SAME subnet as the Vlan you wish to sense.
    A layer 3 switch  interface  needs to be configured within this additional artificial Vlan.
    In a nutshell, we need to create 2 Vlans that share one same ip subnet and put SVI on only one of the Vlans.
    In your case you will need one ip between vlans 211 & 311 in VRF 11 to force the data to go through the IDSM.
    I can understand if this is a bit tricky to understand.
    Please go through my design document for IDSM inline mode, which explains the basic concepts and packet walk in detail.
    It will explain why we need the above and how arp makes the mac-address table populate correct entries, (with one ip subnet for 2 vlans) so that traffic goes through the IDSM.
    https://supportforums.cisco.com/docs/DOC-12206
    - Sid

  • IDS 4215 Inline VLAN Pair

    I am trying to configure IDS 4215 to do inline vlan pair with a Cisco 3750 Layer 3 switch.
    We have 4 vlans in the 3750, vlan 100 for workstations,vlan 200 for servers, vlan 250 for ip phones and vlan 150 for firewalls.
    All vlans have corresponding SVI with that ip been the default gateway for each vlan.
    interface Vlan1
    no ip address
    interface Vlan100
    description Workstation VLAN
    ip address 192.0.0.5 255.255.255.0 secondary
    ip address 192.0.0.254 255.255.255.0
    interface Vlan150
    description WatchGuard FW VLAN
    ip address 192.168.150.254 255.255.255.0
    interface Vlan200
    description Servers
    ip address 192.168.200.254 255.255.255.0
    interface Vlan250
    description VOICE
    ip address 192.168.250.254 255.255.255.0
    ip helper-address 192.168.200.30
    interface Vlan254
    description Management VLAN
    ip address 192.168.254.254 255.255.255.0
    My question is how do i monitor the traffic going to firewall vlan from server/workstation vlans ?
    I read a quite a bit of old topics here in this forum but could not find anything matching though there were few coming close.
    So my idea is to configure new vlan say 151 and move the firewalls to the new vlan.Then do inline vlan pair on old firewall vlan 150 and new fw vlan 151.
    Any idea its going to work ? or can i simply do 2 vlan inline pairs for fw-server and fw-workstation vlans ? Also i understand that i have to configure trunking on switch ports ?
    would appriciate any comments.

    I would recommend you proceed with your first suggestion of creating vlan 151, moving the firewall ports to vlan 151, and then placing the sensor inline between vlans 150 and 151.
    There are 2 options for placing the sensor between vlans 150 and 151: inline interface pairing, or inline vlan pairing.
    With inline interface pairing you would need the 4FE card in the IDS-4215. Create an inline interface pair using Fe2/0 and Fe2/1.
    Create an access port on vlan 150 of your switch and connect Fe2/0.
    Create an access port on vlan 151 of your switch and connect Fa2/1.
    Allow spanning-tree to run (generally between 30 and 40 seconds).
    With InLine Vlan Pairing you can do this with an IDS-4215 without needing the 4FE card.
    Create an inline vlan pair subinterface on Fe0/1 that will pair vlans 150 and 151.
    Creat an 802.1q trunk port on your switch that will trunk just vlans 150 and 151 (leave the native vlan of the trunk as vlan 1, but do not place vlan 1 in the list of allowed vlans on the trunk)
    Connect Fe0/1 to your trunk port.
    Now this will cause All traffic between your internal networks and the firewall to have to pass through the sensor. This includes your voice traffic that goes through the internet.
    The other option you mentioned of creating inline vlan pairs on your workstation vlan and your server vlans, I would not recommend with IPS 5.1.
    The inline vlan pairs would have to be created similar to the inline vlan pair I described above using vlans 150 and 151.
    You would have to create vlan 101 and pair 100 and 101.
    As well as create 201 and pair 200 and 201.
    If the workstations ONLY have connections out through the Firewall and NOT to the servers then it would be OK.
    BUT if the workstations also have connections to the servers then it will cause problems. The packets will have to pass through both the vlan 100 and 101 pair as well as the vlan 200 and 201 pair.
    When the sensor sees the same packet again after having been routed (by the switch in this case) it causes issues. The sensor sees that the packet has changed and believes that a hacker is modifying packets on the network.
    This is being addressed in IPS version 6.0 (still under development) so that vlan pair 100 and 101 can be monitored independant of vlan pair 200 and 201.
    So until IPS 6.0 is released I would suggest staying with the single vlan pair approach using vlan pair 150 and 151.

Maybe you are looking for