Node behind SonicWall Router

[Mike Bentzen]

Sounds like the Deep packet inspection in the sonicwall!

Turn off the deep packet inspection feature on the sonicwall and try again. In my experience, this feature breaks everything and doesn't do anything good.

Mike

Please excuse my brevity. Sent from my iPhone.

> On 29 Oct 2014, at 03:40, Lance Fredrickson <lancethepants at gmail.com> wrote:
> 
> Recently the small business I work at replaced an aging linksys wrt style router with a SonicWall one. Ever since this change I have issues with this node falling back to TCP constantly. TCP for me ends up performing very sub-par, and most of the time unworkable. For some reason too the connection usually ends up being routed through another node.
> 
> I created a new tinc instance using TAP (instead of TUN) between this work PC, and one other host. I then added an additional route command in tinc-up so the work node is aware of the other tinc network. This seems to work much better with the new router. I'm guessing the constant flow and overhead (arps and such)  of TAP is helping to keep the sonicwall device from dropping/closing the connection.
> 
> I tried playing with PingInterval and lowered it to 30 seconds while previously using tun so the work node might stay better connected. I didn't see any better results, maybe even lower is necessary.  If I were to try to use tun again, would this be the route to go? lowering the ping time? It seems like the connection needs more activity for the connection not to be dropped.
> 
> I also have seen that running "tinc dump subnets" while using TAP outputs the MAC addresses tinc is aware. The MAC addresses leading zeros end up being truncated. Not really anything detrimental, but was just wondering if this was unintended, and thought I'd bring it up.
> 
> Thanks,
> 
> Lance
> 
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc