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:CH ... stallation

HTH,

@killersoft
Did you managed to run CHR with second network interface added?

Regards,

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?

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,

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?

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,

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?

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.

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.

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

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.

WOW, thanks so much for this piece of info. Brought my tunnel right up...

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.
2017-02-03 14_30_23-PARCOVET - TeamViewer - Gratis licens (kun til ikke-kommerciel brug).jpg

You can use multiple public (elastic) IPs on a single interface at least, I've tested it.Haven't tried adding a second interface.
AWS router gives you the Elastics by static NAT to your CHR, so for each Elastic IP on AWS you also need to create a new private(manually in CHR) in the same address space as the private you receive by DHCP.

Hello all

I trying to build tunnel based on hca's description in above of this topic

and faced with the same "no phase2" problem. But unfortunately can't resolve it by the method that was described

My configuration is following

I have CHR running on the AWS side and HW Mikrotik on office side.
CHR placed in the VPC, subnet 172.16.30.0/24, and have one interface with binded Elastic IP.
The Source/dest. check is disabled and Security Group allow all from OFFICE_Real_IP.

CHR_EIP 18.194.160.xxx
CHR internal IP 172.16.30.178
CHR internal net 172.16.30.0/24

OFFICE_Real_IP 5.145.132.xxx
OFFICE_Internal IP 192.168.254.252
OFFICE_Lan 192.168.254.0/24

CHR config

/ip address
add address=18.194.160.xxx interface=ether1 network=18.194.160.xxx

/ip dhcp-client
add disabled=no interface=ether1

/ip firewall nat
add chain=srcnat dst-address=192.168.254.0/24 src-address=172.16.30.0/24
add action=masquerade chain=srcnat

/ip ipsec proposal
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=achen

/ip ipsec peer
add address=5.145.132.xxx/32 enc-algorithm=aes-256,aes-192,aes-128 \
local-address=172.16.30.178 nat-traversal=no secret="$secret"

/ip ipsec policy
add dst-address=192.168.254.0/24 proposal=achen sa-dst-address=5.145.132.xxx \
sa-src-address=172.16.30.178 src-address=176.16.30.0/24 tunnel=yes

OFFICE config

/ip ipsec peer

add address=18.194.160.xxx/32 dh-group=modp1024 enc-algorithm=\
aes-256,aes-192,aes-128 local-address=5.145.132.xxx nat-traversal=no \
secret="$secret"

/ip ipsec policy
add comment="Amazon wdt-cloud" dst-address=172.16.30.0/24 proposal=amazon \
sa-dst-address=18.194.160.xxx sa-src-address=5.145.132.xxx src-address=\
192.168.254.0/24 tunnel=yes


I have seen the following messages on the both routeters:


Jul/27/2018 18:37:08 ipsec,debug 5.145.132.xxx notify: NO-PROPOSAL-CHOSEN
Jul/27/2018 18:37:08 ipsec 5.145.132.xxx fatal NO-PROPOSAL-CHOSEN notify messsage, phase1 should be deleted.
Jul/27/2018 18:37:18 ipsec,debug 380 bytes from 172.16.30.178[500] to 5.145.132.xxx[500]

any help is welcome

Hi all
I trying to build tunnel based on hca's description in above of this topic
and faced with the same "no phase2" problem. But unfortunately I can't resolve it by the use internal sa_src addresses in the policy that was described

My configuration is following:

I have CHR running on the AWS side and HW Mikrotik on office side.
CHR placed in the VPC, subnet 172.16.30.0/24, and have one interface with binded Elastic IP.
The Source/dest. check is disabled and Security Group allow all from OFFICE_Real_IP.

CHR_EIP 18.194.160.xxx
CHR internal IP 172.16.30.178
CHR internal net 172.16.30.0/24

OFFICE_Real_IP 5.145.132.xxx
OFFICE_Internal IP 192.168.254.252
OFFICE_Lan 192.168.254.0/24

CHR config

/ip address
add address=18.194.160.xxx interface=ether1 network=18.194.160.xxx

/ip dhcp-client
add disabled=no interface=ether1

/ip firewall nat
add chain=srcnat dst-address=192.168.254.0/24 src-address=172.16.30.0/24
add action=masquerade chain=srcnat

/ip ipsec proposal
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=achen

/ip ipsec peer
add address=5.145.132.xxx/32 enc-algorithm=aes-256,aes-192,aes-128 \
local-address=172.16.30.178 nat-traversal=no secret="$secret"

/ip ipsec policy
add dst-address=192.168.254.0/24 proposal=achen sa-dst-address=5.145.132.xxx \
sa-src-address=172.16.30.178 src-address=176.16.30.0/24 tunnel=yes

OFFICE config

/ip ipsec peer

add address=18.194.160.xxx/32 dh-group=modp1024 enc-algorithm=\
aes-256,aes-192,aes-128 local-address=5.145.132.xxx nat-traversal=no \
secret="$secret"

/ip ipsec policy
add comment="Amazon wdt-cloud" dst-address=172.16.30.0/24 proposal=amazon \
sa-dst-address=18.194.160.xxx sa-src-address=5.145.132.xxx src-address=\
192.168.254.0/24 tunnel=yes


I have seen the following messages on the AWS CHR :


Jul/28/2018 09:47:03 ipsec,debug proposal #1: 1 transform
Jul/28/2018 09:47:03 ipsec,debug got the local address from ID payload 172.16.30.0[0] prefixlen=24 ul_proto=255
Jul/28/2018 09:47:03 ipsec,debug got the peer address from ID payload 192.168.254.0[0] prefixlen=24 ul_proto=255
Jul/28/2018 09:47:03 ipsec searching for policy for selector: 172.16.30.0/24 <=> 192.168.254.0/24
Jul/28/2018 09:47:03 ipsec policy not found
Jul/28/2018 09:47:03 ipsec failed to get proposal for responder.
Jul/28/2018 09:47:03 ipsec,error 5.145.132.xxx failed to pre-process ph2 packet.

any advice would be helpful

Hi all

Sorry that I created my post twice. I didn't notice that all posts are pre-moderated.
Finally I have resolved problem by self.
A new network interface from other VPC subnet 172.16.60.10/24 was added to CHR instance. And ipsec policy was modified for use this new net.

Now config is following on AWS CHR side:

/ip address
add address=172.16.60.10/24 interface=ether2 network=172.16.60.0

/ip ipsec peer
add address=5.145.132.xxx/32 dh-group=modp1024 \
enc-algorithm=aes-256,aes-128,3des local-address=172.16.30.178 secret=\
"$secret" send-initial-contact=no

/ip ipsec policy
add dst-address=192.168.254.0/24 sa-dst-address=5.145.132.xxx sa-src-address=\
172.16.30.178 src-address=172.16.60.0/24 tunnel=yes

Tunnel is working now. I can ping 172.16.60.10 ip from the Office LAN 192.168.254.0/24 and vice versa.