ICMP redirects

[ralph]

Has anybody got a clue how to block ICMP redirect messages on a Teleworker Server?

Interesting problem.   I have a TW in server/gateway mode.  (actually behind a firewall - NO NAT!)  A phone on the same subnet calls through the TW Server to any internal phone.  Hangs up after a few minutes ~2-15.   

Now, get this, only a problem on internal calls.   Never on exernal.   Same 3300, MXe.

A sniff shows a ICMP packet that says destination unreachable.   I get this on both sides of the TW server.   Appears to come from the TW server it self and not a switch or router.   I'd like to turn ICMP redirets off.   Any clues?

Ralph

[chadmaynard]

Are you familiar with iptables? Look at the chains that start with InboundICMP. There may be a few, because a new chain is created after every config change. To maintain the changes through a reboot or through an expand-template process (which happens when you configure the server using the menu or web user interface), you'll have to make the changes in /etc/e-smith/templates/etc/rc.d/init.d/masq, specifically the file 90adjustICMPIn.

Honestly I don't really understand what you mean by "A phone on the same subnet calls through the TW Server to any internal phone" .. What do you mean by a phone on the same subnet?

[ralph]

I found my answer:
Server# echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects [for IPv4]
Server# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects [for IPv4]
Didn't help though.

What do you mean by a phone on the same subnet?

I put a phone in the DMZ so I could be sure packets do not transverse the firewall.

Ralph

[chadmaynard]

Oh =) Yes it is expected behavior to send bogus redirects when an encrypted packet don't traverse the firewall (use the same interface). The teleworker is simply trying to get the hosts to stop using it improperly. These messages will go away when you move out of the DMZ.  The kernel doesn't realize what's going on because the RTC packets are encrypted.

[ralph]

Oh!  Now that is interesting.   I'm not excrypting my voice packets.  (From system options)   is there someplace I can turn this off at?

Check out the following:   We are trying to upgrade our 6510 to SP6 before rolling it out to customers.   When running SP6 calls consistantly cut off at 1.5 minutes.   When I heard about it I asked the tech to unplug the TW server next time he tried to upgrade.    The 6510 is on the same subnet as the TW server.  Below is the email he sent with his results.   

Ralph

We loaded the sp6 and turned on the tools needed to recover more detailed info. We were able to get it to fail consistantly 1min and 30 seconds into the call.
After that test I unplugged our teleworker from the network and repeated the test. The calls DID NOT FAIL. Plugged in the teleworker  back into the network and the calls started failing again. Scott still captured all the logs from the 6510 and 3300 and is sending them off to mitel (Bruces department). We put the vm back to sp5 for now because Ralph said the teleworker and Mobility run through that same server. So in conclusion the sp6 build seams to be fine it is a issue with either our network,the teleworker config. or the mitia integration between the teleworker ,3300,and 6510. This issue needs to be resolved before we can load sp6 back. But after this last test and what is being told to us by both Esna and Mitel the sp6 build looks ok.

[chadmaynard]

Is there any sort of IP address or proxy ARP conflict that is causing ARP poisoning on any of the involved hosts? make sure that the arp tables on each are correct and don't flap.

[ralph]

Where would you think I should check the ARP tables at?  Cisco or TW?

Ralph

[chadmaynard]

Everywhere you can. 6510, cisco, tw, etc. Anything that is related. try running a constant ping through one of the phones (via the PC port) and see if you loose the pings as well. Since there are so many hosts involved in your description you;ll have to pretty much rule them out one by one.

[Chakara]

  Did you see the article 08-5157-00024 from MOL?  ICMP redirects are normal function in certain setups - for example if you have a default gateway router, however the router you need for this particular packet on the same network as your device.   Then the default gateway router sends an ICMP redirect to tell your device where to send your traffic. 


  All of that said, the article listed shows that Mitel IP Phones may not handle ICMP redirects properly all the time.  This is an issue and possibly what you are seeing?

-Chak
 

[chadmaynard]

That's the cause of the first problem but isn't related to the dropped call issue. And the first thing wasn't really a problem anyway.