Hi,

I've sent in a request to support a week or so ago and was told to upgrade from 5.15 to 5.16 and try again. Which I did, and still had the same problem:

I have a RB750GL that is using PPPoE to connect to the internet. I've configured OpenVPN Server on the same RB. I then try and connect from a remote Windows machine running OVPN. Result: the RB750's PPPoE session dies with repeated errors:

"could not add address: already have such address".

I see in Winbox, in the IP -> Address table the status shows "DI". Only if I reboot the router OR if I delete the Dynamic address does PPPoE start working again. Needless to say, I can't get the OVPN session to work, until we solve the PPPoE crashing problem first!

This problem has been duplicated both in my customers environment and, as of today, here in my lab with two other RB's running the latest 5.16 firmware.

Is anyone else able to duplicate this issue, or have found a work around?

Thanks,

-Rob

The problem seems to be related to static IP assigned by the ISP to to router. Since its the same IP each time the PPPoE session is negotiated, the address does not appear to be cleared from the Dynamic address table and this is causing the error. I've tested this on a dynamic address and non-PPPoE setup and it works fine.

Is there really no one using OpenVPN Server on RouterOS in a Static PPPoE environment?

Thanks,

-Rob

I have same problem with RouterOS 5.19f (rb751-2hnd).
Can anybody help?

I have same problem with RouterOS 5.19f (rb751-2hnd).
Can anybody help?

Getting similar bad results with ROS 5.20 on an RB2011L-IN acting as a border device providing Internet access over ADSL using PPPoE.

Whenever an OpenVPN connection is attempted on the public interface, (I am using Tunnelblick as a client) the PPPoE session crashes. PPPoE recovers ungracefully by reconnecting but also leaving the box in an inconsistent state: the previously ISP assigned address remains in the address table as well as the corresponding entries in the routing table. DynDNS update scripts stop functioning as well. Needless to say, the OpenVPN connection is not established.

Regarding Rob's latest remark, about a static IP assigned by the ISP to to router, I find that this is not the case. In my tests the IP is renewed on each PPPoE client reconnect.

Bottom line, the OpenVPN server currently serves as a first grade DoS vulnerability and not much else. Workarounds, fixes, advice much appreciated

B.

Guys - can you check and tell me if:

a) In your Firewall -> Mangle rules, your PPPoE connections have properly created the dynamic change MSS actions? This is the default if you are using the "default" profile under PPP and of course, you didn't change the "Change TCP MSS" to something other than YES, in that profile.

b) Check to see if ANY Mangle rules have Passthrough set to "NO" - especially if they appear ABOVE the dynamic MSS change rule(s).

Let me know what you find!

Thanks,

-Rob

Your problem seems to be similar to my: http://forum.mikrotik.com/viewtopic.php?f=2&t=65424 - looks like VPN servers are little bit screwed. There is also solution for recovery in my posts recommended by support.

a) Mangle rules include the dynamic MSS actions. Using the default profile for PPPoE and have not made any changes. Confirmed that "Change TCP MSS" is set to "YES".
b) At the time no other mangle rules where active.

5.23 seems to have sorted out the PPPoE crash issues. OpenVPN on the RB2011L-IN is no longer a DoS vulnerability but IMHO Mikrotik has still a very long way to go in order to sort out it's (Open) VPN business. Currently the implementation is barely above "proof of concept": TCP only, without CRL checking, no compression and no pushing of routes. Good luck if you need to manage anything more than 2 remote access clients.

B.

5.23 seems to have sorted out the PPPoE crash issues. OpenVPN on the RB2011L-IN is no longer a DoS vulnerability but IMHO Mikrotik has still a very long way to go in order to sort out it's (Open) VPN business. Currently the implementation is barely above "proof of concept": TCP only, without CRL checking, no compression and no pushing of routes. Good luck if you need to manage anything more than 2 remote access clients.

B.

I have similar problem with 6.35.2, if I change anything on openvpn window, pppoe stop working..