That just means that the packet filter/personal FW is dropping the unsolicited inbound packets and is sending back the proper response to the requester of 'Destination Unreachable'. There is a port 1 TCP/UDP but since the traffic is unsolicited, the packets are being dropped by the packet filter/personal FW.
If the traffic is being dropped by the packet filter/PFW, it's unsolicited inbound traffic the FW packet filter/PFW should not be letting through to the machine.
You should find out who the IP belongs to with Arin Whois by entering the IP into the Whois search block. You should make the determination if the IP is a legit IP -- most likely it is not a legit IP.
formatting link
You should be happy that the unsolicited inbound traffic is being blocked and forget about it.
There are one hundred forty different protocols using IP, such as TCP, UDP, ICMP, IGMP, BGP, XNS, Banyan Vines, Compaq Peer Protocol... and only a few use port numbers - ICMP is not one of them. See RFC0792.
0792 Internet Control Message Protocol. J. Postel. Sep-01-1981. (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950) (Also STD0005) (Status: STANDARD)
Your firewall (in common with many others) reports ICMP with the type number displayed as the source port, and the 'code' displayed as the destination port. This _should_ be explained in the documentation for your firewall.
ICMP Type 3 code 1 - Host unreachable.
Normally, a remote router will reply with ICMP Type 3 code 1 when you send a packet attempting to connect to a host that does not exist, or exists but is turned off/disconnected/dead/wedged. In ICMP, the 'source' IP address is the remote (router or host), and the destination IP is the system that sent the original packet that caused the problem. You need to review your outbound traffic, and find what host is sending the original traffic to an unreachable host. If your system is not NATing, or Port Forwarding, the problem lies on the host given as the destination IP in the ICMP packet. If you looked inside the ICMP packet with a packet sniffer, you will find the header of the packet that caused the problem.
No
One of your hosts - probably behind the firewall - is mis-configured, or is sending traffic to a host that doesn't want to speak to you.
The OP said ICMP packets, so your explanation doesn't really hold. ICMP type 1 is unassigned, type 3 is Destination Unreachable.
Depending on the firewall type, ICMP logging can be misleading. There are no ports for ICMP - just types, and the log shows these as "ports". Check your documentation to see what the log means. If the packets are type 3 you don't really want to block them, as that would mean your clients won't find out about non-existent destinations. At the very least you could filter as per the code field, letting only a sub-set through. Type 1 is unassigned and completely safe to block and ignore.
snipped-for-privacy@painkiller.example.tld (Moe Trin) wrote in news: snipped-for-privacy@compton.phx.az.us:
I might need to look at protocols a little closer or understand them a little better. However, in the message above, I see no indication of what the IP(s) are WAN or LAN other than some a.b.c IP notations. The OP gives no indication that he/she even has a LAN; I'll assume it's a remote IP and not a LAN IP and nothing on the machine is initiating it. I'll also assume, this is another personal FW solution in whine mode.
I have noticed over the past few weeks a slow build up of reports of ICMP packets being blocked by my firewall. The firewall reports follow the pattern below:-
ICMP packet dropped - Source:a.b.c.d, 3, WAN - Destination:w.x.y.z, 1, LAN -
The firewall drops them as 'Destination Unreachable' since port 1 doesn't exist on the firewall. I know that they aren't pings but I am puzzled as to what they are. My concern is that they may be legit traffic that is being blocked.
Are others seeing these packets also? Can anyone tell me what these packets are?
The IP address of the remote IP would have made a difference in the determination as to who it was, which is not part of any LAN situation or any ISP(s) DNS server IP as an example. You may want to leave it blocked if you determine that the IP may be of dubious origins.
LOL and no offense to you. But you being in whine mode and a PFW solution being in whine mode whining about nothing are two different things. If you consider yourself a piece personal FW software, then by all means the shoe fits. :)
Are we talking PFW, host based network/Internet FW, packet filtering router FW, or FW appliance?
I am amused at your response too as I thought I was kind of writing *plain English*.
If the machine is turned off, there is no traffic so how can something be spoofing traffic? In addition to that, the Sonicwall should be doing Stateful Packet Inspection (SPI) that should be preventing IP spoofing and several other types of attacks.
Traffic or packet sniffing is about traffic leaving a computer the sniffer such as Ethereal (free) would be installed on the computer in question to review all outbound traffic leaving the computer.
Doesn't the Sonicwall TZ170 have logging? That's what you should be using is the router's syslogs to get an accurate picture of traffic to/from the router or to/from the WAN and LAN.
You can use Wallwatcher and view in real time all inbound traffic from remote IP(s) and all outbound traffic from LAN IP(s) /machines -- all traffic to or from the router *Blocked and not Blocked* traffic -- ICMP or non ICMP traffic blocked or not blocked, along with setting various alert conditions that Wallwatcher will alert you on like an remote IP is being blocked an it's alerting you that it has happened like 60 times in a 15 second time frame as an example.
Look up SPI and find out how it works. Yes, It could happen on a simple NAT router that was not doing packet inspection, but it will not happen on that Sonicwall.
Well WW kind of works the same way. It shows all outbound connections blocked or not blocked, all blocked unsolicted inbound connection. As for solicted inbound that would be due to solicted outbounf from a machine and it doesn't show it. It may show the inbound if the router was doing port fowarding -- I have yet to do port forwading with WW active.
But you'll get more bang with WW than what you can get by using Excel.
It's unsoliced inboud traffic from a remote site that's being blocked. I get ICMP traffic on the Watchguard and I configure WG to block all ICMP traffic on the External interface. I just ignore it for the most part.
I looked back through the docs and it is there - "The TCP or UDP port number or ICMP code follows the IP address". Thanks for pointing me to it.
I have a single PC connected on the LAN side of a Sonicwall TZ170 firewall. I am soon to add a 2nd multi-media PC to the LAN. I run NAV daily and Ad-aware and SpyBot bi-weekly on the PC and none report any "funnies".
About 70% of these return packets arrive while my PC is turned off with only the firewall and modem active. Does this mean that someone is spoofing my IP address and causing the problem?
I am not how to go about sniffing the incoming ICMP packet as it is dropped by the firewall before it gets to my PC. I am assuming that the sniffer would need to be on the WAN side of the firewall.
Would turning ON the Windows Firewall logging help here as it would give me some clues to any packets going out to the addresses sending back the ICMP Type 3 code 1 packets.
I didn't consider that revealing the IP addresses would add any value to the discussion - hence the a.b.c.d notations. I can tell you that the ICMP packets are coming from the USA, while I am located in Australia, if that helps.
BTW I am NOT in whine mode at all. I am simply trying to find out what is happening. If doing that offends you - tough titty. I am amused at your response as it is not in your usual helpful vein.
I dunno - the words 'Source' and 'WAN' verses 'Destination' and 'LAN' are pretty indicative.
There are three possible causes.
Something on the LAN (or firewall) is initiating the connection, and the rules on the firewall are set to block all ICMP.
Someone elsewhere is using something like 'nmap' in the decoy mode, or is sending messenger pop-ups with a faked source address.
Someone elsewhere is attempting a denial of service attack (bandwidth) on the OP. Not very likely, because ICMP errors must not cause an ICMP error (meaning there is no acknowledgement or rejection sent back) so the attack isn't as efficient as sending (for example) a unrelated TCP frame (which would generate such an error packet).
While ICMP packets _could_ be longer, the longest legitimate ICMP packet (excluding ICMP Echo 'ping') is less than 100 bytes. In causes 2 and 3 above, there really isn't anything you can do about this. You're going to waste your CPU cycles no matter what, unless it's blocked on an upstream system - may not be the best idea, but...
I don't know about being in 'whine mode', but yes the firewall may not be optimally configured.
I'm only reporting the most common cause (and it waaayyyyy out-numbers spoofed address problems).
That's more probable in this condition. In another post, you list a dozen addresses in 63.176.0.0/12, and note the addresses all end in .8, ..9, or .10. That block is SPRINT-IPDIAL, which is used by Sprint (a major bandwidth supplier in the USA) for "point of presence" service. ISP x wants to offer a dialin location in town Y, but doesn't have any facilities there. Sprint (among others) will supply this service to the ISP for a fee. The IP addresses you show are located all over the country (look at the third term from the right in the name - it has the two letter state code and a short indication of the city, such as 'sdn-ap-005ilchic100F' being ILlinois and CHICago). Given that scatter, and the limited range of .8 - .10, I'd suspect this is either some worm or a skript kiddiez trying to find computers on the Sprint IP space to exploit, and is using your IP address (probably among others) to act as decoys. You are probably seeing what is called 'back-scatter' as a result. If that's the case, there really isn't anything you can do other than ignore the log entries.
On the firewall, or outside - yes.
I don't use windoze, but my understanding of the "firewall" that it has is that it only is set to effect incoming packets, and totally ignores all outgoing crap. What would be more useful is to monitor your system(s) to watch for outgoing _requests_ (such as your system wanting to pull up a web page at one of these unknown hosts). In this case, given the addresses involved (they all look like dialups), random locations of the hosts (all over the US), and that interesting limit on the range of the last octet, I'd more suspect a worm rather than a rogue web process. Given your statement that "70% of these return packets arrive while my PC is turned off", I'd suspect it's not your problem.
In another post down thread, you ask:
Sending spam - or indeed ANY transaction that takes TCP won't work. To establish a connection, there is a "three way handshake" needed before the connection is usable. You say 'hello' and give a sequence number. The peer replies, ACKing your sequence number, and says hello giving it's own sequence number. You then ACK the peer's number, and only then can data start moving. If a bad guy spoofed your address, that second packet goes to you, and he doesn't receive the sequence number, so no conversation can occur. On the other hand, sending something like windoze messenger pop-up ads (which uses UDP) would work, as these are typically sent blind anyway. The only way to discover this would be to look in that ICMP packet, and look at the included header to see what protocol was in the initiating packet.
OK, the bulk are coming from the Sprint USA 63.176.0.0 - 63.191.255.255 IP range. The IP addresses are:-
Source:63.184.190.9, 3, WAN - Source:63.184.254.10, 3, WAN - Source:63.185.62.9, 3, WAN - Source:63.185.94.10, 3, WAN - Source:63.186.30.9, 3, WAN - Source:63.187.30.9, 3, WAN - Source:63.187.94.8, 3, WAN - Source:63.187.254.10, 3, WAN - Source:63.188.62.10, 3, WAN - Source:63.189.30.9, 3, WAN - Source:63.189.190.9, 3, WAN - Source:63.190.94.10, 3, WAN -
One curiosity is that all addresses end in .8, .9 or .10
My apologies - I read you as saying that I was in whine mode. I hadn't heard the term used about a firewall before.
I didn't explain properly. I was wondering if a PC somewhere was using my IP address to send out packets containing spam or whatever. If the receiving site saw my IP address in the packets as the source it would send the response packet to my IP address not to the correct IP address of the actual PC that sent the original packets as it wouldn't know that IP address.
Ok, that explains it. That should show if my PC is sending anything. I would check for the same addresses cropping up in both logs.
The logs only show what has been dropped but show nothing about what traffic has gone in or out.
Thanks for the info. I'll have to check this out.
What I have been doing is having the firewall send me the log each day which I paste into Excel and then sort on source IP address order to see what is happening. But this only shows me what has been blocked by the firewall and shows nothing about traffic passing through the firewall untouched.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.