cancel
Showing results for 
Search instead for 
Did you mean: 

Entry in Router Log

Razer
Grafter
Posts: 1,398
Thanks: 8
Registered: ‎17-11-2012

Re: Entry in Router Log

Quote from: ejs
The type of packet is a reply. The proper use for this packet is for replying. But anyone could malciously craft the packet and send it to you. Or someone sends a packet with a spoofed IP address to the other system so that the other system will send the reply to you. Or, especially if you recently changed IP addresses, it could be related to the previous user of your current IP address (unless you've got a static IP of course).

Yes, of course. Thanks for that bit of a reminder.
Quote from: ejs
I see very few of these ICMP Destination Unreachable packets.

I see many, regularly, most especially when I'm playing my game. It's how I've come to confusion about them in reference to direction and the source of my particular problem.
@AO. Thanks for trying to explain. I'm still thinking it's not making sense. About the direction. Perhaps I haven't been clear about my confusion in that regard. With the quote I put from the article about Destination Unreachable being a response to a datagram from 'the device', implying it is the 'originating source', that is why I am confused when one sees a DU entry from another IP address to one's own, as with Jim's. What ejs said notwithstanding, the direction of the reply is of course from the other IP address, but the ultimate source is still 'the device'. Further to this, what compounds my confusion is that it sheds no light on the root of a problem I have and have previously posted about on forum. If I can understand 'direction' - i.e. source of the problem, I can perhaps move on.
I get a host of DU entries when playing my game. The greater amount are to do with the game server and they are port unreachable. If they are replies to 'the device' my device, then I think that means my device has tried to connect to a port on the game server and it was unreachable and the server replied as such. Fine, I can understand that (though quite how it replies if it's unreachable I don't know). What throws me is that if the direction - i.e. source, is the game server - as implied by the direction in the entry: IP address so and so to my IP address then that makes me think the game server has tried to connect to my device and my device was unreachable and the article is wrong - it isn't a reply. Huh
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: Entry in Router Log

If the code part says port unreachable, that means the game server process is not running, but the computer the game server runs on  - the host - is still up. So the operating system of the computer replies with the port unreachable message. The destination is a port on the host, so the packet got as far as the host, but couldn't reach the port, because the game server program isn't running.
Quote from: Razer
I'm still thinking it's not making sense. About the direction. Perhaps I haven't been clear about my confusion in that regard. With the quote I put from the article about Destination Unreachable being a response to a datagram from 'the device', implying it is the 'originating source', that is why I am confused when one sees a DU entry from another IP address to one's own, as with Jim's. What ejs said notwithstanding, the direction of the reply is of course from the other IP address, but the ultimate source is still 'the device'.

The log entry is always going to have the destination as your IP address and the source as some remote IP address. The ICMP packet itself will contain details of the 'originating source' as you put it, but I don't think those are in your log.
Here is a packet I logged, it's a reply from the final destination that I got by doing a UDP traceroute to sf.net (which is handy because sf.net is short to type, and it responds).
[tt]ICMP DU SRC=216.34.181.62 DST=87.113.my.ip LEN=56 TOS=0x00 PREC=0x80 TTL=239 ID=24993 DF PROTO=ICMP TYPE=3 CODE=3 [SRC=87.113.my.ip DST=216.34.181.62 LEN=60 TOS=0x00 PREC=0x00 TTL=1 ID=39681 PROTO=UDP SPT=59900 DPT=53 LEN=40 ] [/tt]
The traceroute sent a UDP packet to port 53 on 216.34.181.62 - that's not a DNS server, it's the sourceforge website, which sent me the ICMP reply indicating there's nothing running on port 53. The part inside [ ] is the details of the 'originating source' which I assume aren't in your logs.
Edit: Because I see so few of these, I added extra logging rules to log all ICMP DU packets, even the ones I'm expecting to receive.
Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: Entry in Router Log

Hang on a minute, that is confusing things even more and doesn't represent the reality that Jim specifically was quoting.
I'll address Razer's points later.
Quote from: ejs
Because I see so few of these, I added extra logging rules to log all ICMP DU packets, even the ones I'm expecting to receive.

So users with normal firewall rules will not see such a packet, the response to what you sent would normally go straight to the program/command that sent it, not the Firewall!, unless you designed it to respond to a port that was blocked!
Quote from: ejs
Here is a packet I logged, it's a reply from the final destination that I got by doing a UDP traceroute to sf.net (which is handy because sf.net is short to type, and it responds).

I think this muddies the picture.
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: Entry in Router Log

Quote from: Anotherone
I think this muddies the picture.

I was illustrating an ICMP DU packet for Razer. If I wasn't expecting it, and it just turned up out of the blue, the log entry would be the same (with a different first SRC IP address of wherever it came from).
Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: Entry in Router Log

@Razer
The article isn't wrong, you are misinterpreting it due to the understandable confusion, made worse by ejs's response IMHO.
The reason for the log entry (in Jim's case) is that the Firewall did not allow the packet to be delivered to the destination - his machine - the entry is very clear., his IP address is the destination.
I really think it a case of bad phraseolgy, the type of incoming packet in Jim's example is not a reply, the reply is what is sent to the source. Read again with my bolding, see if that helps -
The quote you gave in reply #6 does not mean that you have received the Destination Unreachable message, it means that is what has been sent to the Source. The message received by the Source will go to the program on the source device that sent it (not it's Firewall - if it has one - unless it has special rules or hasn't been set up correctly for the program). The Destination Unreachable message is a reply to the Source about the packet it sent to you
Quote from: http
The receipt of a Destination Unreachable message tells a device that the datagram it sent couldn't be delivered, and the reason for the non-delivery is indicated by the Code field in the ICMP header

In the normal course of events when you are running any program, game or otherwise, the relevant ports will be available if you've set things up correctly - eg. it may require port forwarding, dmz whatever. You should not see Firewall log entries stopping legitimate packets.
Let me take a more simple example when using your browser, if you can't reach the destination, do you look in your Router log for why - no - you get a message in your browser - it could be a Timeout, a 403 or 404 etc. The message is returned to the program.
Without seeing your specific log entry Razer, I can't really comment more.
At this point, I really can't spend any more time trying to explain this, I have other things to get on with (and we now have visitors as well), maybe someone else can try. I may come back to it in the future.
Razer
Grafter
Posts: 1,398
Thanks: 8
Registered: ‎17-11-2012

Re: Entry in Router Log

OK guys thank you for your efforts. What ejs says is what I have been told before - as it transpires by you ejs. Whilst I can understand that and previously 'accepted' the explanation, I have been continually bothered by it because it runs contrary to what I still actually think is going on - what you have said AO. I'll dig out the previous example I've posted on forum before:
Quote
FIREWALL replay check (1 of 11): Protocol: ICMP Src ip: 216.240.146.139 Dst ip: 87.113.176.213 Type: Destination Unreachable Code: Port Unreacheable

Src=game server, Dst=my IP at the time.
My reading of that tells me it is my port which is unreachable in this instance, and I read your above post AO as confirming the same. It would seem to me that Jim's message is essentially the same as mine in terms of the direction, then: them trying to contact us and us saying no (for whatever reason).
npr
Pro
Posts: 1,898
Thanks: 119
Fixes: 9
Registered: ‎21-01-2013

Re: Entry in Router Log

This may help you understand these ICMP datagrams.
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
Personally I can't be bothered to get my head around these firewall logs. They are only the firewall boasting that's it's blocked some incoming packet.
IMO it's not the stuff in the logs we need be concerned about, it's the stuff that's not picked up Wink
Oldjim
Resting Legend
Posts: 38,460
Thanks: 787
Fixes: 63
Registered: ‎15-06-2007

Re: Entry in Router Log

duplicate post removed
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: Entry in Router Log

Quote from: Anotherone
Let me take a more simple example when using your browser, if you can't reach the destination, do you look in your Router log for why - no - you get a message in your browser - it could be a Timeout, a 403 or 404 etc. The message is returned to the program.

A timeout is probably the most incorrect example possible. A timeout is getting no response whatsoever until your web browser decides to stop waiting. If your web browser then displays a pretty error page, that's entirely down to the web browser all by itself, without it receiving anything. In fact your web browser could indeed display a time out message if your firewall goes bonkers and wrongly blocks the packets so that they never reach your web browser! You do not receive any "timeout" packets!
A HTTP 403 or 404 error message on the other hand, is delivered over the same HTTP connection that the web page would have been sent, some web sites will even send pretty or amusing error pages. Those are sent to the web browser.
Razer
Grafter
Posts: 1,398
Thanks: 8
Registered: ‎17-11-2012

Re: Entry in Router Log

Quote from: npr
This may help you understand these ICMP datagrams.
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

Well thanks npr, I appreciate the link. I am still confused because that hops back (as I read it) to ejs and the link I've already quoted and questioned before being correct. I think I fucking give up.
Quote
Personally I can't be bothered to get my head around these firewall logs. They are only the firewall boasting that's it's blocked some incoming packet.
IMO it's not the stuff in the logs we need be concerned about, it's the stuff that's not picked up Wink

It's important to me because when I know what is factually correct about my log entries I'll be able to tell whether my set-up (or router itself) is at fault or if it's a fault with the game servers.
Excuse me Jim. I hadn't intended to hijack your thread. Please do split it off if you think that's necessary.
Anotherone
Champion
Posts: 19,107
Thanks: 457
Fixes: 21
Registered: ‎31-08-2007

Re: Entry in Router Log

Quote from: ejs
A timeout is probably the most incorrect example possible.

Embarrassed You are of course technically correct there as it's not due to a packet of data sent to your IP address, more the lack of!! I hope you appreciate I was just trying to illustrate that in normal circumstances, the program that's being run, browser, game, whatever, will normally give you relevant information.
Oldjim
Resting Legend
Posts: 38,460
Thanks: 787
Fixes: 63
Registered: ‎15-06-2007

Re: Entry in Router Log

Quote from: Razer
Excuse me Jim. I hadn't intended to hijack your thread. Please do split it off if you think that's necessary.
No problem - I had the answer to my question by npr reply 4