IPsec Mikrotik to Linux (Racoon): No traffic through tunnel

I am trying to setup an GRE over IPsec tunnel between a Mikrotik router (RB750Gr3; Running RouterOS 6.46.4) and a Raspberry Pi running IPsec-Tools and Racoon (The Pi is still running Raspbian Stretch).

While setting up a GRE tunnel is fairly easy (and so is IPsec when you get the hang of it), the combination of the two is giving me problems sofar. I cannot even get ICMP to flow through the tunnel, let alone GRE.

1.1.1.1 = WAN address Mikrotik.
2.2.2.2 = WAN address NAT router. The Raspberry Pi behind the NAT router has internal IP-address 192.168.2.2.

10.0.0.1/30 = GRE endpoint Mikrotik router
10.0.0.2/30 = GRE endpoint Raspberry

The Mikrotik router is configured as a responder, so the IPsec tunnel will only start when the Raspberry initiates traffic.

Configuration Mikrotik:

[admin@router] /ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder
 1   R ;;; Raspberry
       name="Raspberry" address=2.2.2.2/32 local-address=1.1.1.1 passive=yes profile=vpn-s2s
       exchange-mode=main send-initial-contact=yes

[admin@router] /ip ipsec identity print
Flags: D - dynamic, X - disabled
 0    ;;; Raspberry
      peer=Raspberry auth-method=pre-shared-key secret="verysecretpassword" generate-policy=no

[admin@router] /ip ipsec profile print
Flags: * - default
 4   name="vpn-s2s" hash-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp2048,modp1024 lifetime=1d
     proposal-check=obey nat-traversal=no dpd-interval=30s dpd-maximum-failures=3

[admin@router] /ip ipsec proposal print
Flags: X - disabled, * - default
 1    name="vpn-s2s" auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=30m pfs-group=modp1024

[admin@router] /ip ipsec policy print detail
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
 1  A  peer=Raspberry tunnel=yes src-address=10.0.0.1/32 src-port=any dst-address=10.0.0.2/32 dst-port=any
       protocol=all action=encrypt level=require ipsec-protocols=esp sa-src-address=1.1.1.1
       sa-dst-address=2.2.2.2 proposal=vpn-s2s ph2-count=1

Configuration Raspberry:
/etc/ipsec-tools.conf:

flush;
spdflush;

spdadd 10.0.0.2/32 10.0.0.1/32 any -P out ipsec
  esp/tunnel/192.168.2.2-1.1.1.1/require;
spdadd 10.0.0.1/32 10.0.0.2/32 any -P in ipsec
  esp/tunnel/1.1.1.1-192.168.2.2/require;

/etc/racoon/racoon.conf:

log notify;
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

padding
{
        maximum_length 20;      # maximum padding length.
        randomize off;          # enable randomize length.
        strict_check off;       # enable strict check.
        exclusive_tail off;     # extract last one octet.
}

listen
{

        adminsock disabled;
        isakmp 192.168.2.2 [500];
        isakmp_natt 192.168.2.2 [4500];
        strict_address;
}

timer
{
        counter 5;
        interval 20 sec;
        persend 1;
        phase1 30 sec;
        phase2 15 sec;
        natt_keepalive 60 sec;
}

remote 1.1.1.1
{
        exchange_mode main,base;
        lifetime time 24 hour;
        doi ipsec_doi;
        situation identity_only;
        send_cert off;
        send_cr off;
        verify_cert off;
        initial_contact on;
        proposal_check obey;
        nat_traversal on;
        dpd_delay 30;
        dpd_maxfail 3;

        proposal
        {
                encryption_algorithm aes256;
                hash_algorithm sha256;
                authentication_method pre_shared_key;
                dh_group modp2048;
        }

}

sainfo anonymous
{
        pfs_group modp1024;
        encryption_algorithm aes256;
        authentication_algorithm hmac_sha256;
        compression_algorithm deflate;

}

/etc/racoon/psk.txt:

1.1.1.1 verysecretpassword

As GRE traffic did not make it through the tunnel, I decided to test using simple ICMP. I configured a vlan interface on the Mikrotik router (with an unused vlan number) and a dummy interface on the Raspberry and assigned each its 10.0.0.x/30 address.

As soon as I initiate an ICMP action (ping) from the Raspberry to the Mikrotik router, the IPsec connection comes online. Using ‘/tool sniffer’ I send the traffic to wireshark (which is running on my PC). I let wireshark decrypt the IPsec tunnel to see what traffic is running through the tunnel.

This is what I see:

622	15.561220	10.0.0.2	10.0.0.1	ICMP	225	Echo (ping) request  id=0x0a0c, seq=1/256, ttl=64 (no response found!)
622	15.561220	10.0.0.2	10.0.0.1	ICMP	225	Echo (ping) request  id=0x0a0c, seq=1/256, ttl=64 (no response found!)
625	15.561646	10.0.0.2	10.0.0.1	ICMP	221	Echo (ping) request  id=0x0a0c, seq=1/256, ttl=64 (no response found!)
625	15.561646	10.0.0.2	10.0.0.1	ICMP	221	Echo (ping) request  id=0x0a0c, seq=1/256, ttl=64 (no response found!)

The ICMP packet from the Raspberry to the Mikrotik router makes it through the IPsec tunnel, but does not get an answer.

NAT bypass for the 10.0.0.0/30 network on the Mikrotik router is active:

[adminfreek@PE1PQF] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
 0    ;;; NAT bypass
      chain=srcnat action=accept src-address=10.0.0.0/30 log=no log-prefix="NATBYPASS"

However, packets never hit this rule. The question therefore is: Why do I not get a reply either way? (When the IPsec tunnel is established, pinging both ways does not work. I can see traffic going in the tunnel, but it never exits). It does not seem to be a firewall issue. Simple rules at the beginning of the input or forward chain allowing all traffic does not help.

Does anyone have an idea what is going wrong here?

Problem solved!

Turns out that lowering the crypto level for phase 1 (profile) and phase 2 (proposal) solves the issue. I made the following changes:

Profile:

[admin@router] /ip ipsec profile print
Flags: * - default
 4   name="vpn-s2s" hash-algorithm=sha1 enc-algorithm=aes-128,3des dh-group=modp1024 lifetime=1d proposal-check=obey
     nat-traversal=no dpd-interval=30s dpd-maximum-failures=3

Proposal:

[admin@router] /ip ipsec proposal print
Flags: X - disabled, * - default
 1    name="vpn-s2s" auth-algorithms=sha1 enc-algorithms=aes-128-cbc,3des lifetime=30m pfs-group=none

I am not sure why this is necessary, but the GRE tunnel over IPsec is up and running now and I can ping both sides of the tunnel either way.