locked
Filter to remove specific protocols? RRS feed

  • General discussion

  • Hi, this is my first post on these forums.

    I currently have a server acting as a DCHP, VPN and web server etc. I access is remotely via RDP. ive installed microsoft network monitor to monitor exactly whats going on, however when i connect via RDP, i get flooded with TCP and RDP protocols that just roll......is there a way to add a filter to REMOVE the specified protocols? or better still from the SOURCE.

    better still, would it be possible to say remove all "TCP" connections from "xxx.xxx.xxx.xxx" and all "RDP" connections from "xxx.xxx.xxx.xxx" that way i dont loose all TCP connections just the ones from the IP im connected from via RDP..

    If that makes any sense at all

    Thanks!

    Friday, October 14, 2011 1:05 PM

All replies

  • Hi Splinky,

    Welcome to the forum.  Be sure to check out our blog for a lot of great info for these sorts of scenarios: http://blogs.technet.com/b/netmon/.  You can also go to the videos and learn tab to find more info, including common filters.

    You'd want to try something like: !(TCP && Source == "xxx.xxx.xxx.xxx") && !(RDP && Source == "xxx.xxx.xxx.xxx")

    If you don't even want to capture this data, apply it as a capture filter in the Capture Settings dialog.


    Michael Hawker | Program Manager | Network Monitor
    Friday, October 14, 2011 7:03 PM
  • but thats the thing, the filters appear to SHOW the specific filtered data. Not remove it

     

    Thanks!

    Friday, October 14, 2011 11:57 PM
  • Hmm, that should be working.  Would you be able to copy the filter you're typing here (minus IP address of course)?

     

    Also, what version of the product and parsers are you using?  You can try to update your parsers at http://nmparsers.codeplex.com/ as well to see if that helps first.


    Michael Hawker | Program Manager | Network Monitor
    Saturday, October 15, 2011 12:05 AM
  • the one you gave me

     

    !(TCP && Source == "xxx.xxx.xxx.xxx") && !(RDP && Source == "xxx.xxx.xxx.xxx")

    it seems to filter out all TCP connection to me, and RDP connections to me too, which is right but then scrolls heaps of TCP from 219.88.186.89 and if i do a tracert on that its deploy.akamaitechnologies.com which i have no idea what it is, a bit eary?

    PS. The odd RDP packet still pops up from my IP. I have a color rule set the protocol RDP. It takes ages to Parse everything to after applying the filter.

    Is this normal? Im quite new to this


    UPDATE: After applying this filter, i let it Parse, then it goes back to normal and all RDP and TCP traffic from me is shown

    Thanks for your help

    • Edited by deanfourie Monday, October 17, 2011 4:59 AM
    Monday, October 17, 2011 4:45 AM
  • can anyone help with this??

     

    Thanks!

    Tuesday, October 18, 2011 7:21 AM
  • It might be easier to just remove the traffic based on the RDP ports.  There is a standard filter under Remove Noise called No-Terminal Server.  This filter is simply:

    !(Tcp.port == 3389) and !(Tcp.port == 1494) and !(Tcp.port == 1503)

    This will remove any traffic (in both directions) with any of these ports.  You could add a specific source if you want, but I'm not sure why you'd want to do this as then you'll get one-way traffic for the RDP traffic and I would think you'd want to get rid of this as well.  Maybe that's part of the problem you were seeing above.

    Also I'd recommend you use IPv4.Address==xxx.xxx.xxx.xxx (or IPv4.SourceAddress if you want it to be directional) rather an Source=="xxx.xxx.xxx.xxx" because sometimes names get resolved and this will change what shows up in the Source column.  This gets tricky if you apply this type of filter during captures because Source can change from a resolved name to unresolved based on the network traffic.  And this will affect your filter.

    BTW, the speed is dependant on your parser profile.  I would use Default, if possible as this will speed up parsing and filtering.  You will only need Windows is you want to more detailed parsing for Windows protocols.  You can always switch to Windows profile once you have things narrowed down.

    Paul

     

    Tuesday, October 18, 2011 5:58 PM
  • Hi thanks for your reply.

    I would rather filter TCP and RDP traffic only from me specifically, reason being security. I still need to see if another RDP connection is active.

    Could you please give me a line for filtering TCP and RDP traffic from IPv4Address xxx.xxx.xxx.xxx.

    Im extremely new with network monitor, but learning ;)

    Thanks again for your reply!!

     UPDATE: so im using the filter you explained

    No Terminal Server

    !(Tcp.port == 3389) and !(Tcp.port == 1494) and !(Tcp.port == 1503)

    and it works well, but obviously i would like to show other RDP traffic, so is there a way i can add the specific WAN ip?

    One more thing, its only the RDP protocol i want to do this with, I want to do this with PPTP and GRE from my connection to filter all the VPN trafffic that just scrolls too.

    But i figured if i can get a line to filter RDP i can just change it to filter the VPN traffic too.



    • Edited by deanfourie Wednesday, October 19, 2011 3:34 AM
    Wednesday, October 19, 2011 3:14 AM
  • In general you can get rid of any traffic to a specific address by defining the traffic and then negating it.  To learn, create a filter to find the traffic, then negate the entire statement.  So if you want to get rid of RDP traffic on port 3389 to 192.168.1.1 you would do:

    !(TCP.Port==3389 && IPv4.Address==192.168.1.1)

    For PPTP and GRE, I would just use the protocol names in your filter since there shouldn't be an fragmentation below these.  For RDP this doesn't work because RDP could be fragemented into TCP, so this is why we use the port instead above.  So you could do

    !((TCP.Port==3389 || PPTP || GRE) && IPv4.Address==192.168.1.1)

    Hope that helps,

     

    Paul

    Wednesday, October 19, 2011 2:52 PM
  • This seems to work well!!

    Thankyou very much!

    Thursday, October 20, 2011 5:28 AM
  • !protocol.RDP


    Tuesday, June 14, 2016 11:54 AM