Thanks msmatter, thats more of the inkling I had of what it means!
But dont understand how you are
a. detecting VPN is not working
b. removing the routing in place?? (stopping the flow)
For example with the routing rule above, for internet traffic, if the WG tunnel is down, then the traffic will simply get dropped. Whats the concern?
I see the need for failover, but I see none for kill switch. What scenario do you see that unencrypted traffic might leak out??
a) RouterOS does that by removing the Dynamic route. No manually work needed to be done.
b) yes the door slammed is close and while looking for an other exit the traffic fall into the blackhole. From where it never returns.
I can’t have traffic running around going for the Golden Gateway in the router and it is then better to put it out of its misery before things go wrong.
One question I have is how would you create the same blackhole effect if the primary WG route was manually put in and not created dynamically.
In other words that route would continue to exist???
Second question what is the use of preferred source mean to you??
Both of those rules makes no sense to me. What are you trying to achieve??
(1) Are you attempting to allow subnet users from a remote device go out your local WANIP for internet?
If so, the correct way to do this, is by forward chain rules.
examples
a. add chain=forward action=accept in-interface=WG-name out-interface-list=WAN { basic }
b. add chain=forward action=accept in-interface=WG-name src-address=IPHONE-IP out-interface-list=WAN { multiple peers and only one of the peers the iphone) is getting internet }
c. There is already an existing rule
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN
So add the wireguard interface as a LAN list member
add interface=WG-name list=LAN
Many many options but none of them involve the local WANIP directly.
In fact, the Wireguard interface is an interface that is roughly at the LAN level in terms of location/hierarchy. It is not intended to be part of the WAN interface and it would have to be a special case to make it so.
(2) Maybe you have an ISP router in front of the MT device and it is not aware of the WG tunnel and a static route on the ISP router is not possible.
In this case one creates a SOURCE NAT Rule so the traffic exiting the local tunnel heading for the internet is NATTED with the MT routers IP address, prior to reaching the ISP router.
(3) The missing link… you fill in what he purpose is ???
WHy? Can third party VPN servers not handle incoming traffic?
For example how would they handle
user a coming in for internet traffic and user b and user c. Wouldnt the Nord server just return traffic through the tunnel… What assumptions need to be made?
The only thing one should need to do on the MT device is put traffic into the tunnel… (Force ip route for internet traffic so it doesnt go out local WANIP)
To be sure that traffic does not go out the wrong exit I use that killswitch. I am not intrested that that traffic is going any where and so the hunting season is opened as soon the VPN goes down.
As far as firewall is concerned, WG interface is like any other type, and it’s definitely independent interface. VPN provider probably won’t be trying to connect to anything in your network, but in theory they could.
Why are you using mangled traffic in forward chain firewall rules and source nat rules??? Not necessary as one can use firewall address lists in firewall rules???
Hi Goodsat I just want to confirm that you are using a mikrotik device, that is behind an ISP router that you do not have control over.
Second that you are using a third party VPN for internet but only for a few devices, that should be directed out the third party wireguard tunnel for internet access.
Is this accurate or what am I missing??
Hello 404Network my RB4011 is connected as a nat router in sfp+10 gb on an operator box which is in bridge and yes I use a third party VPN for the Internet, but only for a few devices, which must be directed to the protection tunnel third-party wired for Internet access.