How to integrate F5 BIG-IP VE with GNS3

I would like to start by saying Merry Christmas and Happy Holidays season to all. In between spending time with my family, decorating the Christmas three and opening presents, I did find some time to play around with my hobby and testing something in the lab.

Lately I wanted to get a feeling how F5 BIG-IP works, you know, just to get familiar with its interfaces, rules and being capable of setting up a basic LTM or APM. Far from me the idea of becoming an expert on the first touch, but it’s nice to discover new technologies.

Beside getting the F5 BIG-IP VE (Virtual Edition), running up VMware (ESXi, Player, Fusion or Workstation) and starting the virtual machine I also wanted to emulate some kind of real environment to test. So, I did build the below topology in GNS3:

F5 BIG-IP Simple setup

Some explanation:

  • Client WIN7 is a VM in VirtualBox and integrated in GNS3
  • WWW Servers are VMs in VirtualBox and integrated in GNS3
  • WIN2008 AD DC is a VM in VirtualBox and integrated in GNS3
  • Routers are emulated in GNS3
  • F5 BIG-IP VE is a VM in VMware Workstation and integrated as a Cloud in GNS3

GNS3 is version 1.2.1 which works perfect. Why VirtualBox and VMware Workstation? Usually I have no problem to have my VMs in VirtualBox, but I could not successfully import the F5 BIG-IP VE OVA image in VirtualBox. I had to download a trial version of VMware Workstation to install the OVA image.

If you want to know more about this F5 product, Ethan Banks has a great article about the BIG-IP VE. Please note that Ethan’s article is about getting a lab license for BIG-IP VE. I just went for the trial version. You can download the OVA image and get the license here:
https://www.f5.com/trial/secure/big-ip-ltm-virtual-edition.php

Download the BIG-IP VE OVA image, get a trial license (valid for 90 days) and install it in VMware Workstation. It may work with other VMware products, but in this article I’m using only VMware Workstation.

The part that gave me some headache was the how to have a successfully network communication between VMware Workstation and GNS3.

Before GNS3 1.2.1, when I had to use a “cloud” to integrate VirtualBox VMs in GNS3, I was configuring a TAP interface and use Bridge mode for the VM NIC to the TAP interface. Then on the GNS3 Cloud, I was adding the TAP as a Generic Ethernet NIO on the NIO Ethernet. If you want to refresh more deeply the above information please read my article about How to integrate GNS3 with VirtualBox.

Unfortunately, in VMware Workstation, I cannot just bridge a VMnet interface to a TAP and use that specific VMnet in a VM. I just could not make it work.

To cut it short, here are the steps that I had to follow to have this working. I assume that you have VMware Workstation installed already. Another detail is that I’m using Ubuntu 14.04 to test the entire scenario.

1. Add two VMnet interfaces in VMware Workstation Virtual Network Editor

Use the image below to have an idea what I mean.

Virtual Network Editor

2. Configure the BIG-IP VE NIC as follow in VMware Workstation

I assume that you have the BIG-IP VE OVA imported in VMware Workstation

BIG-IP VE NIC

I had 4 NICs originally, but I only need three:

  • VMnet0 is bridge to my real LAN interface so I can manage the F5 BIG-IP VE over Web / CLI interfaces
  • VMnet11 – one “internal” interface facing LAN (server side)
  • VMnet22 – one “external” interface facing WAN (client side)

3. Configure two tap interfaces for F5 BIG-IP VE to be used in GNS3

11 – internal, 22 – external

sudo tunctl -u user -t tap11
sudo tunctl -u user -t tap22

*user = the non-root user which you use on Ubuntu host.

If you are having problems to find tunctl command please do the following:

sudo apt-get install uml-utilities bridge-utils

Bring the interfaces up

sudo ifconfig tap11 up
sudo ifconfig tap22 up

4. Remove the IP addresses on both TAP and VMnet interfaces

sudo ifconfig tap11 0.0.0.0 promisc up
sudo ifconfig tap22 0.0.0.0 promisc up
sudo ifconfig vmnet11 0.0.0.0 promisc up
sudo ifconfig vmnet22 0.0.0.0 promisc up

5. Bridge the TAP and the VMnet interfaces

sudo brctl addbr br11
sudo brctl addif br11 tap11
sudo brctl addif br11 vmnet11
sudo brctl addbr br22
sudo brctl addif br22 tap22
sudo brctl addif br22 vmnet22

Bring the bridge interfaces up

sudo ifconfig br11 up
sudo ifconfig br22 up

5. Add the F5 BIG-IP VE to GNS3

If with GNS3 1.2.1 you can add the VirtualBox VMs directly, for the VMware Workstation (Player, Fusion, etc…) VMs you still need to you the Cloud part.

My GNS3 for F5 topology looks like this:

F5 topology in GNS3

And the GNS3 Cloud (representing the F5 BIG-IP VE) settings are the following:

F5 GNS3 Cloud settings

6. Connect the GNS3 Cloud interfaces to R1 and R2

Like shown in the image above, connect the TAP interface of the Cloud to the peer routers.

I’m running all applications (GNS3, VMware Workstation, VirtualBox) as non-root user. If you’re doing the same an error may occur in GNS3. Something like:

Server error [-3200] from x.x.x.x:8000: R1: unable to create TAP NIO

If this is the case, please run the following command on Ubuntu host:

sudo setcap cap_net_admin,cap_net_raw=ep /usr/local/bin/dynamips

This will help you setup the environment to test F5 BIG-IP VE in a lab environment totally virtualized. I’m not going to cover here how to configure the F5 BIG-IP VE. Maybe in one of my next articles.

If you encounter problems, please let me know in Comments.

GNS3 1.2.1 installation on Ubuntu 14.04

As mentioned in an earlier post GNS3 is moving ahead fast. Currently at version 1.2.1 the GNS3 is looking great. Compared with the version 1.0 Beta 1 which I had installed, the 1.2.1 is not only more stable, but it has the Menu more clean and compact. For example now there is only one Preferences menu where you can adjust all your settings.

During the installation of 1.0 Beta 1 I made some notes in Evernote and it prove to be very useful as the installation was pretty messy. With 1.2.1 I did the same thing, but the installation was very smooth. Still, I said that if I made those notes maybe I should share them for those interested in a quick installation. A more complete guide can be found on GNS3 Community.

1. Download GNS3 1.2.1

Head over to http://www.gns3.com/, create and account and download the bundle archive for Linux.

If you for some reason you don’t want to create an account, you may download each package individually from https://github.com/GNS3

The following lines will assume that you have the bundle archive.

2. Install Ubuntu 14.04 dependencies

$ sudo apt-get install libpcap-dev uuid-dev libelf-dev cmake
$ sudo apt-get install python3-setuptools python3-pyqt4 python3-ws4py python3-netifaces python3-zmq python3-tornado
$ sudo apt-get install unzip 

3. Unzip the bundle archive

$ unzip GNS3-1.2.1.source.zip

You should see 5 packages in GNS3-1.2.1 folder:
dynamips-0.2.14.zip
gns3-server-1.2.1.zip
gns3-gui-1.2.1.zip
iouyap-0.95.zip
vpcs-0.6.zip

4. Install Dynamips

$ unzip dynamips-0.2.14.zip
$ cd dynamips-0.2.14
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo make install

To check if the correct version is install:

$ dynamips | grep version

You should see in the output 0.2.14

5. Install GNS3 Server

$ unzip gns3-server-1.2.1.zip
$ cd gns3-server-1.2.1
$ sudo python3 setup.py install

To check if the GNS3 Server is installed correctly:

$ gns3server

If you see some output other than an error, than you’re fine.

6. Install GNS3 GUI

$ unzip gns3-gui-1.2.1.zip
$ cd gns3-gui-1.2.1
$ sudo python3 setup.py install

To test if the installation is working:

$ gns3

You should see a graphical interface of GNS3 launched.

At this moment you have a working GNS3 environment if you want only want to test Cisco hardware emulators. I strongly recommend to continue and install also the rest of the components. Who knows when you’ll need them

7. Install IOUyap (Optional, if you will use IOU images)

$ unzip iouyap-0.95.zip
$ cd iouyap-0.95.zip
$ make
$ sudo make install

To test the installation:

$ iouyap -h

If you encounter an error, please check the [Update 1] section at the bottom of this article.

8. Install VPCS (Optional, if you want to use VirtualPC)

$ unzip vpcs-0.6.zip
$ cd vpcs-0.6/src
$ ./mk.sh 64
$ cp vpcs /usr/bin/

For the third line, the 64 represent 64bit, as my Ubuntu 14.04 is build on 64bit.
The values can be:
– 32 or i386 for 32bit OS
– 64 or amd64 for 64bit OS

Please be sure to use the correct one for your OS.

To test the VPCS:

$ vpcs

You should see a Virtual PC being launched. Leave the console with letter q.

9. Install VirtualBox (Optional, if you want to launch VMs)

Download the correct version for your system from https://www.virtualbox.org/wiki/Linux_Downloads. The following lines will assume an Ubuntu 14.04 64bit OS.

$ apt-get install dkms
$ dpkg -i virtualbox-4.3_4.3.20-96996~Ubuntu~raring_amd64.deb

You can also use the instructions at https://www.virtualbox.org/wiki/Linux_Downloads and go for an APT installation.The choice is yours.

10. Install Qemu (Optional, if you want to use qemu images)

$ sudo apt-get install qemu

11. Install IOU (Optional, if you want to use IOU images)

I’m not a legal matter expert, and the usage of IOU is sort of grey area. Because of this, I’m not going to cover this chapter.

You’re ready to go. Start the GNS3 GUI:

$ gns3

Some things to check before going live:

  • check in the menu Edit > Preferences to set your desired Paths (in General sections) and to check the paths for the binaries (dynamips, vpcs, iou, virtualbox…)
  • add the IOS, virtualbox vm, iou images
  • in case of Cisco hardware emulators don’t forget to find the IdlePC value (when you add the IOS image or later with the start of your first router with a certain image) otherwise your CPUs will cry.

If something does not work as described or you need help please let me know in Comments.

[Update 1]

If you get the following error during installation of iouyap:

GNS3-1.2.2.source/iouyap-0.95 $ make
gcc -g -DDEBUG -Wall -c -o iouyap.o iouyap.c
iouyap.c:40:23: fatal error: iniparser.h: No such file or directory
#include
^
compilation terminated.
make: *** [iouyap.o] Error 1

Try to install the iniparser as follows:

sudo apt-get install flex bison

then

cd /tmp
curl -L https://github.com/ndevilla/iniparser/archive/master.tar.gz | tar -xz
cd iniparser*
make

and finally iouyap

cd /tmp
curl -L https://github.com/GNS3/iouyap/archive/master.tar.gz | tar -xz
cd iouyap*
bison -ydv netmap_parse.y
flex netmap_scan.l
gcc -Wall *.c -I /tmp/iniparser*/src -L /tmp/iniparser* -o iouyap -liniparser -lpthread
strip --strip-unneeded iouyap
sudo mv iouyap /usr/local/bin

Thanks to mweisel @ forum.gns3.net for this update!

Cisco BGP soft-reconfiguration and received-routes relation

A while ago I received the following question:

“Why I’m not seeing the prefixes received from the BGP peer when using the show ip bgp neighbors x.x.x.x received-routes while the soft-reconfiguration inbound is not enabled?”

I must admit that I had to stop and think for a second before giving my response.

Simple BGP

For the above diagram I have a simple BGP configuration:

router bgp 65301
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 192.168.0.2 remote-as 65302
 neighbor 192.168.0.2 timers 5 15
 !
 address-family ipv4
  network 1.1.1.1 mask 255.255.255.255
  network 2.2.2.2 mask 255.255.255.255
  network 3.3.3.3 mask 255.255.255.255
  neighbor 192.168.0.2 activate
 exit-address-family
router bgp 65302
 bgp log-neighbor-changes
 neighbor 192.168.0.1 remote-as 65301
 neighbor 192.168.0.1 timers 5 15

Focus is on the secondary router. I’m trying to see what prefixes I receive from my BGP neighbor, so I rapidly hit the following command:

R2#sh ip bgp neighbors 192.168.0.1 received-routes
% Inbound soft reconfiguration not enabled on 192.168.0.1

OK, that’s not good. Am I missing the command? Let’s see:

R2#sh ip bgp neighbors 192.168.0.1 ?
  advertised-routes  Display the routes advertised to a BGP neighbor
  dampened-routes    Display the dampened routes received from neighbor (eBGP
                     peers only)
  flap-statistics    Display flap statistics of the routes learned from
                     neighbor (eBGP peers only)
  paths              Display AS paths learned from neighbor
  policy             Display neighbor polices per address-family
  received           Display information received from a BGP neighbor
  received-routes    Display the received routes from neighbor
  routes             Display routes learned from neighbor
  |                  Output modifiers

-> received-routes – Display the received routes from neighbor

OK, I know the soft-reconfiguration inbound is not enabled, but what has this to do with the fact that the command is not showing me what routes I receive from BGP neighbor?

Let’s recall what “soft-reconfiguration inbound” command actually does.

BGP soft-reconfiguration inbound
*Cisco BGP-4 Command and Configuration Handbook

According to the above explanation, if you have an inbound policy (like a route-map) applied to a BGP neighbor and you change that policy, you need to clear the BGP session before it take effect. This is the procedure without having “soft-reconfiguration inbound” configured. I remember it like this and most of the network engineers out there remember this behavior associated with the “soft-reconfiguration inbound” command.

Still, I just want to see what routes I received from BGP neighbor and according with “sh ip bgp neighbors 192.168.0.1 received-routes” description is the right command . I have no inbound policy on R2 for R1 BGP neighbor.

A less remembered fact about the “soft-reconfiguration inbound” command is that when added, the router begins to store updates from the specified neighbor. These updates are unmodified by any existing inbound policies so that the router can correctly apply the new policies when soft reconfiguration is triggered.

Where are these updates stored?

In the BGP Adj-RIB-in (Adjacent Routing Information Base, Incoming) table. So, what the “received-routes” command does actually is looking in the BGP Adj-RIB-in table for the received routes from the BGP neighbor. I consider that the “received-routes” command has an ambiguous explanation leading to confusion.

When “soft-reconfiguration inbound” is not present, the BGP router does not store anything in Adj-RIB-in. Rather it process the update and discard the Adj-RIB-in table, but not before adding the information in the Loc-RIB (Local Routing Information Base) table. Knowing these facts of course the BGP router returns an error when trying to check the received prefixes using the “received-routes” command.

To check actually what’s received from BGP peer and stored in the Loc-RIB (after being processed by inbound policies) use only the “routes” parameter in the command:

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

-> routes – Display routes learned from neighbor

The output is what exists in the Loc-RIB table, after processed by the inbound policy.

Let me show you an example of the above explanation.

I’ll apply the “soft-reconfiguration inbound” first:

R2(config-router)#neighbor 192.168.0.1 soft-reconfiguration inbound

Now I’ll check again the received routes:

R2#sh ip bgp neighbors 192.168.0.1 received-routes  | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

OK, so I have three prefixes, reflected in the Adj-RIB-in table.
Checking next the Loc-RIB tables (so the routes installed after being processed by inbound policies):

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *>  3.3.3.3/32       192.168.0.1              0             0 65301 i

Total number of prefixes 3

The Adj-RIB-in and Loc-RIB tables are identical.

Now, I’ll apply an inbound policy that will filter the 3.3.3.3 prefix.

R2(config)#ip prefix-list LIST permit 3.3.3.3/32
R2(config)#route-map INBOUND deny 10
R2(config-route-map)#match ip address prefix-list LIST
R2(config-route-map)#route-map INBOUND permit 1000
R2(config-route-map)#router bgp 65302
R2(config-router)#neighbor 192.168.0.1 route-map INBOUND in

OK, we have the “soft-reconfiguration inbound” in place, so the inbound policies should be applied automatically denying the 3.3.3.3 prefix.

R2#sh ip bgp neighbors 192.168.0.1 received-routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i
 *   3.3.3.3/32       192.168.0.1              0             0 65301 i

The above output is what we receive from BGP peer. Notice that the 3.3.3.3 prefix is still there, in the Adj-RIB-in table, as the inbound policies are not applied yet. The only visible change is the missing > sign (best).

R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
     Network          Next Hop            Metric LocPrf Weight Path
 *>  1.1.1.1/32       192.168.0.1              0             0 65301 i
 *>  2.2.2.2/32       192.168.0.1              0             0 65301 i

Now we can see that the inbound policy is working fine as the 3.3.3.3 prefix is not installed in the Loc-RIB table. This is also the explanation why the > (best) sign was missing from the 3.3.3.3 prefix in Adj-RIB-in.

I hope you understood the logic behind the confusion which these commands “received-routes” and “routes” and their explanation in IOS is creates.

Please let me know in Comments if you have any questions.

IPsec VPN Mikrotik to Linux

After writing the Mikrotik IPsec VPN article and I got some questions about how Mikrotik will work with a Linux device to build an IPsec VPN. I did notice that the questions were more oriented for a copy / paste solution, so I’ll provide one that it’s working. If you need more details about why the solution is like it this, please let me know.
Also don’t forget to customize the solution as you need.

I’ll start with the same topology like in the last post, just that the right side now it’s a Linux device.

Mikrotik-IPsec-VPN-Linux

Please consider the minimum ports needed to be open on your firewall from my earlier article. Just don’t forget to open these ports also on the Linux device.

First let’s configure the Mikrotik.

The IPsec Proposal

CLI

ip ipsec proposal add name=MyProposal auth-algorithms=sha1 enc-algorithms=aes-256-cbc pfs-group=none

GUI

IP > IPsec > Proposals

Name: MyProposal
Auth. Algorithm: sha1
Encr. Algorithm: aes-256 cbc
PFS Group: none

The IPsec Policy

CLI

ip ipsec policy add src-address=192.168.0.0/24 dst-address=172.30.0.0/24 protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes sa-src-address=11.11.11.11 sa-dst-address=22.22.22.22 proposal=MyProposal

GUI

IP > IPsec > Policies

SRC ADDR: 192.168.0.0/24
DST ADDR: 172.30.0.0/24
Protocol: all
Action: Encrypt
Level: require
IPsec protocols: esp
Tunnel: check
SA SRC: 11.11.11.11
SA DST: 22.22.22.22
Proposal: MyProposal

The IPsec Peer

CLI

ip ipsec peer add address=22.22.22.22 port=500 auth-method=pre-shared-key secret=my_preshared_key exchange-mode=main send-initial-contact=yes nat-traversal=yes proposal-check=obey hash-algorithm=sha1 enc-algorithm=3des,aes-128 dh-group=modp1024 generate-policy=no

GUI

IP > IPsec > Peers

Address: 22.22.22.22
Port: 500
Auth. Method: pre shared key
Passive: not checked
Secret: my_preshared_key
Policy Template Group: default
Exchange mode: main
Send Initial Contact: checked
NAT Traversal: checked
My ID: Auto - empty
Proposal Check: obey
Hash Algorithm: sha1
Encryptions Algorithm: 3des aes-128
DH Group: modp1024
Generate policy: no

Now, the Linux part. I’m using Ubuntu, but I’m not going to advocate here for one flavour or another. So, just use any device with Linux or you try solutions such as Amazon AWS. Install Openswan (compile it from source or install via your Linux flavour package system).

The main file for Openswan is ipsec.conf. For me this file is in /etc, but I assume it can reside in another location.

For the above example, the ipsec.conf file looks like this:

version 2.0

# basic configuration
config setup
        nat_traversal=yes
        oe=off
        protostack=netkey
        force_keepalive=yes
        keep_alive=60
        #nhelpers=0

# Add connections here
conn mikrotik-to-linux
        authby=secret
        auto=start
        type=tunnel
        left=22.22.22.22
        leftid=22.22.22.22
        leftsourceip=172.30.0.1
        leftsubnet=172.30.0.0/24
        right=11.11.11.11
        rightsubnet=192.168.0.0/24
        rightid=11.11.11.11
        pfs=no
        forceencaps=yes
        ike=aes256-sha1;modp1024
        phase2=esp
        phase2alg=aes256-sha1

You need to associate the keyword “left” with “local” and “right” with “remote” and it will be easier to read the configuration above.

Also in the /etc location I have another file called ipsec.secrets which has the pre-shared secret key:

22.22.22.22 11.11.11.11 : PSK "my_preshared_key"

This is the minimal configuration that I need to apply to have the IPsec VPN up and running. I’m sure that it can be fine tuned to add more security or features, but that is not in scope of this post.

As always if you have problems please let me know in Comments.

Mikrotik IPsec VPN

If you did not hear yet about Mikrotik I can’t say I blame you. Not exactly something you’ll find in SOHO network shops next to brand like TP-Link, Linksys or Netgear. Mikrotik is a company
in Latvia that produce network hardware under the name of RouterBOARD. The devices are excellent and the RouterOS support an amazing amount of feature for a SOHO product.

As recently I did develop a small VPN network based on IPsec and using Mikrotik RB951G-2HnD platform, I had the idea to put together a short how to for the enthusiast out there who wants to try these products. Now, I’m not saying that this is the best or the only approach, but it’s a start from which you can develop your own fine tuned solution.

Let’s assume that we have the following topology:

Mikrotik-IPsec-VPN

The idea is to build a VPN using IPsec technology between the two routers. The RouterOS version is 6.23, so earlier versions may not support all features described here, but I’ll try to point this where is the case.

As some people are more comfortable with GUI and others with CLI, I’ll describe both methods. If you are following this blog post, I assume that you are already a bit familiar with RouterOS and your Mikrotik device is connected at least to Internet.

In this example I’ll focus on the left side of the diagram. The right side is configured in the same way.

Before going into the real IPsec configuration, please be sure to have the following ports open on your Mikrotik firewall:

500/UDP - Internet Key Exchange (IKE)

4500/UDP - NAT Traversal, when NAT it's in use

IP Proto 50 - Encapsulating Security Payload (ESP)

IP Proto 51 - Authentication Header (AH)

You may not use these protocols after following this blog post, but it’s OK to have them open if you want to experiment. They can be closed later after you decide what to use, but we don’t want this as a blocking point and force us into troubleshooting.

You can allow the following ports into Mikrotik firewall as follow into CLI:

ip firewall filter add chain=input proto=ipsec-ah action=accept place-before=0
ip firewall filter add chain=input proto=ipsec-esp action=accept place-before=0
ip firewall filter add chain=input proto=udp port=500 action accept place-before=0
ip firewall filter add chain=input proto=udp port=4500 action accept place-before=0

The place-before=0 is to force the rule on the top of your Input table.

On GUI, check the

IP > Firewall > Filter Rules > Input table

Another thing to remember if you’re using NAT like in the picture above is that the LAN subnets have to be allowed to communicate directly, before they are pass to masquerade rule.

CLI

ip firewall nat add chain=srcnat src-address=192.168.0.0/24 dst-address=172.30.0.0/24 action=accept place-before=0

GUI

IP > Firewall > NAT

Let’s start now with the IPsec configuration part.

First let’s define a new IPsec Proposal policy. There is a default one which comes preconfigured but I would like to use my own.

CLI

ip ipsec proposal add name=MyProposal auth-algorithms=sha1 enc-algorithms=aes-256-cbc pfs-group=none

GUI

IP > IPsec > Proposals

Name: MyProposal
Auth. Algorithm: sha1
Encr. Algorithm: aes-256 cbc
PFS Group: none

As mentioned earlier in this post, depending on your RouterOS version, you can have here different options. Just pick what suits your needs.

Next we need to define an IPsec Policy.

CLI

ip ipsec policy add src-address=192.168.0.0/24 dst-address=172.30.0.0/24 protocol=all action=encrypt level=require ipsec-protocols=esp tunnel=yes sa-src-address=11.11.11.11 sa-dst-address=22.22.22.22 proposal=MyProposal

GUI

IP > IPsec > Policies

SRC ADDR: 192.168.0.0/24
DST ADDR: 172.30.0.0/24
Protocol: all
Action: Encrypt
Level: require
IPsec protocols: esp
Tunnel: check
SA SRC: 11.11.11.11
SA DST: 22.22.22.22
Proposal: MyProposal

I think that settings are obvious, just be careful to correctly pick the sources (SRC ADDR and SA SRC). The SRC values are from local site while the DST part has to be the remote site.

Last we need to define a least one IPsec Peer

CLI

ip ipsec peer add address=22.22.22.22 port=500 auth-method=pre-shared-key secret=my_preshared_key exchange-mode=main send-initial-contact=yes nat-traversal=yes proposal-check=obey hash-algorithm=sha1 enc-algorithm=3des,aes-128 dh-group=modp1024 generate-policy=no

GUI

IP > IPsec > Peers

Address: 22.22.22.22
Port: 500
Auth. Method: pre shared key
Passive: not checked
Secret: my_preshared_key
Policy Template Group: default
Exchange mode: main
Send Initial Contact: checked
NAT Traversal: checked
My ID: Auto - empty
Proposal Check: obey
Hash Algorithm: sha1
Encryptions Algorithm: 3des aes-128
DH Group: modp1024
Generate policy: no

Be careful that if you are on version RouterOS 5.xx (just as an example) the Encryptions Algorithm field supports only one value and not multiple like configured above. I did especially to highlight that there are differences depending on the RouterOS version. Nevertheless the baseline for IPsec VPN configuration remains the same.

If you have questions or something does not work as explained please let me know in Comments.