Issue: Snort and Ethereal are not seeing inbound packets with outside source Ip. Have installed dumb hub inbetween router and switch with snort/ethereal machine connected to hub with same results. Users able to websurf and rcv emails, so I know the packets are there. Any ideas?
I'd almost bet that even if the device you used said "Hub" on the outside, and it wass consumer grade gear, it was probably a switch. There was a while there when regardless of the label, it really was a switch (after all, most consumers didn't know the difference and didn't care).
Even if it's a switch, you should see ARP and other broadcast traffic from the router.
Were you running at 10Meg/Half duplex?
If not, some of the "100Meg Hubs" were also acting as hybrid switches ... or the system you're using didn't "downshift" to 10/half and missed all the traffic. Try forcing 10/half mode. There are no full duplex hubs.
Which hub did you use?
If you're using a managed switch, there is usually some flavor of port mirroring (Cisco calls it "SPAN") and may ultimately be easier for you to use (and you don't have to break the connection to put in the monitor.
The easiest way to see what's really there is to install Ethereal (or similar) on the destination PC. Start a capture, then go surfing, FTP, SSH, whatever from the same system. You will absolutely see all of the traffic for that station.
FWIW / Good Luck
This has been an ongoing problem that I have yet to resolve. I had techs over whom their only job is to setup, monitor and work with snort. They are the ones who assist me in setting hub between router and switch, and we used their equipment. So I know we were using correct type of hub and settings. But even regardless of that, my Network consist of Cisco 4500 Series router w/12.1(17) IOS and my switches are Xylan Omni switch ATM. I have Snort and Ethereal installed on a computer with bare W2k with Sp4. This computer resides on the same blade on the same switch that the router does. I have verified both ports are in the same Vlan/Group and have mirrored the router port to the sniffer workstation. In this config my sniffing computer is not picking up packets with an Ip source from outside of my Network. I am however getting all kinds of internal Network traffic. On this computer that I am typing this on resides on a different blade on the same switch as the router. I have Snort and Ethereal installed on this computer, without being mirrored, and I am seeing the same thing, no packets with source Ip from outside my Network. I have tried the sniffing computer at 10F and 10H with no change. Everyone that I have had look at it walks away puzzled. The funny thing is, I have two Networks, totally segregated from one another, and both are having the same issue. Any ideas?
From your description it looks like you're monitoring only TX of the switch port connected to the router. Could you show what does 'show monitor' says on the switch?
Also, by 'all kind of internal traffic' do you mean that you also see traffic that doesn't belong to this VLAN? In that case is it unicast or multicast? If you're seeing multicast traffic from supposedly different VLAN than the one you're monitoring, this is side effect of 'ip igmp snooping', which is default on many Cisco switches.
The config for the router port shows mirroring enabled and the slot/interface it is mirroring. Mirroring on a Xlan switch is easy, its either enabled and it ask for which slot/interface or it is disabled. There are no other options that go along with mirroring.
In regards to internal traffic, I am seeing other Vlan traffic. In regards to "ip igmp snooping", I am using a Xlan Omniswitch, not Cisco.
I can sit at my sniffing computer and on my other computer go to a website and see on Ethereal my workstation sending to my ISA Server, and my ISA Server sending to IP address of website, but I never do see the packets from website to my ISA Server. But yet I can surf all day long with no problems.
Sorry, I'm not familiar with Xlan Omniswitch, but it looks like it only copies traffic which is forward to a port, not received from a port.
In regards to seeing other vlan's traffic, if port you're monitoring is not 802.1q tagged port than this definetely bad. Provided that you've correctly configrued vlan's, I'd recommend you to take it up with Xlan customer support especially if it's not only multicast traffic you're seeing.
We think our issue is in the router due to the outcome of our trouble shooting efforts mentioned above. So my question is, what setting, if any, would transform inbound packets into ghost?
It could just part of the way the Omniswitch operates. Back when they came out, Xylan had some of the most innovative ways to use VLANs in the industry.
It's been better than five years since I've touched 'em (they were bought by Alcatel, along with Packet Engine at about the same time) ... but back in the days of many topologies, a Xylan could save an organization some major grief transitioning from one topology/technology to another.
For example, out of the box, you could put in an ATM UNI blade, a Token-Ring blade, an Ethernet blade, a CDDI blade and a FDDI blade into a chassis (with the switch processor) .... plug all of that stuff in, configure the ATM UNI for edge ... and everything would talk to everything else.
You could create VLANs such that the switch would automatically put you in the correct VLAN (sort of like VMPS, but this worked, and was years ahead of VMPS), put you in a VLAN based on authentication (originated from the switch), multiple VLANs per port, port groups, VLAN by protocol (IP, IPXS, Appletalk ...all automatic).
Xylan was a pretty neat switch, I have no idea what Alcatel's done with them since ... maybe their OK, maybe they're not.
I'm digging around to see if we still have docs in the Lab, I suspect not, but I promise to look.
Try things (if you haven't) like putting the mirrored port in the same VLAN as the monitored port, put the monitoring PC on the same IP block (I know it shouldn't matter in promiscuous mode, but try it), as the monitored (and mirrored) ports.
Try another PC and / or NIC in the monitoring machine, may it just doesn't like promiscuous mode.
Try changing the NIC parameters on the monitoring machine. Maybe the problem isn't the Xylan / router at all.
It's a goofy problem. For goofy problems, all you can do is to start ruling-out things one at a time. If you hit the end of the list, give up.
Thank you for the infomation. My Network is Fiber (ST) to the desktop. I have tried both onboard ethernet with media converter and a Fiber PCi card with no luck. The sniffing computer resides on the same switch and same blade as the router. Have tried same switch different blade with no change. Have tried all the above while mirrored and not mirrored. Have tried all the above with both ports in same Vlan/Group and in different Vlan/Group with no change. Have tried sniffing machine one Ip address lower than router, and tried Ip other than network Ip. Have tried two different machines. I agree it is a goofy problem, but last time I set up a sniffing computer, about 1.5 years ago, I had no problems and things worked first time. No major changes have been made to the Network, such as IOS upgrades on switches or router. Unforntunately the network is on a US NAVY WARSHIP, so I am unable to give up. Will have to figure it out, even if it kills me (which it probably will).
As stated by Scott and others in their previous post, and from your observation, this is problem with port mirroring process running in the Xlan OmniSwitch.
The best way to resolve this issue is to follow with their TAC.
As this is in Navy base, I guess the OmniSwitch & OSRs will be running the standardised Code, which is very old and have some features incorporated only for deployment in Navy.
I have encountered similar issues with port mirroring, which are fixed in later codes.
I know that code upgradation will not be an option for Navy base as it has to go through lot of process and approvals. Also the later codes will have some of the old features incorporated in different fashio, which will not be suitable for you.
The best thing that you can do is, take the following outputs and provide it to their support team, explaining the procedure to recreate. Most Probably you can try to get some private fix for this issue from them.
CLI/UI commands to capture from your omniswitch
download mpm.cnf, mpm.cfg and mpm.cmd files using binary ftp transfer from the switch.
The router is not broken. Whole purpose of router is to deliver packets to destination, and since all your users can surf the net, there's nothing wrong with the router. If destination PC can see packet, any other PC could see packet provided that packet has actually been sent that way.
The only situation when you couldn't see packet is when it's corrupted, but then all your users would have started to complain.