IPsec IKEv2 Tunnel Tuning

RouterOS General
1

Hi, I recently setup an IPsec tunnel (site to site) and I have a few questions about the configuration I chose to do so.
The topology is the following:

The “server” side (passive) configuration is as follows:

/ip address
add address=192.168.5.24/27 interface=ether1 network=192.168.5.0
/ip pool
add name=rw-pool ranges=192.168.77.2-192.168.77.254
/ip ipsec mode-config
add address-pool=rw-pool address-prefix-length=32 name=cfg1
/ip dhcp-client
add disabled=no interface=ether1
/ip firewall filter
add action=accept chain=forward connection-state=established,related dst-address=192.168.1.0/24 \
    src-address=192.168.5.0/27
add action=accept chain=forward connection-state=established,related dst-address=192.168.5.0/27 src-address=\
    192.168.1.0/24
add action=fasttrack-connection chain=forward
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.5.0/27
add action=masquerade chain=srcnat
/ip ipsec peer
add auth-method=rsa-signature certificate=server1 exchange-mode=ike2 generate-policy=port-strict \
    mode-config=cfg1 passive=yes
/ip ipsec policy
set 0 disabled=yes
add dst-address=192.168.1.0/24 src-address=192.168.5.0/27 template=yes
/ip route
add distance=1 gateway=192.168.5.2

And client side:

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=192.168.1.2/24 interface=ether2 network=192.168.1.0
/ip dns
set servers=192.168.1.1
/ip firewall filter
add action=accept chain=forward dst-address=192.168.5.0/27 src-address=192.168.1.0/24
add action=accept chain=forward dst-address=192.168.1.0/24 src-address=192.168.5.0/27
add action=fasttrack-connection chain=forward
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.5.0/27 src-address=192.168.1.0/24
add action=masquerade chain=srcnat
/ip ipsec peer
add address=***.dyndns.org auth-method=rsa-signature certificate=cert_export_client1.crt_0 exchange-mode=ike2 generate-policy=port-strict \
    mode-config=request-only
/ip ipsec policy
set 0 disabled=no
add dst-address=192.168.5.0/27 sa-dst-address=87.202.***.*** sa-src-address=192.168.1.2 src-address=192.168.1.0/24 tunnel=yes
/ip route
add distance=1 gateway=192.168.1.1
/system ntp client
set enabled=yes primary-ntp=194.177.210.54

With this configuration I get connected ok. The client side gets the IP from the server pool and I can ping both internal networks from either side.

My questions are:

  1. Are the policies I set correct in terms of encrypted traffic should be as supposed to be, encrypted. According to the wiki, If I don’t set accept rules in firewall for the internal networks at both sides I shouldn’t be able to ping either side. This is not the case. The only thing needed to ping beyond the two ends is the src-nat masquerade. Meaning tunnel traffic is NATed and not just accepted? So, either I am doing something wrong in the config or this is the way it’s supposed to work.

  2. I am using dynamic WAN address on both sides. Accroding to the wiki when setting the policies I have to explicitly configure SA-SRC and SA-DST address (real IP addresses) at both sides , in a mirror like config.
    The way I did it is
    Server side: created a template for the internal networks with SA-SRC and SA-DST with 0.0.0.0 and as SRC-ADDR the Internal subnet of the server and DST-ADDR the internal subnet of the client.
    Client side configured a tunnel policy stating the same in mirror fashion about SRC-ADDR and DST-ADDR, but this time I enter as SA-SRC the internal IP of the client (192.168.1.2) and SA-DST the WAN IP of the server. Upon connection I see the DA forming at the server side under my template.
    Is the configuration of policies correct? ( I have wrote a script to resolve and update the dyndns of the server not shown above and it work ok)

  3. Also I am not sure about the forward rules in Firewall concering fasttrack and bypass just followed the wiki for this.

  4. Is there anything else I should consider?

Thank you in advanced !

2

First, with dynamic WAN address at both sides no VPN connection can work sustainably. The side initiating the connection must know to which remote address to send the initial request. You would have to use something like dynamic DNS to work this around, and maybe some scripting as I’m not sure whether you can specify an fqdn instead of numeric IP as SA remote address. In any case, you must be aware that the tunnel will be falling down and re-establishing upon each change of the WAN address at any end.

If you can solve this issue somehow, and after reading some related explanations at http://forum.mikrotik.com/t/ipsec-between-mkt-and-fortigate-problem/115291/1 , please come back for more.

3

The topology doesn’t make sense. You have a switch attached directly to a modem, and a VPCS (don’t know what that is) attached directly to the switch. And a “MikroTik” (with no further description) attached to the switch as well. Is the modem a modem or a router and a modem?

Don’t guess about if the traffic is encrypted. Dump the traffic and analyze it to see if it’s encrypted.

Probably what you are doing is too complicated but the picture doesn’t help so I can’t tell for sure.

4

I updated the naming in the topology in the original post.

I am using the Routerboards for establishing the IPSec link. Nothing more. As stated in the original post I have written a script and schedule it to resolve the dyndns name of the server every 1 hour. So I have that covered. (I don’t mind droping the IPsec connection while resolving the WAN server address. It’s just for seconds)

Since the topology works my questions are firewall related.
I dont why it’s useful to place firewall rules add action=accept chain=forward dst-address=192.168.X.0/2X src-address=192.168.X.0/2X add action=accept chain=forward dst-address=192.168.X.0/2X src-address=192.168.X.0/2X on either side since without them I am able to ping and trace past the Mikrotik Routers , network devices at each side.
Also as mentioned I am a bit baffled about the fastrack setup in the firewall and If the policies I set up are correct, even though are working.

I have read the topic mentioned and if I understand correctly it marks the IPsec connection and just place it before drop the rest.

5

I dont why it’s useful to place

/ip firewall filter add action=accept chain=forward dst-address=192.168.X.0/2X src-address=192.168.X.0/2X
/ip firewall filter add action=accept chain=forward dst-address=192.168.X.0/2X src-address=192.168.X.0/2X

>
> on either side since without them I am able to ping and trace past the Mikrotik Routers , network devices at each side.

It boils down to how connection tracking works. For some connections (most illustrative example is a TCP session), if the initial packet matches its own "accept" rule, the firewall remembers the local and remote socket of that packet and all further packets of such "remembered" sessions, in both directions, match a generic condition "connection-state=established,related".

If action=fasttrack is triggered for a given packet matching that condition, not only any further processing of that packet on the firewall, but also its matching by IPsec policy, is skipped. So the role of your "accept" rules above is to accept these packets before they reach the "fasttrack" rule in the "filter" chain, which keeps them available for further handling by other firewall chains and by IPSec policy matching.

icmp is not connection-tracked, which explains why you can ping and traceroute addresses accessible through the tunnel even without these rules.

Your rules above actually do not care about connection states at all. If this is what you want, you may move them from "filter" to "raw" and set "no-track" as an action; according to the manual wiki, doing so will save you some CPU power. If you can find some use for connection tracking, you have to keep your rules in the "filter" chain above the "fasttrack" rule, but you should add "connection-state=established,related" to them.

Have I this time answered what you were actually asking? Sorry for missing the dynDNS note in your first post.
6

Thank you for the extended reply!

I think I will try your suggestion and move it to raw.
I have altered a bit the 192.168.5.0/27 side. A set the modem as bridge and now the ppoe Auth and routing is done by the Hex750Gr3. So that the firewall of the that side (server side) will have more active role, managing both every day routing and IPsec.

I will come back with results. One last question. How to check if tunnel packets are indeed encrypted? Use Wireshark for example?

7

I think I will try your suggestion and move it to raw.

and

So that the firewall of that (server) side will have more active role, managing both every day routing and IPsec.

are mutually exclusive. If you move the rules necessary to prevent fasttrack from shadowing IPSec policy to raw->prerouting, you effectively prevent the stateful firewall (connection tracking) from working. So you can do that at the “client” side, but not at the “server” side. At server side, keep those rules in filter->forward.

One last question. How to check if tunnel packets are indeed encrypted? Use Wireshark for example?

Yes, tools → packet sniffer → set file name and file size, then start, then generate some supposed-to-be-encrypted traffic, then stop, then download the file and open it with Wireshark. But as @acruhl has pointed out, your picture is not too informative regarding the logical topology of the network. From what you wrote I suppose that you have no VLANs there so the LAN traffic and the PPPoE traffic are mixed up in a single LAN and your switches are not manageable. I assume you have your reasons why you cannot conect the modem to one Ethernet port of Mikrotik and the switch and thus the rest of the LAN to another one.

In this case, I would look for L2 filtering capabilities of the modems and use them to prevent all packets with ethertype different from the two PPPoE ones from being forwarded to the ISP. The point is that otherwise LAN broadcasts packets like ARP packets, SSDP etc. as well as some unicast packets leak out to the uplink which consumes the uplink bandwidth and discloses information about devices in your LAN to the ISP.

If the switches are actually manageable, it may be easier to set these rules at the switches.

But back to the verification that the packets are encrypted - the point is that packet sniffing directly at Mikrotik exhibits some funny behaviour. Timestamps of decrypted received packets are for some reason ahead of those of their carrying IPSec (ESP) packets, and in some cases both the encrypted and decrypted version of the very same packet is captured at the same interface. So once your LAN and WAN logical interfaces share the same media, you have to look carefully at ethertype value (to tell normal IP over Ethernet packets from IP over PPPoE) and at MAC addresses of the sender and recipient. You may find the same packet there three times - first the unpacked one on its way from Mikrotik to the LAN device, with source MAC address of the Mikrotik and destination MAC address of the real recipient, after that the ESP packet encapsulated in PPPoE with source MAC address of your ISP’s PPPoE server and destination MAC address of the Mikrotik, and after that the decrypted version of that packet with same source and destination MAC addresses as before. While the actual order of these packets is 2,3,1 (first the encrypted one coming in from the internet, then the decrypted version of it, and last the decrypted version on its way to the LAN destination).

Edit: oops, @acruhl’s comment below has made me realize that I’ve mixed things up a bit. Yes, I had in mind to capture at the ethernet interface between the Mikrotik and the switch, so you’ll have both the LAN traffic and the PPPoE in the same file, and you’ll see what leaks out in parallel to PPPoE, but in this case, you should see in the capture only ethernet:pppoe:ip:udp:esp packets between the ISP and the Mikrotik and the ethernet:ip:whatever_l4_protocol packets between the Mirotik and the LAN device (talking about IPSec related packets here, you’ll likely see some ntp and dns traffic unencrypted as well). The decrypted version of the IPSec packets still on their way from the modem could be visible only if capturing at the PPPoE interface, where the PPPoE headers are already stripped down. For the IPSec packets, the in-interface is the PPPoE client one, not the etherX through which they actually come in from the PPPoE server.

8

It’s a good idea to bridge the modem and use the Mikrotik as the internet facing router. Makes ipsec easier. I’m just doing transport mode ipsec between 2 routers and then I use GRE tunnels to do routing between the sites. Works pretty good. I don’t have a script set up to automatically set the public IPs when they change though, I need to look into that.

That’s a good point sindy makes about looking at the outbound traffic to see what’s actually there.

You can do packet sniffer on the pppoe interface and see your encrypted traffic, but you’ll only see pppoe stuff.

If you look at the outbound ethernet interface, you’ll see “everything” including pppoe and any frames leaking out that shouldn’t be there.

I’ve been rather obsessed lately about checking to see if any of my “inside” traffic is leaking out to the internet. It is. Or it was anyway. I put in firewall rules to keep all RFC 1918 stuff from getting out, and I routinely look at a trace and just strip it down with Wireshark’s filters little by little until I account for everything.

The RB750Gr3 is really good for this because you can put in a large microsd card and save a lot of traffic to a file.

9

—Quick Update—

After changing the modem to bridge and having 750Gr3 to take over. All work ok. EXCEPT IPsec. When I do the same setup as before I can’t ping anything on the other side (192.168.1.0/24) , BUT the other side can ping the server and the hosts behind it (192.168.5.0/27 that is).

----Quick Update 2—
I had to select exit interface bridge1 other It was preselecting ppoe-out1 . That was the problem. Now everything is ok.

The hardware realization is a bit different from my Test machine I used before where it had two interfaces ether1 and ether 2. No bridging whatsoever. I have to get used to the bridge idea of the HEX 750Gr3.


Script for updating the WAN IP at the client Side.

:global RemoteSite [:resolve XXXXX.dyndns.org]
/ip ipsec policy set 1 sa-dst-address=$RemoteSite

I have named the script Remote-Site (same as the variable for convenience only) and set a scheduler (System–>Scheduler) to run this script every 1 hour.

/system scheduler
add interval=60m name=Remote-Site on-event=Remote-Site policy=read,write,policy start-date=
jan/06/2018 start-time=00:00:00

10

Cool, thanks for that. I need to learn MikroTik scripting at some point. I’ve done a few but it’s not sticking in my head.

On my setup I would have to set:

/ip ipsec peer set X address=$variable
/ip ipsec policy set X dst-address=$variable sa-dst-address=$variable

I have a dyndns account as well, but I’ve been using /ip cloud functionality for dynamic dns and it’s fine for if you only need the external address.

11

This script may help with the dynamic DNS aspect.

https://github.com/karrots/ros-ddns-ipsec