Hi all.
Just did an Amazon Web services test of Mikrotiks RouterOS with the available amazon marketplace release of RouterOS v6.34.1.
As it was just a test I did an upgrade to v6.38rc15 which went smooth..
I used the t2.micro ( Free tier ) for the test. It took me about 2 minutes from starting the whole process from the marketplace to getting a winbox link up.
Anyhow attached is a couple of screen shots of it running with winbox pics.
I briefly tested webproxy too and found that worked well..
A few questions:
How did you upgrade your AWS image?
The Full x86 PKG file?
Does that remove the virtual optimized drivers for CHR?
Upgrade can be done with the regular x86 packages, the installation is the one that configures the correct kernel and drivers, upgrades can be done with the generic packages.
Thanks. It nice that its kept simple that way. By architecture like Routerboards.
Hi, yes I kept it simple. Just pressed the check for updates in the package list(release candiate(cutting edge eh!!), and pressed upgrade). Took less than minute to come back to life on AWS.
Nice and smooth 
.
Cheers
You can install and run RouterOS x86 on every emulator that can support x86 CPU. You can use Qemu, VirtualBox or VMware to do his job. The question is if we can use Qemu to virtualize RouterBoard with non x86 CPU, e.g. MIPS and run RouteOS on that VM.
I would imagine that if you can emulate any ROS supported CPU, you can probably install that platform into a virtual machine. You’ll have to keep in mind, though, that the drivers bundled with any given platform are for the hardware in those supported platforms, so you may not have all the drivers necessary for the virtual hardware.
@killersoft
Did you managed to run CHR with second network interface added?
Regards,
I’m trying to test this too but I can’t log into the mikrotik image with the AWS-key.pem – it traps out to password. Is the correct user root? Should I be able to get root access as described in the marketplace connection instructions or is there a trick?
Love to try this. Thnx
Default user is ‘admin’.
Here is Wiki article about CHR installation on AWS:
http://wiki.mikrotik.com/wiki/Manual:CHR_AWS_installation
HTH,
Hi. I succesfully spun up an AWS CHR instance (6.38.1), BUT if I attach a second network interface to the instance, it will show as Running in Interfaces with correctly assigned IP address, but otherwise be completely dead (not reachable neither with www nor Winbox). Eventually the whole instance gets unstable and unreachable. Bug, or am I doing something wrong?
I had similar problems and finally decided to not use CHR on AWS.
Regards,
Please check the AWS documentation or describe in detail - what actions did you perform to get to the conclusion that this is not working - in my testing secondary interface correctly was added and changing assigned address on the interface did not cause any issues with the connectivity to the running instance.
edit:
The test was done with 6.38.2 on EC2 instances. And as there are the requirement to have an Elastic IP for the instance if you are using more than 1 interface.
Also, check your security settings for the network as traffic might be blocked by the internal Amazon firewall.
@janisk
I made AWS test 2 month ago and don’t remember details.
There were other small problems/inconveniences due to AWS infrastructure, not with CHR which worked fine.
I also tested other cloud services and finally I decided to not run CHR on AWS.
Currently I run two CHR using other cloud services for 2 months, so far, so good 
.
Regards,
Err… I think I have described in detail. it’s pretty straightforward. I only need an external IP on one interface, so don’t need to provision additional Elastic IP as instance is born with an external IP. Other than that, second internal IP is assigned to second Network Interface. But only one interface is reachable at a time. Both interfaced share the same security group which allow incoming winbox.
from what network did you have the local IP address that was assigned to the interfaces? Also, as Amazon states in the documentation, assigned IP address is NATed only to one internal Ip address and the virtual interfaces cannot communicate between themselves.
This is my test-setup right now, internal network 172.31.32.0/20 is provided by AWS . Added a Elastic IP to ether2 to see if it made a difference. For the test I am connected to AWS via site-2-site using AWS VPN functionality (hardware MT in my end). Should I not be able to ping ether1 internal AND ether2 internal from my end? Right now, I can only ping ether1.. If i disable ether1 in MT, I can ping eher2. If I reenable ether1 I can still only ping ether2.
As I have understood from the AWS documentation - this is how it works. You have to look into VPS setups how to create local network or how to create a tunnel from AWS to your network. In AWS fabric these interfaces are not connected in any way.
I am having some trouble with an IPSEC vpn tunnel from “HOME” to a CHR on AWS. I have several tunnels running between MT’s scattered around the internet, but can’t seem to get the AWS CHR figured out. I am treating it just like another MT router on the internet – is this correct?
The phase 2 does not complete, but policies, secrets all match.
I need fresh eyes…
SETUP:
I have a CHR image up and running on AWS, and a MT hardware box at HOME. Both have private networks also connected to them.
HOME_IP_ADDRESS
HOME_INSIDE_NETWORK = 192.168.30.0/24
HOME_INSIDE_ADDRESS = 192.168.30.1
CHR_IP_ADDRESS
CHR_INSIDE_NETWORK = 172.31.64.0/24
CHR_INSIDE_ADDRESS = 172.31.64.X
Security group on CHR EC2 instance is WIDE OPEN, which applies to both its internet and private network traffic.
HOME and CHR have open firewalls for each other’s IP address and for all addresses on the private networks behind them.
CHR is set up to perform NAT on traffic leaving CHR_INSIDE_NETWORK through CHR router.
HOME and CHR have NAT VPN bypasses for traffic to each other’s network.
HOME router can ping CHR_IP_ADDRESS and CHR can ping HOME_IP_ADDRESS.
CHR can ping CHR_IP_ADDRESS, also CHR_INSIDE_ADDRESS, and also other linux instances on CHR_INSIDE_NETWORK.
HOME and CHR use default ipsec proposals:
HOME>set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc
lifetime=30m name=default pfs-group=modp1024
CHR>set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc
lifetime=30m name=default pfs-group=modp1024
HOME settings
/ip address
add address=192.168.30.1/24 comment=defconf interface=ether2-master network=192.168.30.0
/ip ipsec peer
add address=CHR_IP_ADDRESS/32 auth-method=pre-shared-key comment=AWS-CHR dh-group=modp1024 disabled=no dpd-interval=2m
dpd-maximum-failures=5 enc-algorithm=aes-128,3des exchange-mode=main generate-policy=no hash-algorithm=sha1
lifetime=1d nat-traversal=no policy-template-group=default proposal-check=obey secret=SECRET
send-initial-contact=yes
/ip ipsec policy
add action=encrypt comment=AWS-CHR disabled=no dst-address=172.31.64.0/24 dst-port=any ipsec-protocols=esp level=
require priority=0 proposal=default protocol=all sa-dst-address=CHR_IP_ADDRESS sa-src-address=HOME_IP_ADDRESS
src-address=192.168.30.0/24 src-port=any tunnel=yes
CHR setting
/ip address
add address=172.31.64.X interface=ether2 network=172.31.64.0
/ip ipsec peer
add address=HOME_IP_ADDRESS/32 auth-method=pre-shared-key comment=HOME dh-group=modp1024 disabled=no dpd-interval=2m
dpd-maximum-failures=5 enc-algorithm=aes-128,3des exchange-mode=main generate-policy=no hash-algorithm=sha1
lifetime=1d nat-traversal=no policy-template-group=default proposal-check=obey secret=SECRET
send-initial-contact=yes
/ip ipsec policy
add action=encrypt comment=HOME disabled=no dst-address=192.168.30.0/24 dst-port=any ipsec-protocols=esp level=
require priority=0 proposal=default protocol=all sa-dst-address=HOME_IP_ADDRESS sa-src-address=CHR_IP_ADDRESS
src-address=172.31.64.0/24 src-port=any tunnel=yes
CHR log errors:
HOME_IP_ADDRESS failed to pre-process ph2 packet.
HOME_IP_ADDRESS peer sent packet for dead phase2
HOME_IP_ADDRESS failed to pre-process ph2 packet.
…
HOME log errors:
In the IPSEC policy window the connection shows “msg 1 sent”, then “no phase2”.
I found the error.
The AWS addresses in the previous post were incomplete. The “external” CHR internet address is used, AND the “internal” NATed address is also used in setting up the tunnel. The ipsec policy must use the CHR_IP_ADDRESS_INTERNAL for the sa-src-address, while the CHR_IP_ADDRESS_EXTERNAL address is used elsewhere.
So to restate the configuration from the previous post:
HOME_IP_ADDRESS
HOME_INSIDE_NETWORK = 192.168.30.0/24
HOME_INSIDE_ADDRESS = 192.168.30.1
CHR_IP_ADDRESS_EXTERNAL
CHR_IP_ADDRESS_INTERNAL
CHR_INSIDE_NETWORK = 172.31.64.0/24
CHR_INSIDE_ADDRESS = 172.31.64.X
HOME settings
/ip ipsec peer
add address=52.37.130.208/32 comment=AWS-CHR nat-traversal=no secret=SECRET
/ip ipsec policy
add comment=AWS-CHR dst-address=172.31.64.0/24 sa-dst-address=CHR_IP_ADDRESS_EXTERNAL sa-src-address=HOME_IP_ADDRESS src-address=
192.168.30.0/24 tunnel=yes
CHR setting
/ip ipsec peer
add address=HOME_IP_ADDRESS/32 comment=HOME nat-traversal=no secret=SECRET
/ip ipsec policy
add comment=HOME dst-address=192.168.30.0/24 sa-dst-address=HOME_IP_ADDRESS sa-src-address=CHR_IP_ADDRESS_INTERNAL src-address=
172.31.64.0/24 tunnel=yes