Page 1 of 1

Sucessful Amazon CHR RouterOS Test

Posted: Tue Oct 25, 2016 12:47 pm
by killersoft
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.
My_AWS_CHR1.jpg
My_AWS_CHR2 after upgrade to current release candidate.jpg
I briefly tested webproxy too and found that worked well..

Re: Sucessful Amazon CHR RouterOS Test

Posted: Mon Oct 31, 2016 12:08 am
by petersonz
A few questions:

How did you upgrade your AWS image?
The Full x86 PKG file?
Does that remove the virtual optimized drivers for CHR?

Re: Sucessful Amazon CHR RouterOS Test

Posted: Mon Oct 31, 2016 11:07 am
by normis
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Mon Oct 31, 2016 5:33 pm
by petersonz
Thanks. It nice that its kept simple that way. By architecture like Routerboards.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Tue Nov 01, 2016 3:55 am
by killersoft
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

Re: Sucessful Amazon CHR RouterOS Test

Posted: Sat Nov 05, 2016 12:23 pm
by WillCartledge
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Sat Nov 05, 2016 1:45 pm
by mpreissner
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Tue Nov 22, 2016 2:25 am
by ditonet
@killersoft
Did you managed to run CHR with second network interface added?

Regards,

Re: Sucessful Amazon CHR RouterOS Test

Posted: Mon Jan 23, 2017 3:46 am
by hca
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

Re: Sucessful Amazon CHR RouterOS Test

Posted: Tue Jan 24, 2017 12:18 am
by ditonet
Default user is 'admin'.
Here is Wiki article about CHR installation on AWS:
http://wiki.mikrotik.com/wiki/Manual:CH ... stallation

HTH,

Re: Sucessful Amazon CHR RouterOS Test

Posted: Tue Jan 31, 2017 9:54 pm
by hogsberg
@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?

Re: Sucessful Amazon CHR RouterOS Test

Posted: Wed Feb 01, 2017 2:05 pm
by ditonet
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,

Re: Sucessful Amazon CHR RouterOS Test

Posted: Fri Feb 03, 2017 10:35 am
by janisk
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Fri Feb 03, 2017 12:44 pm
by ditonet
@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 :D .

Regards,

Re: Sucessful Amazon CHR RouterOS Test

Posted: Fri Feb 03, 2017 1:55 pm
by hogsberg
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Fri Feb 03, 2017 2:22 pm
by janisk
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Fri Feb 03, 2017 3:42 pm
by hogsberg
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

Re: Sucessful Amazon CHR RouterOS Test

Posted: Mon Feb 06, 2017 10:14 am
by janisk
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Wed Feb 15, 2017 11:11 pm
by hca
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".

Re: Sucessful Amazon CHR RouterOS Test

Posted: Thu Feb 16, 2017 5:28 pm
by hca
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

Re: Sucessful Amazon CHR RouterOS Test

Posted: Tue Feb 21, 2017 11:18 am
by hogsberg
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...

Re: Sucessful Amazon CHR RouterOS Test

Posted: Fri Feb 24, 2017 5:23 am
by Aveyer
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.

Re: Sucessful Amazon CHR RouterOS Test

Posted: Fri Jul 27, 2018 8:02 pm
by hazar
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

Re: Sucessful Amazon CHR RouterOS Test

Posted: Sat Jul 28, 2018 11:12 am
by hazar
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

Re: Sucessful Amazon CHR RouterOS Test

Posted: Mon Jul 30, 2018 6:23 pm
by hazar
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.