Community discussions

MikroTik App
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Wireguard on GPRS connection

Fri Aug 12, 2022 6:03 pm

Hi, I have a wireguard setup on my local network through the RB3011 as server 10.1.101.254 (A) and a local server (Olimex Lime2 arm) as 10.1.103.254 (B). These are communicating and I can, from my PC connected to the RB3011, connect to a website on the 10.1.103.254. This seems to work.
Now I need to connect a remote server (C) (copy of the Olimex Lime2) which has exactly the same config, but with its own private/public keys and it has it's own peer-line in the RB3011 wireguard configuration.
This remote server is connected through a 4G GPRS internet connection. It has no public accessible IP addres. For configuration purposed I connect to this server using a reverse ssh tunnel (which is damn slow).
I cannot get this server C connect to A so that they see eachother (cannot ping). Would it be possible at all to connect server C and A directly over the internet as C has no public IP address?
I realize in my RB3011 route setup I do have routes for 10.1.103.0/24 but not for 10.1.102.0/24, and I would not know how these should look like.
I would highly appreciate any help to get this to work. I have limited VPN experience...
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Wireguard on GPRS connection

Fri Aug 12, 2022 7:55 pm

This remote server is connected through a 4G GPRS internet connection.

I know little about this sort of thing, but my web-fu says GPRS is a pre-4G thing. So, is it 4G, or is it GPRS?

It has no public accessible IP addres.

At some level, a connection's route has to include a public IP, else you aren't on the Internet. I'm not being pedantic: how you proceed depends on what you actually mean by your claim:

  • Your public IP changes frequently, such as on every network reconnect, but port-forwarding (formally, dstnat) works once you learn what the public IP is, such as via dynamic DNS. You configure WG to connect to the DDNS name, not to a specific IP. My WG config might be of some use to you in this instance.
  • Your connection is NATted all to hell by your mobile data carrier such that even knowing each network's public IP doesn't help, so what you need is some industrial-strength NAT traversal magic.

Stock WireGuard doesn't address the latter; it's purposely kept too simple to do such clever things. There are third-party products based on WireGuard that add this to it (e.g. Tailscale, headscale) but none of that is included in RouterOS.

Two alternatives:

  1. Easier: switch to ZeroTier, which includes NAT traversal technology natively. Both ends of the connection can be behind the most horrific CGNAT implementation and still communicate, so long as both can talk to the central coordination servers.
  2. Harder: Run a container with Tailscale or similar.

Both options require RouterOS 7.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19106
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard on GPRS connection

Fri Aug 12, 2022 8:44 pm

As long as one end has a publically accessible IP, it should work.
The problem is your explanation is very confusing.
A network diagram is required. When you use the word server do you mean wireguard server or like an FTP server.

From what I can interpret you have two routers on the internet, both are setup to be wireguard servers or clients?
You have a third router that needs to connect via VPN and wireguard should work to connect to either 2.

The remote device has to initiate the connection and that may be the problem as there is no user there to initiate the connection??
Once its up it stays up for the most part. However when a public IP changes (on the server side) wireguard in the current MT construct often needs to be reset.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5405
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: Wireguard on GPRS connection

Fri Aug 12, 2022 9:23 pm

As long as one end has a publicly accessible IP, it should work.
<corrected that typo for you ;) >

Correct. GPRS, 3G, 4G/LTE, whatever ... you need ONE fixed IP to point to.
If A has a public IP AND the port you want to use can be terminating on the RB, it can work.

GPRS is something coming from 2G and was still being used in early 3G era -> super slow !
But GPRS 4G, that's a strange combination... why would one use a technology which is SLOWER then a snail if 4G is available ?

A diagram and further clarifications would be very helpful, yes.
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Re: Wireguard on GPRS connection

Sat Aug 13, 2022 12:02 am

Hi all, sorry for the confusion I created, I'm not really knowledgeable in networking and sometimes the instructions are kind of confusing for me. First, I'm having a 4G connection, shouldn't have mentioned GPRS.
The 'servers' I'm mentioning are both serving wireguard as other services, in fact the servers B and C are MQTT servers which currently communicate through an ssh-tunnel. And server C is really remote (about 1500km away). All A,B and C have wireguard installed and have their own IP range: A=10.1.101.0/24, B=10.1.103.0/24 and C=10.1.102.0/24
Server A (the MT3011RB) has a public IP address which is stable and accessible form the internet.

MT3011RB (server A):
/interface wireguard
add listen-port=13231 mtu=1420 name=sorby_net
/interface wireguard peers
add allowed-address=10.1.103.0/24,192.168.2.0/24 endpoint-address=10.1.101.254 endpoint-port=13231 interface=sorby_net public-key="BQmIN...."
add allowed-address=10.1.102.0/24 endpoint-address=10.1.101.254 endpoint-port=13231 interface=sorby_net public-key="g9Dv...."
wg0.conf of server B:
[Interface]
Address = 10.1.102.254/24
ListenPort = 13231
PrivateKey = cFM3r...
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = z0hp....
AllowedIPs = 10.1.101.0/24,10.1.102.0/24,10.1.103.0/24 #,192.168.10.0/24
Endpoint = 1.2.3.4:13231
wg0.conf of server C:
[Interface]
Address = 10.1.103.254/24
ListenPort = 13231
PrivateKey = cA6ji....
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = z0hpr...
AllowedIPs = 10.1.101.0/24,10.1.102.0/24 #,192.168.2.0/24
Endpoint = 192.168.2.254:13231
An image of the network topology should be here: https://www.dropbox.com/s/m8ss1whkyc1lo ... .jpeg?dl=0
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19106
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard on GPRS connection

Sat Aug 13, 2022 2:21 am

Need config of MT Router A.
/export just hide any wanip or wanip gateway info, and keys etc..


What is the purpose of connecting Wireguard B MQTT server with Router A?
In fact why have the MQTT wireguard server at all. Just use the MT device only???
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Re: Wireguard on GPRS connection

Sat Aug 13, 2022 10:30 am

There is no real need to have server B and C to have their own wireguard server-function with separat IP ranges. Actually it would be much easier to have 1 wireguard IP range to connect all together. So how would the wg0.conf's of B and C should look like if there would be only one WG server on the MT3011RB?

Config MT A:
# aug/13/2022 09:08:53 by RouterOS 7.3.1
# software id = EVGK-W4DB
#
# model = RB3011UiAS
/interface bridge
add admin-mac=... auto-mac=no comment=defconf name=bridge
/interface wireguard
add listen-port=13231 mtu=1420 name=sorby_net private-key="oNs4o..."
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp2 ranges=192.168.2.30-192.168.2.90
add name=dhcp next-pool=dhcp2 ranges=192.168.2.150-192.168.2.200
/ip dhcp-server
add address-pool=dhcp interface=bridge lease-script="DNS_testscript\r\
    \n" lease-time=16h name=defconf
/port
set 0 name=serial0
/user group
set full policy=local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,rest-api
/dude
set enabled=yes
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2
add bridge=bridge comment=defconf ingress-filtering=no interface=ether3
add bridge=bridge comment=defconf ingress-filtering=no interface=ether4
add bridge=bridge comment=defconf ingress-filtering=no interface=ether5
add bridge=bridge comment=defconf ingress-filtering=no interface=ether6
add bridge=bridge comment=defconf ingress-filtering=no interface=ether7
add bridge=bridge comment=defconf ingress-filtering=no interface=ether8
add bridge=bridge comment=defconf ingress-filtering=no interface=ether9
add bridge=bridge comment=defconf ingress-filtering=no interface=ether10
add bridge=bridge comment=defconf ingress-filtering=no interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ip settings
set max-neighbor-entries=8192
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface ovpn-server server
set auth=sha1,md5
/interface wireguard peers
add allowed-address=10.1.103.0/24,192.168.2.0/24 endpoint-address=10.1.101.254 endpoint-port=13231 interface=sorby_net public-key="BQmIN..."
add allowed-address=10.1.102.0/24 endpoint-address=10.1.101.254 endpoint-port=13231 interface=sorby_net public-key="g9Dv8..."
/ip address
add address=192.168.2.254/24 comment=defconf interface=bridge network=192.168.2.0
add address=10.1.101.254/24 interface=sorby_net network=10.1.101.0
/ip dhcp-client
add comment=defconf interface=ether1
/ip dhcp-server lease
...
add address=192.168.2.5 mac-address=1E:2C:39:C7:87:B3
...
/ip dhcp-server network
add address=192.168.2.0/24 comment=defconf gateway=192.168.2.254 netmask=24
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.2.254 comment=defconf name=router.lan
...
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input disabled=yes dst-port=443 protocol=tcp
add action=accept chain=input disabled=yes dst-port=8291 protocol=tcp
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=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
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=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="NTP NAT masquerade " dst-port=123 out-interface-list=WAN protocol=udp to-ports=12300-12390
...
/ip route
add disabled=no distance=1 dst-address=10.1.103.0/24 gateway=192.168.2.5 pref-src=0.0.0.0 routing-table=main scope=30 suppress-hw-offload=no target-scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www-ssl address=0.0.0.0/0 certificate=SystemCertificate disabled=no
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
/lcd
set default-screen=stat-slideshow
/lcd pin
set pin-number=3512
/system clock
set time-zone-autodetect=no time-zone-name=Europe/Amsterdam
/system identity
set name=MT3011RB
/system logging
/system ntp client
set enabled=yes
/system ntp client servers
add address=0.pool.ntp.org
add address=1.pool.ntp.org
add address=2.pool.ntp.org
add address=3.pool.ntp.org
/system scheduler
/system script
/tool bandwidth-server
set enabled=no
/tool graphing interface
/tool graphing resource
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19106
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Wireguard on GPRS connection

Sat Aug 13, 2022 4:14 pm

Now you are going overboard LOL.
Certainly the MT device with public IP is the main central point of your wireguard in terms of a site that can be connected to.
Once connected however traffic is peer to peer (two way tunnel - either side can originate traffic into the tunnel).
Concur that the MQTT wireguard on the left side (B) is not required.

So on the left side of your diagram we can do all wireguard connectivity with the MT device.
On the right side, I dont know what is connected to the 4G, Im assuming its a router of some type that is NOT wireguard capable and thus you are using the MQTT device which has a wireguard capability as the remote site host for wireguard.

Please confirm.

The issue being you haven really detailed your wireguard requirements and thus you have implemented wireguard really without a coherent plan.
a. identify user/device, groups of users/devices on the networks and note any road warrios that will be 'on the road'
b. identify what they should be able to do and NOT be able to do.
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Wireguard on GPRS connection

Sat Aug 13, 2022 10:18 pm

/ip firewall filter
add action=accept chain=input disabled=yes dst-port=8291 protocol=tcp

Change that rule to open port 13231 (your WireGuard listen port) instead.

(You will then be running WinBox over WG for remote management, a far safer method than exposing WinBox to the open Internet.)

Having done that, set up some sort of dynamic DNS to deal with the changing cable modem IP, such as RouterOS's "cloud" feature. That should solve the rest of the problem, since it lets you point Client C at 529c0491d41c.sn.mynetname.net (to use the linked-to page's example name) instead of a raw IP.
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 12:14 pm

/ip firewall filter
add action=accept chain=input disabled=yes dst-port=8291 protocol=tcp
Change that rule to open port 13231 (your WireGuard listen port) instead.
That's a good point, will do that for future use. Actually currently the 8291 port for WinBox is blocked at the level ot the cable router so there should not be much of a danger as yet.
(You will then be running WinBox over WG for remote management, a far safer method than exposing WinBox to the open Internet.)

Having done that, set up some sort of dynamic DNS to deal with the changing cable modem IP, such as RouterOS's "cloud" feature. That should solve the rest of the problem, since it lets you point Client C at 529c0491d41c.sn.mynetname.net (to use the linked-to page's example name) instead of a raw IP.
I'm using DynDNS, for this. But that does not solve the primary problem of the connection between B and A (actually I made a mistake in my description, server B is the remote one, not C).
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 1:19 pm

Now you are going overboard LOL.
Ahhh... a refreshing dip in the canal :D Good suggestion!
Certainly the MT device with public IP is the main central point of your wireguard in terms of a site that can be connected to.
Once connected however traffic is peer to peer (two way tunnel - either side can originate traffic into the tunnel).
Concur that the MQTT wireguard on the left side (B) is not required.
Yep, I guess so, Wireguard at the left side of my scheme is not required, actually main purpose to set it up was to test if I was capable of getting wireguard up and running.

So on the left side of your diagram we can do all wireguard connectivity with the MT device.
Right!

On the right side, I dont know what is connected to the 4G, Im assuming its a router of some type that is NOT wireguard capable and thus you are using the MQTT device which has a wireguard capability as the remote site host for wireguard.
Correct. At the right side (for correctness that is in my explanation Server B) I have a 4G USB modem with no wireguard capabilities. The device to which it is connected is an Olimex Lime2 board with debian and wireguard. It also has a USB wifi device which funtions as hotspot for some sensors (temp, humidity,pir) feeding the system with mqtt payloads. Currently the mqtt messages are communicated with server C through an ssh tunnel.

Please confirm.

The issue being you haven really detailed your wireguard requirements and thus you have implemented wireguard really without a coherent plan.
a. identify user/device, groups of users/devices on the networks and note any road warrios that will be 'on the road'
b. identify what they should be able to do and NOT be able to do.
The reasons to set up a wireguard network are:
1. it seems to be fast, hopefully faster than my current setup with ssh tunnels, which are really slow
2. simplify secure connection to the remote system, which is now being done by accessing the remote ssh tunnel which is maintained by server B
3. enable future possibilities, eg accessing webcam/security cam
The 'users' are (should be) the connected sensors (connected through the wifi hotspot) and remote access using ssh for management. The idea is to move the devices from the local IP range (192.168.10.0/24) of server B to the wireguard network.
 
holvoetn
Forum Guru
Forum Guru
Posts: 5405
Joined: Tue Apr 13, 2021 2:14 am
Location: Belgium

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 2:39 pm

Having done that, set up some sort of dynamic DNS to deal with the changing cable modem IP, such as RouterOS's "cloud" feature. That should solve the rest of the problem, since it lets you point Client C at 529c0491d41c.sn.mynetname.net (to use the linked-to page's example name) instead of a raw IP.
With the minor drawback Mikrotik's implementation of WG does not cover changing IP with DDNS.
But easily solved using a small script and a netwatch trigger. So I classify it as a minor annoyance, nothing more.
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 3:53 pm

With the minor drawback Mikrotik's implementation of WG does not cover changing IP with DDNS.
But easily solved using a small script and a netwatch trigger. So I classify it as a minor annoyance, nothing more.

I left it out of the export, but this is the script, should be triggered once and awhile with a scheduler line

# Set needed variables
	:local username "yourUserName"
	:local password "yourPassword"
	:local hostname "yourDynDNSaccount"

	:global dyndnsForce
	:global previousIP

# print some debug info
	:log info ("UpdateDynDNS: previousIP = $previousIP")

# get the current IP address from the internet (in case of double-nat)
	/tool fetch mode=http address="checkip.dyndns.org" src-path="/" dst-path="/dyndns.checkip.html"
	:delay 1
	:local result [/file get dyndns.checkip.html contents]

# parse the current IP result
	:local resultLen [:len $result]
	:local startLoc [:find $result ": " -1]
	:set startLoc ($startLoc + 2)
	:local endLoc [:find $result "</body>" -1]
	:local currentIP [:pick $result $startLoc $endLoc]
	:log info "UpdateDynDNS: currentIP = $currentIP"

# Remove the # on next line to force an update every single time - useful for debugging,
# but you could end up getting blacklisted by DynDNS!

#:set dyndnsForce true

# Determine if dyndns update is needed
# more dyndns updater request details http://www.dyndns.com/developers/specs/syntax.html

	:if (($currentIP != $previousIP) || ($dyndnsForce = true)) do={
		:set dyndnsForce false
		:set previousIP $currentIP
		:log info "$currentIP or $previousIP"
		/tool fetch user=$username password=$password mode=http address="members.dyndns.org" \
		src-path="nic/update?system=dyndns&hostname=$hostname&myip=$currentIP&wildcard=no" \
		dst-path="/dyndns.txt"
		:delay 1
		:local result [/file get dyndns.txt contents]
		:log info ("UpdateDynDNS: Dyndns update needed")
		:log info ("UpdateDynDNS: Dyndns Update Result: ".$result)
		:put ("Dyndns Update Result: ".$result)
	} else={
		:log info ("UpdateDynDNS: No dyndns update needed")
	}
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 4:19 pm

He’s saying that the WG conn needs to be bounced when the IP changes.

As for my firewall recommendation, that’s not optional. If the remote router can’t connect to the “server” router on port 13231, you get the very symptom you complain of.
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 8:10 pm

He’s saying that the WG conn needs to be bounced when the IP changes.

As for my firewall recommendation, that’s not optional. If the remote router can’t connect to the “server” router on port 13231, you get the very symptom you complain of.
Not completely sure what you mean but both using the IP address and using the DynDNS address on the remote (B) server does not allow me to connect
If you consider this a firewall problem, where should I search in the firewall rules?
 
tangent
Forum Guru
Forum Guru
Posts: 1351
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 8:28 pm

where should I search in the firewall rules?

I obliquely told you already, but okay, I'll spell it out. You're missing this on "router A":

/ip firewall filter
add action=accept chain=input dst-port=13231 protocol=udp

Without this, the default "drop all not coming from LAN" rule kicks in, dropping inbound connections to your WireGuard server.

Note that I removed "disabled=yes" so it will be enabled. It also needs to be a UDP rule, not TCP, since WG is UDP exclusively.
 
mikear
newbie
Topic Author
Posts: 40
Joined: Wed Mar 23, 2022 8:08 pm
Location: Utrecht, Netherlands

Re: Wireguard on GPRS connection

Sun Aug 14, 2022 9:03 pm

where should I search in the firewall rules?

I obliquely told you already, but okay, I'll spell it out. You're missing this on "router A":

/ip firewall filter
add action=accept chain=input dst-port=13231 protocol=udp
Without this, the default "drop all not coming from LAN" rule kicks in, dropping inbound connections to your WireGuard server.

Note that I removed "disabled=yes" so it will be enabled. It also needs to be a UDP rule, not TCP, since WG is UDP exclusively.
OK, thats a bingo. Sorry for my ignorance. But indeed obviously I've been blocking everything but the related packages.
Great help!

Who is online

Users browsing this forum: Ahrefs [Bot], apitsos, neki and 75 guests