IPsec VPN - RouterOS and FreeBSD

FreeBSD suggests using Racoon as the IKE daemon, and I buy that recommendation since RouterOS also uses racoon internally (hint: look at the ipsec,debug)

But this "simple"-tunnel method of RouterOS it a bit tricky to replicate on a default racoon setup. In this example I will use a IP-in-IP tunnel (also called ipencap) and has IP Protocol 4 (IP/4), but using a GRE (IP/47) should also be fine.

  • Route-based tunnel - not Proxy/Policy-based
  • Using IP-in-IP tunnel type ("ipencap" / IP Protocol 4)
  • Site A tunnel endpoint - 192.168.254.1/32
  • Site A local network - 192.168.1.0/24
  • Site B tunnel endpoint - 192.168.254.2/32
  • Site B local network - 192.168.2.0/24

SITE_A_IP and SITE_B_IP is the corresponding public IP-addresses. This howto doesn't cover any required firewall openings.

This is what I found out and works.

Site A - RouterOS

1. Setup tunnel interface on RouterOS, and setup a linknet

/interface ipip
add name=tun1 ipsec-secret=XXXXXXXXXX local-address=SITE_A_IP remote-address=SITE_B_IP
/ip address
add address=192.168.254.1/30 interface=tun1
/ip route
add dst-address=192.168.2.0/24 gateway=192.168.254.2

You're done on RouterOS.

Site B - FreeBSD

1. Setup tunnel interface and services on your FreeBSD (or similar system)

/etc/rc.conf:

cloned_interfaces="gif0"
ifconfig_gif0="inet 192.168.254.2 192.168.254.1 netmask 255.255.255.255 tunnel SITE_B_IP SITE_A_IP"
racoon_enable="YES"
ipsec_enable="YES"
ipsec_file="/usr/local/etc/racoon/setkey.conf"

gateway_enable="YES"
static_routes="net1"
route_net1="-net 192.168.1.0/24 192.168.250.1"

2. Configuration for racoon. Please note the "address SITE_B_IP 4 address SITE_A_IP 4" where the 4 is for ipencap (IP/4) tunnel packets.

/usr/local/etc/racoon/racoon.conf:

path pre_shared_key "/usr/local/etc/racoon/psk.txt";
log notify;

listen {
    isakmp          SITE_B_IP [500];
}

remote SITE_A_IP [500] {
    exchange_mode       main;
    proposal_check      obey;

    # phase 1
    proposal {
        encryption_algorithm    aes 128;
        hash_algorithm          sha1;
        authentication_method   pre_shared_key;
        lifetime time           3600 secs;
        dh_group                2;
    }
}

# phase 2
sainfo (address SITE_B_IP 4 address SITE_A_IP 4) {
    pfs_group                       2;
    lifetime                        time 3600 sec;
    encryption_algorithm            aes 128;
    authentication_algorithm        hmac_sha256, hmac_sha1;
    compression_algorithm           deflate;
}

3. This one is tricky, the IPsec kernel policy configuration. This tells the kernel IP-stack - that traffic from SITE_B_IP to (out) SITE_A_IP that is of type ipencap (IP/4) shall be of encrypted with IPsec transport type ESP. The next line is for the opposite direction.

/usr/local/etc/racoon/setkey.conf:

flush;
spdflush;
spdadd SITE_B_IP SITE_A_IP ipencap -P out ipsec esp/transport/SITE_B_IP-SITE_A_IP/require;
spdadd SITE_A_IP SITE_B_IP ipencap -P in ipsec esp/transport/SITE_A_IP-SITE_B_IP/require;

4. And of course the shared secret.

/usr/local/etc/racoon/psk.txt:

SITE_A_IP    XXXXXXXX

Then of course restart services or do a full reboot.

I prefer route-based tunnels since they work almost like a physical link, and you can use traceroute and standard tools. Your routes decide whats reachable. Policy based tunnels are a bit magic and bypasses standard routing, and I find them hard to troubleshoot.

The theory of operation here is that the tunnel itself gets encrypted, not the specific packets going trough it.

  1. Packet arrives at Site A router. Router makes route lookup and the decision to forward packet to tunnel inteface.
  2. Tunnel encapsulates packet.
  3. Packet then matches Source, Destination and Protocol number defined in IPsec kernel policy (setkey.conf), witch applies the transport encryption.
  4. Encrypted payload leaves router

ifconfig gif0 should display:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
    options=80000<LINKSTATE>
    tunnel inet SITE_B_IP --> SITE_A_IP
    inet 192.168.254.2 --> 192.168.254.1  netmask 0xffffffff 
    inet6 fe80::a3d9:9ef1:721c:a309%gif0 prefixlen 64 scopeid 0x4 
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: gif

A tcpdump should show the something like:

19:04:14.700751 IP SITE_A_IP > SITE_B_IP: ESP(spi=0x06b57eb9,seq=0x12), length 136
19:04:15.706837 IP SITE_B_IP > SITE_A_IP: ESP(spi=0x02a7da91,seq=0x10), length 136
19:04:15.707011 IP SITE_A_IP > SITE_B_IP: ESP(spi=0x06b57eb9,seq=0x13), length 136
19:04:16.715800 IP SITE_B_IP > SITE_A_IP: ESP(spi=0x02a7da91,seq=0x11), length 136

Good luck!

How are you doing these days? (English)

For a long time, I used a Linux machine with iptables firewall. I had this for many years, but when the need for wireless arrived, the choice fell on Linksys WRT54G, which also took over the firewall parts. It was later replaced with a Netgear WNR3500L since it had integrated Gigabit-switch.

Unfortunately, in a couple of years, most people have acquired wireless at home and the 2Ghz-band was becoming very noisy with all neighborÕs stuff. It didn't make it better that every ISP sends their combined modem and access point (which also often is really bad ones)

I realized that it was time to use the 5GHz band, since my PC already had support for this. I've also realized that I wanted to run OpenWRT, and the hardware from Broadcom does not play well with opensource unfortunally. So the choice fell on a TP-Link WDR3600. This really does its job well and works completely trouble-free with OpenWRT.

Why not DD-WRT?

DD-WRT felt phenomenal when it came. All of a sudden you had features that you never thought possible with cheap sub-$100 routers. You could fine-tune the parameters to improve the reliability significantly. But after a few years, I thought the whole project felt a bit weird. It never came new releases, only new "builds" that seem to be the complete jungle which builds that were stable or not. No changelogs, no security updates. The whole project seems to be a * one-man-show *, but at the same time some kind of commercial facade? No one really knows.

Why not OpenWRT?

OpenWRT is a fantastic project. It is much more than just an alternative firmware; it is a complete solution for embedded systems. But it is still "only" a Linux distribution to be fair, even if LuCI is a very nice interface. It also lacks some proprietary optimizations and features that only a manufacturer can have full knowledge of (due to NDA agreements, and so on...) There is also no what if continuous updates and security fixes. You simply have to nicely wait for a new release.

Hello RouterOS

On weekdays, I work with IT-security and networking equipment. It ranges from stuff sitting in a closet somewhere to half a meter high gear in noisy datacenters. These usually have very specific functions or exceptional performance, and their exceptionally high price tags. But this affects. What can you use at home, but without paying hundreds of dollars for hardware and licenses?

I can recommend the Latvian manufacturer Mikrotik with it's RouterOS and Routerboard. They made previously only a little more pricey pure router modules, but has now begun to use the same type of Atheros/Qualcomm chipsets such as TP-Link and others. It's Linux-based of course.

Advantages

  • Has support for everything you would expect from a entry-line enterprise router.
  • They have different types of hardware depending on performance requirements ($40 to $2000).
  • They develop on their own hardware for their software, hence very reliable.
  • They have the opportunity to use the hardware support (NAT and forwarding in hardware)
  • They release new software continuously, and it is almost ridiculously easy to upgrade.
  • They have a proper CLI which is actually really good and useful (and colorful). Some big-player vendors should actually be ashamed.
  • It is good quality radio design, construction and components.
  • Web interface is great to.
  • Larger models support encryption in hardware, providing lovely VPN performance.

Cons

  • Licensed - But new hardware includes one standard license, and they are not that pricey.
  • Their switches do not support IGMP snooping (Not quite sure this)
  • No "cluster" support - However, failover with standard VRRP is available.
  • Some of the cheap models (home-ones) have limited flash-storage - Not possible to use all functions/packages.

I myself have now this gear for the moment, on different physical locations.

  • RB260GS - Switch _ (SWOS, not RouterOS) _
  • RB wAP AC 802.11ac + 802.11n - AP + Firewall
  • RB922UAGS-5HPacD - 802.11ac - AP + Firewall
  • RB912UAG-2HPnD - 802.11n (2x2) - Used as repeater
  • RB hAP - 2.4Ghz 802.11n (2x2) - At my parents place

RouterOS Neighbours Neighbors list

Wireless performance Wireless performance is great to (2x2 11ac-40Mhz)