I am more and more convinced that @JordanR and @Cvan are talking about dynamic interfaces. Not static ones which I earlier identified as most probable solution.
In both cases (both dynamic and static), the interface is marked as as "PPTP/L2TP/SSTP Server Binding" so it may be not easy to understand, however if you check the flag, it will be clear.

I tested both situation with SSTP and PPTP and it simply did not occur as long as I used manually created server binding. I have FW rules bound to Server Binding in my normal config, I on purpose created route and it worked despite disconnecting/reconnecting.
I also replicated exactly same result as those two (i.e. broken FW rules and broken routes) when I left the interface to be dynamic.


Let me give you example config:

Code: Select all

/ip pool add name=pool2-VPN ranges=10.100.1.191-10.100.1.199
/ppp profile add local-address=10.100.1.254 name=VPN remote-address=pool2-VPN
/ppp secret
   add name=Adam password=test profile=VPN service=pptp
   add name=Betty password=test profile=VPN service=pptp
/interface pptp-server server set default-profile=VPN enabled=yes
/interface pptp-server add name=BettyVPN user=Betty

Magic happens on last line of that code, where I am manually creating server binding, which stays as a existing (but not running) interface even if Betty disconnect. Once Betty reconnects, interface goes back to running state and keeps same internal ID which is linked to firewall rule or routes...
If both Adam and Betty connects, I can print something like this:

Code: Select all

[admin@mikrotik] > /interface  print where type="pptp-in"   
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                TYPE       ACTUAL-MTU L2MTU  MAX-L2MTU MAC-ADDRESS      
 0 DR  <Adam>                              pptp-in          1500
 1  R  BettyVPN                            pptp-in          1500

Now lets block both of them access to rest of local network:

Code: Select all

/ip firewall filter 
   add action=drop chain=forward dst-address=10.100.1.0/24 in-interface=<Adam>
   add action=drop chain=forward dst-address=10.100.1.0/24 in-interface=BettyVPN

at the moment, it works. But once they disconnect, following will happen:

Code: Select all

[admin@mikrotik] > /interface  print where type="pptp-in"   
Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                                TYPE       ACTUAL-MTU L2MTU  MAX-L2MTU MAC-ADDRESS      
 0     BettyVPN                            pptp-in          
 
[admin@mikrotik] > /ip firewall filter export
 ...
# no interface
add action=drop chain=forward dst-address=10.100.1.0/24 in-interface=*F00110   
add action=drop chain=forward dst-address=10.100.1.0/24 in-interface=BettyVPN

See? Adam's rule got broken because his interface does not exist anymore. It is actually not linked via name (that is just displayed as user-friendly description) but link happens via internal ID, in this case it was F00110. Once Adam connects again, he won't get same ID again despite the fact that his dynamic server binding will have same name.
Same would happen for routes.

Please, lets focus on those interfaces - whether they are dynamic (automatically created when client connects) or static (manually created by admin)

I knew the answer would eventually surface!