Thanks, there's a lot of helpful information there. However to start off ..
The topic title is misleading, more likely it is a case of the remote client being treated as WAN (or not LAN) rather than being detected as such.
I was saying "detected", because that is what the router logs, these are the final log entries as a client connects ...
12:37:28 l2tp,ppp,info <l2tp-L2TP-REMOTE>: authenticated
12:37:28 l2tp,ppp,info <l2tp-L2TP-REMOTE>: connected
12:37:34 interface,info <l2tp-L2TP-REMOTE> detect WAN
So once the connection has been so detected, and added to the WAN list it will be affected in exactly the same way by a rule that matches either "WAN" or "!LAN".
Alternatively add the VPN interface to the LAN interface-list. As the interface is created dynamically you can either use a server binding to create a static interface name (the historic way), or specify the interface list in the PPP profile for the VPN - this will dynamically add and remove the VPN interfaces from the specified interface-list.
This might be the answer, but it's not working quite the way I expected. If I specify Interface List LAN in the PPP profile, this doesn't stop the connection being detected as WAN, so the connection is in both lists. Presumably that means it will still match any rule specifying "WAN", but maybe it won't match "!LAN". I'm not sure on that, so will have to test.
> interface list member print
Flags: X - disabled, D - dynamic
# LIST INTERFACE
0 ;;; defconf
LAN bridge
1 ;;; defconf
WAN lte1
2 LAN *6
3 D ;;; LAN detected
LAN ether1
4 D LAN <l2tp-L2TP-REMOTE>
5 D ;;; WAN detected
WAN <l2tp-L2TP-REMOTE>
My goal here is to allow the remote client to access the network, so my understanding is that it has to be permitted (or not dropped) in the "forward" chain as well as "input".
Finally I am not clear on the server binding option, but I will look that up and give it a go as well.