Mikrotik as ProtonVPN client - enspoints cannot use it's DNS

RouterOS Forwarding Protocols
1

Hi!

I have defined 2 VPNs on my Mikrotik: NordVPN and ProtonVPN

Long story short - I recently noticed that Nord cannot do port forwarding for a web server in my LAN, but Proton should do it. So I'm testing ProtonVPN to get rid of NordVPN.

But as for now Mikrotik sets NordVPN for 1 Win11 VM (running as normal endpoint) and ProtonVPN for my webserver.

Win 11 is attached directly to my home LAN: 192.168.1.0/24. To that LAN I have Sophos FW attached (192.168.1.10) and it provides DMZ subnet 192.168.3.8/29 (.9 - Sophos FW, .10 - Ubuntu SRV)

Ubuntu SRV 192.168.3.10/29 is defined on Mikrotik to use ProtonVPN

Because I needed 3 default routes to Internet I created 2 extra routing table (not VRFs): nordvpn and protonvpn - each pointing 0.0.0.0/0 via xxxVPN interface

I also use local DNS on that Mikrotik.

And here is the problem:

Win 11 gnerally works fine, it has access to Inet, it uses NordVPN connection, it does use local DNS correctly.

But Ubuntu SRV - also everything works fine except it cannot use Mikrotik as local DNS. Also it cannot ping Mikrotik at 192.168.1.1

shadow82@ubuntu-24:/mnt$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=5.55 ms

shadow82@ubuntu-24:/mnt$ ping google.com
[nothing]

shadow82@ubuntu-24:/mnt$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
[nothing]

shadow82@ubuntu-24:/mnt$ tracepath 8.8.8.8 -nn
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.3.9                                           0.144ms 
 1:  192.168.3.9                                           0.048ms 
 2:  192.168.1.1                                           0.860ms 
 3:  192.168.1.1                                           0.900ms pmtu 1420
 3:  10.2.0.1                                              3.333ms 
 4:  [ProtonVPN]                                           4.580ms 
 5:  [ProtonVPN]                                           4.493ms 
 6:  [ProtonVPN]                                           7.210ms 
 7:  no reply

I think Win 11 VM setup with NordVPN is very similar to the one prepared for Ubuntu SRV but I'm missing something...

Win 11 does ping 192.168.1.1 and use Mikrotik DNS service

Ubuntu cannot use it, cannot ping it but... tracepath do respond from 192.168.1.1 (?)

I tried to add on Mikrotik FW rule allowing to use DNS for Ubuntu SRV but it didn't help (Win 11 running in NordVPN table doesn't need that).

Sophos FW does not do any NAT and it's not blocking DNS queries (changing Ubuntu to 8.8.8.8 works fine)

When I do packet sniffing I see ~9 results per 1 ping from Ubuntu SRV (192.168.3.10) to MKT DNS (192.168.1.1). That's quite a lot -

image
image780×507 129 KB

I attach my MKT relevant config on pastebin: https://pastebin.com/LNxYH31r
tcpdump here: https://drive.shadow82.pl/s/5EGAD2nDiETwZYs

Is there some routing loop?
MKT doesn't know where to respond?
What am I missing here?

2

Using print is now how we share router configuration details on this forum. Run this command:

/export hide-sensitive file=config

Download the file config.rsc to your computer and use a text editor to censor the informations like serial numbers, MAC addresses, public IP addresses, public keys, etc. ... The paste the content in a code block between

```routeros
  --- paste your config here ---
```
3

Hi there, as CGG noted a full config of the router is

step 1.
/export file=anynameyouwish (minus router serial number, any public WANIP information, keys).

step2.
Provide some clarity on the two wireguard vpn setups.
besides the fact they have provided you with..
a. ip address to use
b. endpoint address
c. endpoint port
d. private key to use on router interface creation ( so they know the public key it makes already )
e. did they provide a DNS address for you to use???
f. any other info??

Typically yes, third party vpns are STRICTLY for OUTGOING traffic, in other words, your web browsing etc is done at a different location than your actual physical location and goes out a different ISP.
Hosting incoming traffic to reach to your network is NOT a normal function of third party VPNS.

Typically if you dont have a public IP address to host your own wireguard connection folks rent a cloud server 6-8$ per month, get a MT CHR license and voila you have your OWN 'third party" scenario except you are the third party and it has full wireguard capabilities.

After reading the proton port forwarding information, its not clear to me yet, how to integrate that with router settings and maybe you dont as the bulk of the work should be done at the Proton site.

If you have users needing to reach servers on your local network, can we assume that means they would use whatever port the local server is using ( not the proton listening port ) and the endpoint address proton has given you and somehow proton would know to send this port and request to your mikrotik??

On the CHR we do this by
a. allowing port forwarding in the forward chain

add action=accept chain=forward connection-nat-state=dstnat

b. Creating a dstnat rule for that port......

add action=dst-nat chain=dstnat in-interface-list-WAN dst-port=MT-ServerPort protocol=xxx \
to-address=MT-ServerIP to-port=(if port translation required)

c. Now we need to tell the CHR where to send the traffic as it has no clue about the MT SERVERIP,

add dst-address=MTServerSubnet  gateway=wireguardinterface routing-table=main

d. the tricky part at the CHR is knowing the requirements. Is it essential/necessary that the Server on the Local MT lan sees the original IP address for whatever reason or not. If not then we sourcenat all traffic going into the Wireguard tunnel with the wireguard address of the wg interface of the CHR.......

This makes any reply traffic at the local MT router EASY! no special routing or allowed IPs need to be considered.

On the other hand if the server needs to know the originators WANIP, things get more difficult at the MT Router side. The only difference at the CHR is we dont need to sourcenat. So a tad easier there.
At the MT router, we know have to be able to return traffic for any potential WANIP.

How do we ensure the return traffic from the server outbound goes back into the tunnel.
Probably a couple of routing rules would suffice.
-min prefix rule (ensures local traffic still works)
-src of serverIP use routing table=useWG

with table of

/routing table fib name=useWG

and route of

add dst-address=0.0.0.0/0 gateway=wireguardinterface  routing-table=useWG

Of course we also need forward chain firewall rules to allow the traffic both incoming and outgoing on the MT Router.
++++++++++++++++++++++++++++++++++++++++++++++++

All to say, we would have to know how PROTON is sending you the port forwarded traffic.
1 - All with single source IP of the proton wireguard IP
OR
2 - All with original WANIP address
3 - Can we can assume proton is sending the dst port it received from the user??

Here is the difficulty, I have described doing it for KNOWN ports, but proton site keeps talking about random ports and UPNP and NAT PMP.

Thus I do not know how to handle this 'extra' level of complexity.
I do know that MT has now both settings UPNP and NAT PMP.