Problem ssh to mikrotik ovpn client

RouterOS General
1

I installed a openvpn server on a linux machine and I configured my board RBM33G as a vpn client successfully

Interface status is connected running
and I see the board ip address /ip Addreses

but ssh and ping to the board ip from the server is not working

why can’t I ssh to the board via vpn?

2

I would suspect your firewall rules on the RBM33G to block ssh access and icmp response via the /interface ovpn-client. If you can’t see it there on your own, follow the hint in my automatic signature.

3

This is the config export:

[admin@MikroTik] > /export hide-sensitive
# may/26/2019 09:06:23 by RouterOS 6.44.3
# software id = EPU4-B5BD
#
# model = RouterBOARD M33G
# serial number = A2FD0AB8D70F
/interface lte
set [ find ] mac-address=02:1E:10:1F:00:00 name=lte1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/port
set 1 name=usb2
/interface ppp-client
add apn=internet name=ppp-out1 port=usb2
/ppp profile
add change-tcp-mss=yes name=OVPN-client only-one=yes use-encryption=required use-mpls=no
/interface ovpn-client
add certificate=client cipher=aes256 connect-to=myhost mac-address=FE:22:AC:D1:11:7E name=myvpn profile=OVPN-client user=admin
/ip address
add address=192.168.88.1/24 comment=defconf interface=ether1 network=192.168.88.0
/ip firewall filter
add action=accept chain=input comment=OpenVPN dst-port=1194 protocol=tcp
/ip ssh
set allow-none-crypto=yes forwarding-enabled=both
/system clock
set time-zone-name=Asia/Jerusalem

My firewall rules are empty, added this rule :

ip firewall filter add action=accept chain=input comment="OpenVPN" disabled=no dst-port=1194 protocol=tcp

but it didn’t change anything

4

It has nothing to do with your topic but I have to start from this because it is critical. Empty firewall rules on a machine which is connected to internet are a very bad idea (if you don’t get a public IP on your internet uplink, it is just a bad idea). The reason is that Mikrotik’s default handling in /ip firewall filter is accept, so without any firewall rules, access to management is open via all services (not only ssh but also all the other ones, including the plaintext ones with none or ridiculously weak protection of password authentication - telnet and http), and also access to devices on Mikrotik’s LAN is open if the attacker knows or can guess their addresses.

The firewall part of the default configuration is safe against the filth trying to barge in through the WAN door and neatly composed so I recommend you to use it; it follows the philosophy of “zone firewall” where zones are implemented using /interface list. It is also beginner-friendly in terms that whatever comes in via an interface which is NOT on interface list WAN is accepted (which instantly becomes a security hole as soon as you start adding your own WAN interfaces and don’t add them as /interface list member of interface list WAN).

If you know nothing about how firewall works, this supercharged firewall intro and explanation of rule syntax may be useful.

Now to your issue - the OpenVPN implementation in Mikrotik is very limited to put it really softly. Besides a security hole (the client accepts the server certificate even if it doesn’t have the certificate of its signing CA in its repository - still true in 6.44.3) and lack of support of UDP transport and compression, it also doesn’t support pushing routes from server to client. So the initial SYN packet of your SSH attempt makes it to the Mikrotik via the OpenVPN tunnel when you try to SSH to the IP address assigned to the Mikrotik by the OpenVPN server, but the response takes the default route via LTE so it gets anywhere but back to the client.

What you have to do depends on how you use the VPN:

  • if it is some public service providing you with a public IP, so the SSH client is on somewhere else in the internet, you need the OpenVPN tunnel to become the default route of the Mikrotik as soon as it gets up; to do that, you set the add-default-route of the /interface ovpn-client to yes, and also set the default-route-distance in the /interface ppp-client to something higher than 1. But before doing that, you have to add a static route to the VPN server’s IP via the LTE interface, otherwise the OpenVPN’s transport packets would also be routed into the OpenVPN tunnel interface rather than delivered to the server.
    In this case, there are two additional points:
    • most public VPN services block incoming connections to the public IPs they assign to their clients (because it is not their purpose and because they need to recycle the public IPs or even share them among several clients), so you may be unable to SSH to your router for this reason,
    • if the incoming connections to the public address are permitted, you have to place the interface to the interface list WAN and only permit access to the services in your network which really need to be accessible from outside, such as SSH to the Mikrotik itself by allowing access to TCP port 22 in chain=input of the firewall
  • if you use the VPN the traditional way, to build a secure link between two private networks, it is enough to add routes to all remote subnets which you need to access via the OpenVPN tunnel. If you have multiple subnets behind the Mikrotik and want to access hosts in these subnets from the server side, you have to inform the OpenVPN server about their availability va that client using the iroute directive in the openvpn configuration file on the server in addition to adding routes to them via openvpn’s tunX interface into the server’s kernel routing table.
5

Updating backend server config to be closer to :
https://wiki.mikrotik.com/wiki/OpenVPN#OpenVPN_server_configuration:
fixed the problem

But I would expect the client to have a faulty status in that case.

current:

keepalive 10 120
# comp-lzo no
# push "comp-lzo no"
user nobody
group nogroup

previous:

keepalive 10 60
comp-lzo no
push "comp-lzo no"
user myuser
group mygroup

Regarding the firewall rules, you are absolutely right, and gave me some important points.
At the moment I am working on a POC but when it’s done we will definitely harden the board

6

Glad you’ve found it. However, if this was enough to fix the problem, then you must be connecting to the Mikrotik using SSH from the OpenVPN server itself. An attempt to connect from any other network would have had to fail due to the absence of the at the client. The typical trouble into which people run is that they don’t forget to set up the default route via the VPN tunnel but they forget to set up the individual route to the VPN server.


It’s a question whether the client has a possibility to find out in advance that the server will send lzo-compressed packets.


So you are setting up the POC in a closed network environment, i.e. your ppp-client doesn’t actually connect to an ISP but to some test ppp server?