Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mschwab]

My 825 is currently filling up my log with these messages:
[INFO] Tue Jul 07 17:27:39 2009 Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.3 to 64.34.14.32   
[INFO] Tue Jul 07 17:25:57 2009 Above message repeated 381 times   
[INFO] Tue Jul 07 17:25:56 2009 Blocked outgoing ICMP packet (ICMP type 3) from 192.168.0.3 to 64.34.14.31   
[INFO] Tue Jul 07 17:22:18 2009 Above message repeated 827 times   

while my Everquest2 game is running on the 192.168.0.3 local machine.  64.34.14.30/31/32 are registered to Vivox.com, which is the 3rd party company that provides voice chat support for Everquest/Sony.  I would like to be able to allow these IP address to communicate with each other (both ways), so that I might not get these error messages, and so that voice chat might work (not working at all at the moment, although some times it does).  I also want to enable these IP addresses to talk to 192.168.0.2, my other gaming machine.

But when I sat down with my network-professional neighbor to go over the 825 menus, even he could not figure out which page to use to try to enable these IP addresses to go through the router.  Could I get some simple tutorial information about how to achieve this, please?

[Fatman]

You might try reading the first page or so of this thread.

http://forums.dlink.com/index.php?topic=6002.0

[mschwab]

You might try reading the first page or so of this thread.

http://forums.dlink.com/index.php?topic=6002.0

OK, I read all of that thread (wow, lot of "side stuff" going on there!  I used to be a forum moderator, and I don't envy you the job!), and the couple pages you linked to.  A lot of it went over my head, and I think I'm a little more tech-savvy than your average customer (with my dusty electrical engineering degree ).

I think what you are trying to tell me is that the ICMP Type 3 message that the 825 is "Blocking" is not really being blocked, but is simply "unreachable", or it's a bad IP address?   I can ping the addresses, so they are not completely "unreachable".  So the error message is misleading in that it says the router "blocked" the message?  Or is it more like the router blocked the message because the IP address is unreachable anyway?

Are you saying there is no way to set the 825 to allow these messages to go through anyway?  So does that mean it is a problem in the Vivox voice software on my client, that is trying to reach those IP addresses that are not available?  Or is the server behind those IP addresses malfunctioning?

[Fatman]

OK, I read all of that thread (wow, lot of "side stuff" going on there!  I used to be a forum moderator, and I don't envy you the job!), and the couple pages you linked to.  A lot of it went over my head, and I think I'm a little more tech-savvy than your average customer (with my dusty electrical engineering degree ).

I think what you are trying to tell me is that the ICMP Type 3 message that the 825 is "Blocking" is not really being blocked, but is simply "unreachable", or it's a bad IP address?   I can ping the addresses, so they are not completely "unreachable".  So the error message is misleading in that it says the router "blocked" the message?  Or is it more like the router blocked the message because the IP address is unreachable anyway?

Are you saying there is no way to set the 825 to allow these messages to go through anyway?  So does that mean it is a problem in the Vivox voice software on my client, that is trying to reach those IP addresses that are not available?  Or is the server behind those IP addresses malfunctioning?

Being a moderator is easy, unimaginable power, in an eety bity living space!  In all seriousness though, this is the easiest part of my day, I will keep it.

ICMP type 3 messages are sent when a host or service is unavailable or unreachable, an example would be if you attempted to send a UDP packet to your PC (and don't have anything listening on that UDP port, and your PC doesn't just ignore unsolicited packets silently) it should respond with an ICMP Type 3 message saying unavailable.  Your PC or any other router along the way however can decide to drop that ICMP type 3 message however.

ICMP type 3 messages ARE being blocked, but they are very commonly blocked at gateways in modern networks.

Back in the day (so I am told, I wasn't a gleam in my fathers eye when ICMP was being written) this was a big security discussion and everyone was quite heated about it.  The status quo that arose out of those ashes however was that ICMP type 3 is a convenience and should not be relied on ever because any router along the way can drop it silently and without fear of being told it is doing something wrong.

If you had ever seen the way I tell routers they are doing something wrong you would understand their fear.

It is also (due to the above amongst other reasons) not your core issue.  I am starting to fear given the number of VoIP devices that are reporting issues that I am going to find that STUN or some other VoIP related technology relies on ICMP type 3 messages (which would be a no no standards wise).  I have a strong feeling that when (and if) we get out captures back from Tsumone (anyone really) then we will have an potential answer for all of the related issues.

In summary, your blocked Type 3 ICMP by itself means nothing, we need to find a real definition of the problem, which will extend deeper than these packets.

[mschwab]

OK, so I think I started with a bad example with these Type 3 messages.  Those occurred when the voice chat in Everquest 2 was NOT working, and voice application was obviously trying to do crazy things.

Last night voice chat WAS working, although as usual I have to disable/re-enable voice chat several times before I can switch voice channels, or get it where I can hear them and they can hear me.  And I watch Task Manager to be sure that the EQ2VoiceService.exe process doesn't get spawned multiple times.  But each time I disable/re-enable voice chat (or at about that time) these kind of messages appear in the 825 log:

Blocked outgoing TCP packet from 192.168.0.3:4344 to 70.42.62.154:443 as PSH:ACK received but there is no active connection
Blocked incoming TCP packet from 70.42.62.154:443 to 192.168.30.53:4363 with unexpected sequence 3534148511 (expected 1647742096 to 1647806336)

Now I should mention that a gazillion of these kind of message appear in the log, but the rest involve IP addresses that are all over the place, having nothing to do with me, Vivox, or Everquest (Sony).  I presume that these indicate that the 825 is doing it's job protecting me from hackers?

But I picked out these 2 because 70.42.62.154 is one of the IP addresses registered to Vivox, the 3rd party voice application that is working with Everquest2.  In the case of these Vivox IP addresses, what do you think these message indicate?  Back to my original question, if I wanted to allow these IP addresses to "get through" the 825 (not be blocked), how would I do that?

Also, my network-savvy neighbor was deeply puzzled and disturbed by the "port-mapping" that seems to be implied in these messages.  How does port 443 on the outside IP address get mapped to 4344, 4363, and other various ports on the local network?  We have not entered any port forwarding into the 825 settings.  He thought it might be a firmware bug.  I'm at the original 1.01, and the 825 firmware page insists that is the current version when I press "Check version".  And after reading all the warnings here about 1.11 I certainly hesitate to upgrade.

[Fatman]

I will start with your last point first, there is no port forwarding here, a (somewhat) random source port is used by a host attempting to open a TCP connection, the destination port is the one that people know and love.

Blocked outgoing TCP packet from 192.168.0.3:4344 to 70.42.62.154:443 as PSH:ACK received but there is no active connection
Blocked incoming TCP packet from 70.42.62.154:443 to 192.168.30.53:4363 with unexpected sequence 3534148511 (expected 1647742096 to 1647806336)

In this case in the first packet your PC is the source and chose a (somewhat) random port (4344), the remote IP is the destination and so a well known port is used (443 which is commonly used for HTTPS).

In the second packet the remote side is still the destination, but it is sending a return packet, it should be noted that this is an entirely different connection (judging by the different local side ports.

This logging is also interesting in that it happens after NAT, but that is just a interesting thing to note for the time being, it bears no relevance.

Now for why these packets are being blocked.

The first one is our of sequence, TCP connections normally use a 3 way handshake (SYN, SYN/ACK, ACK), this log message informs you that the software on your PC jumped to ACK without a SYN and SYN/ACK passing through NAT.

The second packet has an out of range sequence number (this one is more likely to be cause by confused connections than anything else).  The sequence number is one of the fields in the TCP header that is used for both connection integrity purposes as well as a certain amount of security.  In order to join the conversation a middle man would have to know the correct sequence number, which is unlikely.

The solution is to turn off SPI and endpoint filtering, this will allow at least the first packet through, and it might the second as well.  It should be noted however that they were both dropped because they are examples of packets that should never happen if the TCP standard is followed.  Such malformed packets have been used in attacks in the past, this is why the default action is to drop them.  Someone is playing fast and loose with the rules here, and it does not bode well for your VoIP application.

[mschwab]

Thanks, Fatman, I sent your last 3 paragraphs on to Sony, since it appears that Vivox is the one playing "fast and loose" with the rules here.

Considering I get a zillion similar blocked messages from other IP addresses in the log, and those are presumably hackers, there is no way I would want to turn off SPI and let all of those other hackers get in!

(SPI is different from SIP, right?  SIP I have turned off because of some other SIP ALG errors I got before.  I just turned SIP back and I no longer get those errors anyway.)

Here is some more information from Sony you might find interesting:
From SOE:
" What we found is that apparently Vivox is now using packets that exceed the maximum size for most routers. That is causing many routers to block them or break them apart. Because of that, the only real solution would be to install firmware that increases the size limit (not always possible) or to bypass the router entirely. We are referring the customers that are still having a problem to install their routers newest firmware. You will have to go to the manufactures website for support, I would direct you but I am unsure of the type of router you have. If you need help please let me know the router make and model and I will get you what they recommend. Then you will want to download your routers firmware by clicking on the type of router you have from the list. If this does not help you might have an older router that will not support all this information that the packets are giving. I am sorry about this we do know it is a know problem with a few of our customers and we are working to get a solid answer. I do hope that with the update to your firmware that it resolves the issue at hand. Please let me know if there are any other problems or concerns with your Voice Chat."

They are referring to a setting called MTU, which is limited to 1500 on the 825.  Vivox VC is apparently using larger packets (1557).   Do you agree with their statement that new firmware for routers should allow for packets > 1500?   Or you you think that Vivox should instead get their packet size back under 1500?  (Again, I am not interested in "upgrading" the 825 firmware at this time!

[Fatman]

The MTU of Ethernet (IEEE802.3) is 1500, to can't be set larger (see footnote).  Sony is either not being clear on what they mean or don't understand what is happening here, or are being intentionally deceitful (the last option I would suggest too loudly without better proof).  Now some WAN type use an MTU smaller than 1500 (PPPoE at 1492 for example), but this doesn't explain out of sequence packets.

SIP is Session Initiation Protocol, it is commonly used for VoIP.
SPI is Stateful Packet Inspection, it is a security measure that maintains a list of the connection status of every open connection so that illegal packets can be dropped.

Footnote:  Every communication technology has it's own MTU, some technologies are used in conjunction with others that have different MTUs, in this case the smallest MTU is the one that should be used on all stacked protocols.  For most type of connections MTU is implicit and not a setting.  In Ethernet (IEEE 802.3) networks the MTU is adjustable and capped at 1500 by the IEEE 802.3 standard.  It is important to note that there is a newer standard for gigabit networks allowing higher MTUs (up to 9000) but that does not apply for WAN technology.

[mschwab]

I still have not gotten an answer to the original title question of this thread.  If I want to "allow" a particular IP address to "get through" the 825, how do I do that?  Or a particular port number, or a range of port numbers or a range of IP addresses?

Perhaps related:  Now that I have enabled SIP again, after a day or so these messages started appearing in my log again:
[INFO] Wed Jul 15 12:28:05 2009 SIP ALG rejected packet from 70.42.62.15:5062 to 192.168.30.53:8096   
[INFO] Wed Jul 15 12:28:03 2009 SIP ALG rejected packet from 192.168.0.3:8096 to 70.42.62.15:5062   

So, could you tell me how I might allow packets to or from 70.42.62.15 (Vivox.com) to get through the firewall?  Or port 5062?

[Fatman]

You don't allow particular IPs to "get through"  its an all or nothing.  And the entire LAN net gets full WAN access via NAT.


The only way to bypass the SIP ALG is to disable it.

[mschwab]

OK, I'm getting more frustrated with these non-specific answers.  Are you telling me that with all the many confusing pages of advanced settings on the DLink 825, listing IP address ranges and ports, that there is no way to use all these settings to allow IP addresses or ports to go through?  Then what is the point of the settings?

I came here looking for some basic tutorials about how to use the setting pages.   Please forget SIP (I have disabled it again) and Type 3.  For example, the Sony support page has this info stickied:

• Try turning off your firewall. If that fixes the problem, then open the following ports on the firewall:
• Incoming UDP ports 3478, 5060,5062
• Outgoing TCP port 80 and 443
• All destination UDP ports 12000-16000

So, if I want to "open the ports" as described above, on the DLink 825, how would I go about doing that?

[Fatman]

Ok, we have had some misunderstandings here.  And I would prefer to call my answers overly-specific not non-specific, I am not Lycan after all.

• Incoming UDP ports 3478, 5060,5062

These are those port forwards and other settings you mentioned.  What I was trying to say in my last post though is that you do not "allow IPs through" you allow anyone through over that logical port.  Please see the below.

http://www.dlink.com/support/faq/?prod_id=2805

• Outgoing TCP port 80 and 443

This is what the second half of my last post was about, outgoing traffic is only denied by ALGs or similar tactics, it is all allowed out and it is hard to change that fact.  Also this list of outgoing ports is completely wrong if they have SIP in play.

• All destination UDP ports 12000-16000

I assume they mean that these should be allowed in both directions, see the first two points.