Page 1 of 1

VPN connect - feature request

Posted: Fri May 16, 2014 9:59 am
by SomeYoungGuy
I hope like crazy this gets to you guys at MikroTik .

When a VPN connection established please could you refresh (or something) the connections list (even "assured" connections), because if you are using SIP, the already established connections DO NOT update to using the newly established VPN connection even if the VPN routes directly apply to the connections that are established.

Here is the scenario: make a sip connection through the Mikrotik, then make a VPN connection for that SIP only by adding a route in the routes table to send the sip traffic over the VPN - easy right.

If that VPN is up 100%... you have no problems, but if it goes down, and the sip establishes a connection via the default route, it will never go back to using the VPN after the VPN is reconnected again.

Its so simple to fix, just find the sip connection in the connection table, remove it, and wait 10 seconds... done... but phew what a pain in the neck!

Wouldn't it to be possible (as part of the VPN connection code) that once a VPN is established it looks in the connections table and refreshes any connections that should be updated even if the connection is established and assured.

I'm not sure if this is the right place to post this - but please could someone at MikroTik read this! :)

Re: VPN connect - feature request

Posted: Sat May 17, 2014 11:14 pm
by scotthammersley
Are you using the "Check Gateway" feature? If that doesn't solve the problem, then post your config because that is an easy problem to fix.

Re: VPN connect - feature request

Posted: Tue Jul 15, 2014 5:00 am
by sanitycheck
Check Gateway seems to help if the outage on the remote end is fairly long. By that I mean >20 seconds where the Check Gateway feature can detect the link went down. An example would be a manual power-cycle of a cable modem.

If you get a port flap on the same modem, where the WAN port shows the modem was offline for just 2 or 3 seconds, Check Gateway doesn't help and SIP hangs up. That's not a surprise given the Check Gateway feature does 20-second increment pings.

I have the SIP helper turned off on the client side and disabled on the main office side (the phones register on custom port 5066 so the SIP helper does not affect them), so it's not a factor in my case. The SIP helper is active for my SIP trunk to the VoIP service provider out of the main office.

Actually I'm surprised Check Gateway works at all in the case of an IPSEC VPN gateway, because the gateway is bridge-local in most cases. Maybe Check Gateway is smart enough to know the real gateway address to ping?

Re: VPN connect - feature request

Posted: Tue Jul 29, 2014 9:02 pm
by sanitycheck
Turning off port speed auto-negotiation on the WAN port seems to reduce the occurrence of this problem considerably. This is true even though the frequency of Internet outages has not varied much at that location. This change does not eliminate the problem as of 6.19, however.

An older but similar customer installation never has this problem. ROS is 6.7 on both sides there.

Re: VPN connect - feature request

Posted: Fri Aug 01, 2014 7:26 am
by sanitycheck
I discovered disabling auto-negotiation as mentioned above eliminated a similar problem at a different customer site.

In that case a SIP trunk to a service provider would stop responding, even though connection tracker said the connection was up (also SIP helper is enabled there). This happened every few weeks, but it seemed by the logs to correspond with their DSL going down sometime earlier in the day (PPPoE reconnecting). Rebooting the router was required to fix the problem before. Since disabling auto-negotiation they never again had the problem. I made the change several months ago. Their router is on 6.14.