2 issues Firewall rule defconf: drop all not coming from LAN stops L2PT traffic, different subnet masks

beginner to mikrotik. running a RB4011iGS+RM
I have a remote client L2PT set up, can connect remotely, but am unable to do anything outside of ping both ways. Cannot access any network resources. Have noted 2 things,

I enabled logging on all drop rules and found “defconf: drop all not coming from LAN” is the offending rule.
error “drop local input: in: out:(unknown 0), proto UDP, 192.168.88.239:137->255.255.255.255:137, len 78” and several variations of this.

Second issue i noticed is that my network subnet is 255.255.255.0, but client always gets 255.255.255.255
my ip pool for client is 192.168.88.235-240, but i have not found a way to issue/change subnet mask.

even if i disable this rule, i still have some issues, but i am not sure the different subnet really matters or if it is the issue. reading on this firewall rule, i have read it is not one to disable. I have also searched and tried to rewrite the rule and it always seems to leave me open. Since i saw this was the most common issue when searching, yes proxy-arp is enabled on ether2, even tried local-proxy-arp.
thanks in advanced

You don’t need to care about input, it’s traffic to router itself and client doesn’t really need anything there. Your problem is forward. It can’t be completely broken when ping works. But nobody will be able to tell you much without seeing your config, it would have to be only lucky guess.

what all do you want? Here is firewall.

mar/25/2020 16:09:48 by RouterOS 6.46.4

software id = WXJI-ABF4

model = RB4011iGS+5HacQ2HnD

serial number = xxxxx

/ip firewall filter
add action=accept chain=input comment=
"defconf: accept established,related,untracked" connection-state=
established,related,untracked
add action=accept chain=input comment="L2PT: Accept IPsec-esp" in-interface=
ether1 log=yes protocol=ipsec-esp
add action=accept chain=input comment="L2PT Accept UDP" dst-port=500,1701,4500
in-interface=ether1 log=yes protocol=udp
add action=accept chain=input comment=
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop invalid" connection-state=
invalid log=yes
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN"
in-interface-list=!LAN log=yes log-prefix="drop local"
add action=accept chain=forward comment="defconf: accept in ipsec policy"
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy"
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack"
connection-state=established,related
add action=accept chain=forward comment=
"defconf: accept established,related, untracked" connection-state=
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=
invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed"
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=
out,none out-interface-list=WAN

There’s nothing wrong (*) in what you posted, unless your WAN list contains something it shouldn’t. For example in another thread, user had problem with detect internet adding L2TP interface to WAN list, but I don’t think it’s enabled by default and it would block ping too.

Check what exactly happens. You can use Tools->Torch to watch packets on interface, so check what comes from client (on L2TP interface), then if it passed through router and continues to destination (on LAN interface). You’ll also see if target device responds.

(*) Ok, there is, but it doesn’t cause the problem. You want to accept only encrypted L2TP packets:

/ip firewall filter
add action=accept chain=input comment="Accept UDP for IPSec" dst-port=500,4500 in-interface=ether1 protocol=udp
add action=accept chain=input comment="Accept UDP for L2TP" dst-port=1701 ipsec-policy=in,ipsec in-interface=ether1 protocol=udp

thanks for the updated rules code. its replaced my old one.
I’m afraid nothing else has changed

drop local input: in: out:(unknown 0), proto UDP, 192.168.88.238:137->255.255.255.255:137, len 78

this fills my log while torching. i do not get anything between client and server. Still can’t access network drives or assets.
should i just add an allow and forward rules for my IP range for L2PT or would that make a hole?
If you think itsa in a wan config, what info do you want from wan?

Access from VPN should be allowed already. When you torch on , do you see anything from client to LAN? If not, then it’s the client you need to fix. What is it, Windows, something else? Check what routes it has, if it knows where your LAN is.

I reset the config, and redid it from scratch. I can now connect, ping, torch, and do see activity on both sides, buit i still cannot see shared resources thru the tunnel. at this point, my guess is either a routing table issue, or config issue on the windows side. If you have any other advise to offer, i would appreciate it.

If you can ping devices in LAN, then routing is ok. I’d check firewall of target devices.