Hi all, I have several locations, each connected by a Sonicwall VPN through PPPOE DSL, with Snom 360 phones. I've found that I have to tweak the Asterisk server MTU (inside one of the firewalls) to get everything to work "just right". Set the server MTU too low, and the Snom phones don't communicate correctly anymore. Too high and the phones work, but the server can't access the web (for yum updates, for example). So I've settled on an MTU of 1448. Has anyone else struggled with this? What did you settle on? - Mike
> I have several locations, each connected by a Sonicwall VPN through > PPPOE DSL, with Snom 360 phones. > > I've found that I have to tweak the Asterisk server MTU (inside one of > the firewalls) to get everything to work "just right". Set the server > MTU too low, and the Snom phones don't communicate correctly anymore. > Too high and the phones work, but the server can't access the web (for > yum updates, for example). > > So I've settled on an MTU of 1448. > > Has anyone else struggled with this? What did you settle on?I've not experienced the problem with asterisk (but that's because I've not implemented anything as yet behind a Sonicwall). Sonicwall does have a problem with the mtu when using pppoe, and that problem has been around for several software releases. Not sure why they can't get it right, but they can't. The limited testing that we've done suggests the mtu that you've picked is reasonable. However, you'll still run into a problem anytime the user on the LAN side of the firewall hits a box on the outside that happens to be sending pkts based on a standard ethernet mtu. The only way to correct "that" is to change the mtu at the distant location. (Obviously, if that device is not under your control, it can't be fixed. It seems to only be an issue with large udp packets. Not seen the problem with tcp pkts.) We've sent detailed packet traces to the Sonicwall engineers specifically showing the problem, but that was about two years ago and the problem is still around.
Dr. Michael J. Chudobiak wrote:> Hi all, > > I have several locations, each connected by a Sonicwall VPN through > PPPOE DSL, with Snom 360 phones. > > I've found that I have to tweak the Asterisk server MTU (inside one of > the firewalls) to get everything to work "just right". Set the server > MTU too low, and the Snom phones don't communicate correctly anymore. > Too high and the phones work, but the server can't access the web (for > yum updates, for example). > > So I've settled on an MTU of 1448. > > Has anyone else struggled with this? What did you settle on?Actually the maximum MTU varies from ISP to ISP. Usually, they will advise you when you subscribe. It's not only Sonicwall. In my previous job, we'd the same problem with a Cisco Soho DSL router. It can't do web with the standard MTU of 1500. The ISP advised us to change to 1476. I believe it's caused by the addition of PPPoE header to the frame. A standard Ethernet frame is 1500bytes. Adding the header to a full frame will cause the final frame size to exceed 1500, which causes fragmentation.
> I have several locations, each connected by a Sonicwall VPN through > PPPOE DSL, with Snom 360 phones. > > I've found that I have to tweak the Asterisk server MTU (inside one of > the firewalls) to get everything to work "just right". Set the server > MTU too low, and the Snom phones don't communicate correctly anymore. > Too high and the phones work, but the server can't access the web (for > yum updates, for example). > > So I've settled on an MTU of 1448. > > Has anyone else struggled with this? What did you settle on?Can you give a better description of your network? (ascii art is acceptable :) Just out of curiosity, what sort of MTU values were you finding 'too low', and on what interface were you setting it (I assume pppoe as you mention it above)? You can find that vpn tunnels break pmtu discovery (you are sending packets that are too big, but the 'packet too big' message gets blocked or lost so you never find out). Can you do a 'tracepath' to the remote phone? That will determine the mtu and tell you at each hop, and can show where packets are being lost. James