… and the reason why I made my remark about those lists…
Yup, Concur. one shouldnt make changes unless.
a. one understands what each line does,
b. one understands that the config is the sum of its parts and interrelated.
Hello Mr jvanhambelgium..!
so clearly enough it seems that i have a DNS problem in my config and i don’t know in which side..so please can you clarify more what you mean by this sentence “make sure your Mikrotik is configured correctly then to allow this Wireguard-client to make DNS-lookups,”
how can i enable this DNS lookup on my mikrotik device..?
Hello Mr anav…so the connection is active again.. if you want to add any info or advise i am listening . go a head..
Hello Mr jvanhambelgium..!
so clearly enough it seems that i have a DNS problem in my config and i don’t know in which side..so please can you clarify more what you mean by this sentence “make sure your Mikrotik is configured correctly then to allow this Wireguard-client to make DNS-lookups,”
how can i enable this DNS lookup on my mikrotik device..?
[/quote]
Remember that once packets exit the “wireguard” interface there is the aspect of firewallling!
So in your wireguard-config you provide 192.168.1.1 to the client as DNS to use. Fine, no problem with that.
Now ARE the packets from the wireguard-client ALLOWED to talks to the 192.168.1.1
TEST1 : Setup/Activate your wireguard on Android and use “ping” tool. Can you ping 192.168.1.1 ?!
192.168.1.1 = Your “LAN” and your Wireguard is not part of that so you cannot just think you can reach any network-destination.
What are your current firewall rules for input/forward chains ?
Yes post COMPLETE config
/export (minus serial number and any public WANIP info)
Remember that once packets exit the “wireguard” interface there is the aspect of firewallling!
So in your wireguard-config you provide 192.168.1.1 to the client as DNS to use. Fine, no problem with that.
Now ARE the packets from the wireguard-client ALLOWED to talks to the 192.168.1.1
TEST1 : Setup/Activate your wireguard on Android and use “ping” tool. Can you ping 192.168.1.1 ?!
192.168.1.1 = Your “LAN” and your Wireguard is not part of that so you cannot just think you can reach any network-destination.
What are your current firewall rules for input/forward chains ?
[/quote]
no i can’t ping 192.168.1.1..
so this is my firewall rule
ip firewall filter
add action=accept chain=forward in-interface=wireguard2 out-interface=ether1
add action=accept chain=input comment=“allow WireGuard” dst-port=47333
protocol=udp
add action=accept chain=input comment=“allow WireGuard” dst-port=13231
protocol=udp
add action=accept chain=input comment=l2tp-ipsec in-interface=ether1 protocol=
ipsec-esp
add action=accept chain=input comment=ipsec in-interface=ether1 protocol=
ipsec-ah
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=return chain=detect-ddos dst-limit=32,32,src-and-dst-addresses/10s
add action=add-dst-to-address-list address-list=ddos-target
address-list-timeout=10m chain=detect-ddos
add action=add-src-to-address-list address-list=ddos-attackers
address-list-timeout=10m chain=detect-ddos
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input dst-address=127.0.0.1
add action=drop chain=input connection-state=invalid
also maybe that can make more sence for you
this is my complete config.
MRT.rsc (5.48 KB)
add action=accept chain=forward in-interface=wireguard2 out-interface=ether1
What is this supposed to do ? Adapt this rule, remove the “out-interface” critera to start.
You have a generic “masquerading” rule that will NAT everything going out via “ether1” , so I don’t understand why the above rule is needed.
Did this rule ever had any hits ?
Now, on the DNS part => 192.168.1.1 = Mikrotik “interface” itself (on which you want DNS resolving)
Hence you must have on your INPUT-chain a rule allowing that! Try to add the rule in bold allowing traffic from the wireguard2 interface to “hit” your Mikrotik interface(s)
(finetuning can be done later, first get it working)
/ip firewall filter
add action=accept chain=input in-interface=wireguard2
add action=accept chain=input comment=“allow WireGuard” dst-port=47333 protocol=udp
add action=accept chain=input comment=“allow WireGuard” dst-port=13231 protocol=udp
add action=accept chain=input comment=l2tp-ipsec in-interface=ether1 protocol=ipsec-esp
add action=accept chain=input comment=ipsec in-interface=ether1 protocol=ipsec-ah
add action=accept chain=input connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input dst-address=127.0.0.1
add action=drop chain=input connection-state=invalid
Retest that ping ?
Your firewall rules are pratically non-existant and thus should SHOULD pass everything through. This is a blind terrible approach.
The better approach is to use the deafult rule set with drop rules at the end of both input chain and forward chain. In that regard you know exactly what is allowed and everything else is dropped.
Much clearer and cleaner. (aka get rid of the disorganized noise you have)
BUT FIRST!!! you need to add interface list and interface list members so the rule can be properly applied.
Add these rules…
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface list member
add comment=defconf interface=ether1 list=WAN
add interface=LTE name*** list=WAN ( whatever the interface name is that gets the WANIP, sometimes its just ether1 )
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=WLAN1 list=LAN
Now for the firewall default rules that you should be using, and below that the rules you should add!!!
/ip firewall filter
{Input Chain}
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else" *****
{forward chain}
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=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN
…
In your case would add the following rules to the input chain:
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=127.0.0.1
add action=accept chain=input comment=“allow WireGuard” dst-port=13231
protocol=udp
add action=accept chain=input comment=“allow WireGuard” dst-port=47333
protocol=udp
add action=accept chain=input comment=l2tp-ipsec in-interface=ether1
protocol=ipsec-esp
add action=accept chain=input comment=ipsec in-interface=ether1 protocol=
ipsec-ah
add action=accept chain=input in-interface=wireguard2 comment=“allow admin to config router”
add action=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else
AND
In your case would add the following rules to the forward chain just before the last drop all rule…
add chain=forward action=accept in-interface=wireguard2 out-interface-list=LAN comment=“wg to LAN traffic”
add chain=forward action=accept in-interface=wireguard2 out-interface-list=WAN comment=“wg to internet”
add action=accept chain=forward comment=“allow port forwarding” connection-nat-state=dstnat
add action=drop chain=forward
Concur with the previous poster, the forward chain rule you have for wireguard to ether1 is useless.
You will note that I have added the proper input chain rule above, you were trying to construct, so that the admin can access the router for configuration purposes.
Also CHANGE on ANDROID settings. DNS server to 192.168.50.1
Hello My friends ..! So for everyone who share his advise or opinion in this discussion i want to say very thanksful for you …!
i didn’t solve the problem yet. i realised that the problem on my android device so when i create a wireguard interface in another devices with the same router and configuration, the connection work very well . so now i have to know what is the problem with my device, not with my mikrotik router.
very thanksful ..!
Ensure you let us know what the issue is when you find it please.
i will Mr anav..!
Hi, did you make any progress??