Hello all,

I've tried searching before posting, but solutions either don't work or use-case is not covered. In any case, I apologise in advance if there's well known solution already.

So, I have RB4011iGS+5HacQ2HnD-IN, configured PPPoE to my ISP, IPSec and DoH. Single bridge, all configurations done following official guides, firewall rules included for sec hardening.

I can access Internet, everything's encrypted, unnecessary services disabled, using 6.48.6 LT etc. But, devices on LAN can not talk to each other using local network/switching, they can only access Internet. What is needed, for traffic between LAN IPs to work AND also to have access to Internet, at same time?

Regards,

一些阅读后解决,防火墙是如何工作的,modified 'mark connection' and 'mark routing' in pre-routing chain of mangle rules to only apply when destination address is not subset of LAN IPs used by DHCP server.

There are lots of ways to get this done in RoS. Solved yes, but solved optimally........... I have my doubts.

Well, it's a progress for someone who is new to RouterOS =)
In any case, I am open to suggestions - yes, I am pretty sure it's not the most optimal solution (static list instead of dynamic one), but it works.

Usually a diagram helps and also the complete config.

/export file=anynameyouwish ( minus router serial number and any public WANIP information).

Attached

There are some minor issues but the major issue is your NordVPN.
What is the purpose of the NORD VPN, all users are sent out NORD VPN for internet?
Not sure how as I dont see any routes for that unless its accomplished in vpn settings.....

As far as I understand it, packets are marked in pre-routing chain, and sent to WAN interface by default, using srcnt rule, and yes, it's part of template in IPSec config. What I did was simply add condition that packets are marked only if their destination IP is not LAN (ie, machines in local network are trying to reach either the router itself or Internet). Not sure if this can be done differently, just followed official IPSec setup and VPN works, verified.

All you are doing is duplicating what is already done.
Ipsec routing supercedes normal IP routes so no need to mangle for them.

The problem I see is how do you get LAN users to see each other etc and not go out the ipsec tunnel.

Requirements ( confirm please )
a. all users on single subnet lan should go out iPSEC for internet
b. if ISPEC is not working should we assume local users can go out local WAN for internet?
c. all users should still be able to see each other.

All correct except for point B, there should be a killswitch in case VPN fails, ie users can not go to Internet (packets sent to blackhole).

Have you thought of using wireguard instead of ISPEC.
I dont think I can be of further use here...........

a. faster
b. easier
c. no kill switch needed

NM the idiots at Nordvpn dont offer wireguard................ they probably use betamax at home too.

Wireguard was indeed first option considered (eg ProtonVPN), but from what I read about it, it requires RouterOS v7 and there's no LT release yet in that branch.
NordVPN on the other hand has the greatest selection of servers available. Performance wise, there's very little effective BW drop, cca 10-15%, depending on server used. All in all, a good compromise.

Okay I got advice from an ipsec guru, since I am allergic to anything requiring real networking knowledge................

No mangling required, it can in most cases be solved more elegantly withiin ipsec settings.
I just have to fire up a temp ipsec on my router to see it.....

Okay this is a sample of a local subnet 192.168.88.0 going out an ipsec tunnel.
The correct tab menu for this is POLICY.
Order is important, we ensure that local users can reach other local users

/ip ipsec policy
addaction=nonedisabled=nodst-address=192.168.88.0/24dst-port=any peer="" protocol=allsrc-address=192.68.88.0/24src-port=any
add disabled=no dst-address=0.0.0.0/0 group=default proposal=default protocol=all src-address=192.168.88.0/24 template=yes {you should have this already in place}

Hmm I see your policy is problematic as well besides need the additional config line,

There should be no need for 0.0.0.0 as source address that is not accurate and it should be your subnet.
However that only applies to real ipsec, and not through 3rd party ipsec, so no need to change it, although I would for accuracy.

Fixed a small typo, src-address should be 192.168.88.0/24, not 192.68.88.0/24.
In any case, it works with proposed changes, it simply bypasses the IPSec tunnel completely, Thank you!

It just seemed wrong to have such twisted rules for a normal ipsec connection and thus why searched for a better way, glad it worked out for you.