Blog.gowifi

Blog.gowifi

logos (other)

Logos

Go Wireless NZ

Follow by Email

Monday, April 16, 2018

Mikrotik Site-to-Site IPsec VPN


In this blog, we will look at how to establish a Site-to-Site VPN between two Mikrotik routers


Prerequisites: Each router can ping each their respective neighbour on their public-facing IP address (or have a route to reach it)

Firstly, let's set up some firewall rules so that each LAN can communicate with each other:

In this example, Workstation1 wants to communicate, via the IPsec tunnel, with Workstation3. With NAT rules present, this would not be successful.

To rectify this, we will add a simple firewall rule and place it before our default NAT masquerade rule:

Office1 Router
/ip firewall nat
add chain=srcnat action=accept place-before=0 \
src-address=10.1.202.0/24 dst-address=10.1.101.0/24 

Office2 Router
/ip firewall nat
add chain=srcnat action=accept place-before=0 \
src-address=10.1.202.0/24 dst-address=10.1.101.0/24

This will stop packets destined for the IPsec tunnel from having their source address encrypted

Another issue we may encounter after configuring our IPsec tunnel is Fasttrack. Fasttrack bypasses IPsec policies, so we need to create an explicit accept rule and place it before our Fasttrack rules in the firewall of each router:

/ip firewall filter
add chain=forward action=accept place-before=1 \
src-address=10.1.101.0/24 dst-address=10.1.202.0/24 \
connection-state=established,related
add chain=forward action=accept place-before=1 \
src-address=10.1.202.0/24 dst-address=10.1.101.0/24 \
connection-state=established,related

These rules will add significant load to the CPU if there is a fair amount of tunnels and significant traffic on each tunnel. The solution to this is to use RAW firewall tables. This bypasses connection tracking, that way eliminating the need to filter the rules listed above

/ip firewall raw
add action=notrack chain=prerouting src-address=10.1.101.0/24 dst-address=10.1.202.0/24
add action=notrack chain=prerouting src-address=10.1.202.0/24 dst-address=10.1.101.0/24

Now we can get to the main event, configuring the IPsec tunnel itself

First, we need to specify our remote peer, authentication method and secret. This is the bare minimum requirement to establish a Site-to-Site IPsec VPN but more parameters could be adjusted if required. In this example, we will use a pre-shared key of "test" which is inadvisable in real-world deployments

Office1 Router
/ip ipsec peer
add address=192.168.80.1/32 auth-method=pre-shared-key secret="test"
Office2 Router
/ip ipsec peer
add address=192.168.90.1/32 auth-method=pre-shared-key secret="test"

For IPsec VPN tunnels to successfully negotiate, each respective proposal must match. For this particular example, we will use the default proposal which will ensure a successful connection. 

We will now create an IPsec policy to link to the proposal:

Office1 Router
/ip ipsec policy
add src-address=10.1.202.0/24 src-port=any dst-address=10.1.101.0/24 dst-port=any \
sa-src-address=192.168.90.1 sa-dst-address=192.168.80.1 tunnel=yes \
action=encrypt proposal=default
Office2 Router
/ip ipsec policy
add src-address=10.1.101.0/24 src-port=any dst-address=10.1.202.0/24 dst-port=any \
sa-src-address=192.168.80.1 sa-dst-address=192.168.90.1 tunnel=yes \
action=encrypt proposal=default

You should now have a functional IPsec VPN tunnel

To verify, issue the following commands:

/ip ipsec 
remote-peers print
installed-sa print

You should see the tunnel is established and each router has created two Security Associations

Thanks for reading. Was this blog helpful? please feel free to comment or rate it below.

No comments:

Post a Comment