Community discussions

MikroTik App
 
ysha
just joined
Topic Author
Posts: 12
Joined: Wed Sep 16, 2015 11:04 am

FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Sat Jun 27, 2020 6:03 am

Hi, has anyone managed to make an "ipsec tunnel" between Freebsd(Linux) using ipsec-tools with racoon on one side and Mikrotik on the other in "tunnel" mode when each side has its own local LAN? Can someone publish the material how to do this? Each side has a "white" static ip. Maybe there are at least some ideas how to create a similar FreeBSD on Mikrotik?

https://www.freebsd.org/doc/ru_RU.KOI8- ... ipsec.html
FreeBSD side:
ifconfig gif0 A. B. C. D W. X. Y. Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff

Mikrotik ?
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Sat Jun 27, 2020 11:48 am

The settings on the link you gave describe a setup which uses a virtual interface as an entry point to the IPsec processing of the packet, whereas RouterOS currently only supports the method specified in the IPsec RFC, which is selection of traffic for sending via the IPsec SA using matching on IP protocol (udp, tcp , ...), source and destination addresses, and source and destination ports where applicable. That RFC also requires that received packets matching any IPsec traffic selection criteria that were not received via a corresponding IPsec SA must be dropped.

The traffic selector of the SA is not only used locally but also negotiated between the peers. The "virtual interface" approach uses an "any to any" traffic selector, so you cannot use a traffic selector on Mikrotik side and virtual interface on the remote side just like that. A workaround is possible, which consists in defining a list of exceptions from "any to any" and assigning "action=none" to these exceptions, but it can be used only for a single remote peer.

So first, check whether FreeBSD can support also the traffic selection method, and if yes, go that way. If it cannot, the simplified idea is the following:

/ip ipsec policy
add action=none src-address=0.0.0.0/0 dst-address=0.0.0.0/1
add action=none src-address=0.0.0.0/0 dst-address=192.0.0.0/2
add action=encrypt src-address=0.0.0.0/0 dst-address=0.0.0.0/0 peer=FreeBSD


This way, packets to 0.0.0.0-127.255.255.255 are matched by the first policy, packets to 192.0.0.0-255.255.255.255 by the second one, and only packets to 128.0.0.0-191.255.255.255 make it to the last policy which sends them down the SA.

By extending this approach, you can narrow the address range which makes it to the last policy to the destinatinon subnet you want to be sent to the FreeBSD peer while the traffic selector used to negotiate the SA will be "any to any".

It only makes sense to dive into the details of how to set the encryption and integrity protection algorithms and peer authentication methods once you resolve this key aspect.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
ysha
just joined
Topic Author
Posts: 12
Joined: Wed Sep 16, 2015 11:04 am

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Sun Jun 28, 2020 6:43 pm

Thanks for the information, let's assume the FreeBSD side settings will be in accordance with the schema https://www.freebsd.org/doc/ru_RU.KOI8- ... etwork.png
from https://www.freebsd.org/doc/ru_RU.KOI8- ... ipsec.html

# ifconfig gif0
gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --> W.X.Y.Z

# netstat -rn
Routing tables Internet:
Destination Gateway Flags Refs Use Netif Expire
192.168.2.1 192.168.1.1 UH 0 0 gif0

# ipsec sa policy
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

# racoon.conf
remote W.X.Y.Z {
nat_traversal off;
exchange_mode main;
proposal {
encryption_algorithm des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}

sainfo anonymous {
pfs_group 2;
lifetime time 1 hour;
encryption_algorithm des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}

Mikrotik is side 2 - W.X.Y.Z 192.168.2.1 (192.168.2.0/24)

Which Mikrotik settings should correspond to this scheme. Let's assume that encryption methods and key information exchange policies have been achieved.

Could you or Mikrotik specialists provide the basic interface, routing, and ipsec sa policy settings so that the FreeBSD-Mikrotik ipsec tunnel works? Perhaps needed to change some settings on the FreeBSD side to match Mikrotik.

This would significantly contribute to the promotion of Mikrotik products as this problem makes it difficult to use them in conjunction with existing OS such as Linux and FreeBSD.
 
ysha
just joined
Topic Author
Posts: 12
Joined: Wed Sep 16, 2015 11:04 am

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Wed Jul 01, 2020 6:08 pm

Tell, why the this example doesn't work https://serverfault.com/questions/77937 ... -only-icmp
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Wed Jul 01, 2020 6:44 pm

Please be patient. In my previous post, I've tried to explain
  • what is the essential incompatibility between the apparently only possible setup on the FreeBSD (with a virtual interface) and the definitely only possible setup on the RouterOS (with policy-based packet selection),
  • what is the possible workaround,
  • what are the limitations of that workaround.
In parallel, I was remotely debugging an almost identical setup where the FreeBSD is substituted by Google Cloud Platform, but the debugging has come to a dead end as what perfectly works for me, on the same CPU architecture (x64/CHR) and RouterOS release (6.45.9) like the OP of that topic uses, doesn't work for the OP.

As in the meantime you have provided all the other settings necessary, the only thing which is not elementary is to compose the exception policies for the Mikrotik end. As soon as I find enough time for that, I'll post the complete IPsec setup which should work against the FreeBSD one set the way you've posted originally. But it will not be in just hours from now.

The setup you ask about now, which is based on use of GRE instead of a virtual interface as an entry point of the IPsec SA itself, is definitely an alternative, but it's a different approach, so it deserves a separate topic. It also has its drawbacks, namely, it may not work if one of the peers is behind NAT, but at least it removes the limitation to a single connection of the same type on the RouterOS side (you can have several GRE over IPsec tunnels, but only one tunnel with a virtual interface on the remote peer).
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
ysha
just joined
Topic Author
Posts: 12
Joined: Wed Sep 16, 2015 11:04 am

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Thu Jul 02, 2020 8:53 am

Thank you for your participation, I will wait for information
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Thu Jul 02, 2020 3:45 pm

OK, so let's start by a good news - you can forget all what I wrote about the incompatibility in my first response, as I have confused a gif tunnel with a vti one, due to the title of the topic title which mentions IPsec tunnel mode alone.

According to this article, in its IPv4 over IPv4 mode, the FreeBSD's gif (referring to RFC 2893, which is an evolution of RFC 1933, as an inspiration) is compatible with the ipip tunnel, standardized by RFC 2003. No cross-reference between these two RFCs can be found in either of them, however the packet format differs in just the payload protocol type (4 for IPv4/RFC 2003 and 41 for IPv6/RFC 2893); I didn't dive into all those ICMP and TTL handling details and loop prevention mechanisms.

So given that both A.B.C.D and W.X.Y.Z are directly routable (no NAT between them), it would be best to first check this layer of compatibility alone, before diving into IPsec.

At Mikrotik side, you add the tunnel interface using
/interface ipip add name=freebsd-gif0 local-address=W.X.Y.Z remote-address=A.B.C.D !keepalive

The "logical addresses" as FreeBSD refers to them may be added using
/ip address add address=192.168.2.1/32 network=192.168.1.1/32 interface=freebsd-gif0


For GRE, you would just use /interface gre instead of /interface ipip in the step above (at RouterOS side). Except the IP protocol to be matched by the policy (the tunneling protocol itself), the IPsec layer settings will be the same regardless whether the inner tunnel used will be GIF/IPIP or GRE.

In RouterOS configuration, a Phase 1 proposal mostly matches an /ip ipsec profile. Hence
remote W.X.Y.Z {
        nat_traversal off;
        exchange_mode main;
        proposal {
                encryption_algorithm des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}
translates into
/ip ipsec profile add name=FreeBSD enc-algorithm=des hash-algorithm=sha1 nat-traversal=no
/ip ipsec peer add name=FreeBSD address=A.B.C.D local-address=W.X.Y.Z exchange-mode=main profile=FreeBSD
/ip ipsec identity add peer=FreeBSD auth-method=pre-shared-key secret=verycomplexsecret


Phase 2 proposal is called /ip ipsec proposal, so
sainfo anonymous {
      pfs_group 2;
      lifetime time 1 hour;
      encryption_algorithm des;
      authentication_algorithm hmac_sha1;
      compression_algorithm deflate;
}
translates into
/ip ipsec proposal add name=FreeBSD pfs-group=modp1024 lifetime=1h enc-algorithms=des auth-algorithms=sha1
There is no way to control use of compression algorithm in RouterOS so I suspect it is not used at all. It seems that it must be specified it in Racoon configuration but it is used only as an proposed option, not a mandatory requirement.

Lastly, in RouterOS, the policy for both SAs is configured using a single line, where the src-address represents the local IP or subnet and the dst-address represents the remote one. So
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
translates into
/ip ipsec policy add src-address=W.X.Y.Z dst-address=A.B.C.D ipsec-protocols=esp tunnel=yes proposal=FreeBSD protocol=ipencap level=require peer=FreeBSD

However, as you have public IP addresses at both machines and the gif/ipip/gre tunnels are linked to them (A.B.C.D, W.X.Y.Z), you can save some packet space by using a transport mode of IPsec - to do that, you need to change the above to
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunneltransport/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunneltransport/W.X.Y.Z-A.B.C.D/require;

and
/ip ipsec policy add src-address=W.X.Y.Z dst-address=A.B.C.D ipsec-protocols=esp tunnel=yesno proposal=FreeBSD protocol=ipencap level=require peer=FreeBSD


For GRE, the protocol field would be set to gre rather than ipencap.

Mikrotik is side 2 - W.X.Y.Z 192.168.2.1 (192.168.2.0/24)
This part is a bit confusing. In Mikrotik IP address configuration, the network parameter of an /ip address row must either be the subnet into which the IP address itself fits, or a /32 address representing the remote end of the tunnel to the routing (so that you could specify it as a gateway of a route rather than the tunnel interface itself). So to reach the whole 192.168.1.0/24 via the tunnel, you have to manually add a route:
/ip route add dst-address=192.168.1.0/24 gateway=192.168.1.1
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
ysha
just joined
Topic Author
Posts: 12
Joined: Wed Sep 16, 2015 11:04 am

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Thu Jul 02, 2020 4:59 pm

Thank you for the information.

Which route rule should be on the FreeBSD side for Mikrotik side remote LAN 192.168.2.0/24
(similarly Mikrotik side "/ip route add dst-address=192.168.1.0/24 gateway=192.168.1.1") ?

static_routes="vpn"
route_vpn="192.168.2.0/24 192.168.2.1"

or

static_routes="vpn"
route_vpn="192.168.2.0/24 -interface gif0"

I assume the gif configuration is as follows:

ifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff

and which version RouterOS do you recommend for this: Long-Term 6.45.9 or Stable 6.47 ?
 
sindy
Forum Guru
Forum Guru
Posts: 5343
Joined: Mon Dec 04, 2017 9:19 pm

Re: FreeBSD (racoon) - ipsec tunnel mode - Mikrotik

Thu Jul 02, 2020 5:41 pm

Which route rule should be on the FreeBSD side for Mikrotik side remote LAN 192.168.2.0/24
(similarly Mikrotik side "/ip route add dst-address=192.168.1.0/24 gateway=192.168.1.1") ?
I'm not familiar with the structure of FreeBSD configuration, so since the tunnel configuration somewhere else indicated a shorter than a 32 bit netmask, I've assumed they somehow add the destination subnet to the tunnel parameters.

If it is not the case, there is in fact no need to assign any IP addresses to the tunnel endpoint interfaces at all, unless you need to use recursive next-hop search or dynamic routing protocols. So if you do assign them, both the route with the IP of the remote end of the tunnel as gateway and the route with the local interface name will work, at both the FreeBSD end and the RouterOS end. But if you want to assign the IP addresses to the tunnel endpoint interfaces, I'd recommend not to use ones that fit into larger subnets. Technically there is nothing wrong about doing so, but some behaviour may not be intuitive for the administrator.

which version RouterOS do you recommend for this: Long-Term 6.45.9 or Stable 6.47 ?
From the point of view of IPsec and IPIP/GRE tunnel configuration there is no difference between these two. But the general rule is to use long-term wherever its feature set is sufficient for the purpose.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: Majestic-12 [Bot], sindy and 71 guests