To be clear you are attempting to connect to a third party VPN provider?
Not sure what that has to do with your phone, as either.
a. you are connecting to proton with your router and ISP connection and then selecting which users use the tunnel
OR
b. you are connecting your phone via cellular and wireguard app to the proton wireguard
I will assume we are talking a. ( mainly because your router is not WIFI so not sure how it could get a LANIP ?? unless you have a wifi device attached to the router in which case a. still applies )
The other thing is you are using IPV6, which I know didly about so all my advice is based on normally an IPV4 based network.
Therefore I am confused as to why you have DHCP servers, why you have NAT etc............ I thought that all goes out the window with IPV6....
Thus will assume you dont actually use ipv6
Observations:
1. It is probably not a good idea to use 10.2.0.1 for an external DNS server on your settings. That DNS is specific to PROTON and will potentially screw up the rest of your LAN.
Suggest
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,9.9.9.9 etc.....
2. I do agree for traffic entering the tunnel that traffic should be using 10.2.0.1, so how to make that happen?
3. Missing one default rule that normally should be there that the router uses itself so add it in.
/ip firewall filter
add action=accept chain=input comment="accept established,related" \
connection-state=established,related
add action=drop chain=input connection-state=invalid
add action=accept chain=input protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback" dst-address=127.0.0.1
add action=accept chain=input src-address-list=allowed_to_router
add action=drop chain=input
4. Placing any rules after the drop rule in the input chain makes zero sense............... No traffic goes past this rule its ALL DROPPED .
So change the order (if you noted I already slighlty modified your order above, default rules first, then admin rules...........then drop )
What this reveals is a mess in the input chain, duplicates etc..................... needs to be cleaned up!!!!!
/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" \
connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback" dst-address=127.0.0.1
add action=accept chain=input comment="allow Winbox" in-interface=local \
in-interface-list=static port=8291 protocol=tcp src-address-list=\
Authorized
add action=accept chain=input comment="allow SSH" in-interface=local port=\
2200 protocol=tcp src-address-list=Authorized
add action=accept chain=input src-address-list=allowed_to_router
add action=drop chain=input
However even this is not quite right but close. The problem is you think you are limiting winbox to a select few, which you are not,
because you have have the allowed to router rule, basically your entire subnet, then the entire subnet has access to winbox.
The idea is to only allow the entire subnet for distinct services, typically DNS, so lets do this instead.... Keep all the default rules above and for the last four rules:
add action=accept chain=input comment="allow Winbox" in-interface=local \
in-interface-list=static port=8291 protocol=tcp src-address-list=\
Authorized
add action=accept chain=input comment="allow SSH" in-interface=local port=\
2200 protocol=tcp src-address-list=Authorized
add action=accept chain=input src-address-list=allowed_to_router dst-port=53 protocol=udp
add action=accept chain=input src-address-list=allowed_to_router dst-port=53 protocol=tcp
add action=drop chain=input
Thus only those on the Authorized list can access winbox and port2200 and the lan users can only access DNS services.
Now, for authorized users aka the ADMIN you could simplify the two rules to this:
add action=accept chain=input comment="Admin Access" in-interface=local src-address-list=Authorized
5. Wireguard settings seem fine!
6. Table seems fine
7. wireguard IP address is fine , although I typically use /24 for all addresses.
8. Yikes just got to the forward chain, it would seem you are more concerned with ICMP then actual needed traffic and I recommend you simply remove all that nonsense.
Also made the wan nat rule much clearer to read by splitting it into two rules..
add action=fasttrack-connection chain=forward comment=\
"fast-track for established,related" connection-state=established,related \
hw-offload=yes
add action=accept chain=forward comment="accept established,related,untracked" \
connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward comment="internet traffic" in-interface=local out-interface=ether1
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="Drop All Else"
Thus basically stating, keep the needed default rules, allow LAN to WAN traffic, allow port forwarding (disabled if not using) and then drop the rest of any possible traffic. Similar to the input chain rule.
Now whats missing??
Answer: Allowing traffic to enter the wireguard tunnel:
add action=accept chain=forward comment="internet traffic" in-interface=local out-interface=ether1
add action=accept chain=forward comment="permission to enter tunnel" in-interface=local out-interface=protonWG
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="Drop All Else"
You could refine the bridge entry by replacing it with source-address list of IPs that need to enter the tunnel, but
remember only the IPs you ROUTE to the tunnel can reach the tunnel anyway. Firewall doesnt tell traffic where to go it simply blocks it or doesnt.
add action=accept chain=forward comment="permission to enter tunnel" src-address-list=VPNsecure out-interface=protonWG
9. IP router for proton wireguard looks fine, matches up with the Table created.
10. THE SOURCENAT RULE is WRONG......... I am not sure how you came up with that ??? The idea is simply to give every local user going into the tunnel the (source) IP address of Wireguard on your router, so that the proton server at the other end wont reject the traffic.
from:
/ip firewall nat
add action=masquerade chain=srcnat out-interface="ether1[internet]"
add action=masquerade chain=srcnat out-interface=protonWG routing-mark=\
USEproton src-address-list=VPNsecure
TO:
/ip firewall nat
add action=masquerade chain=srcnat out-interface="ether1[internet]"
add action=masquerade chain=srcnat out-interface=protonWG
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
11. Now comes the time that we glue together the config above in terms of forcing traffic out the tunnel.
IN this case, with one or two devices, the easiest path are routing rules.
You willl need a rule per user............
/routing rule add src-address=IPaddressof NAS action=lookup table=USEproton
/routing rule add src-address=IPaddressofPhone action=lookup table=USEproton
Note: Use action=lookup-only-in-table IF, you do not want the phone or NAS to fall back to using local WAN, in case the tunnel stops working.
12. YOu should add one mangle rule to ensure smooth traffic flow, no bumps due to MTU mismatching:
add action=change-mss chain=forward comment="Clamp MSS to PMTU for Outgoing packets" \
new-mss=clamp-to-pmtu out-interface=protonWG passthrough=yes protocol=tcp tcp-flags=syn
13. Finally we still have the issue of the DNS for proton, suggesting the following to force that traffic as well.
/ip nat
add chain=dst-nat action=dst-nat in-interface-list=VPNsecure dst-port=53 protocol=tcp out-interface=protonWG to-address=10.2.0.1
This states that for any users on the list that are going out the WG tunnel, their traffic requests for DNS will be sent to 10.2.0.1 and not to the local router.
I am not 100% if this is necessary but should work.
Please confirm that 10.2.0.1 is what Proton gave you to use for DNS ( and you didnt make it up on your own ).
