No traffic through IPSec tunnel (if opnSense side initiate)

RouterOS General
1

Hi
We struggling with IPSec tunnels where we have between opnSense FW’s and a Mikrotik CCR1009-7G-1C-1S+

opnSense:
local net: 10.0.172.0/24
WAN Endpoint: 11.33.55.77
Config:

connections {
    ec2943b5-7b5a-453e-87ad-b5a1287d2d9c {
        proposals = aes256-sha512-modp2048,aes256-sha512-ecp521
        unique = no
        aggressive = no
        version = 2
        mobike = no
        local_addrs = 11.33.55.77
        remote_addrs = 22.44.66.88
        encap = no
        dpd_delay = 120
        send_certreq = yes
        local-e50a4a28-5a6c-4691-a390-79fa40745218 {
            round = 0
            auth = psk
            id = 11.33.55.77
        }
        remote-5c0f8aa5-ff3b-4ae9-b425-4acf1f617671 {
            round = 0
            auth = psk
            id = 22.44.66.88
        }
        children {
            d4ac59ed-59b6-4b7d-943f-4cfcb0a04b80 {
                esp_proposals = aes256-sha256-modp2048,aes256-sha512-modp2048,aes256-sha256-ecp521,aes256-sha512-ecp521
                sha256_96 = no
                start_action = start
                close_action = none
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 10.0.172.0/24
                remote_ts = 10.0.10.0/24
                rekey_time = 3600
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child d4ac59ed-59b6-4b7d-943f-4cfcb0a04b80
            }
        }
    }
}
pools {
}
secrets {
    ike-5906a6a1-2ffa-45d6-8ff7-da66cdfe79ea {
        id-0 = 11.33.55.77
        id-1 = 22.44.66.88
        secret = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    }
}

Mikrotik:
local net: 10.0.10.0/24
WAN Endpoint: 22.44.66.88
Config:

/ip ipsec profile set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip ipsec profile add dh-group=ecp521 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-256 hash-algorithm=sha512 name=myProf_1 nat-traversal=no
/ip ipsec peer add address=11.33.55.77/32 exchange-mode=ike2 local-address=22.44.66.88 name=myEndpoint_1 profile=myProf_1
/ip ipsec proposal set [ find default=yes ] disabled=yes
/ip ipsec proposal add auth-algorithms=sha512 enc-algorithms=aes-256-cbc name=myProposal_1 pfs-group=ecp521
/ip ipsec identity add my-id=address:22.44.66.88 peer=myEndpoint_1 remote-id=address:11.33.55.77 secret="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
/ip ipsec policy set 0 disabled=yes
/ip ipsec policy add dst-address=10.0.172.0/24 level=unique peer=myEndpoint_1 proposal=myProposal_1 src-address=10.0.10.0/24 tunnel=yes

If we ping, try ssh or whatever from the net behind the opnSense, we didn’t get any response, but we can see the incoming ipsec packets on the Mikrotik side, but no packets from or to any internal IP’s, only WAN IP’s:

Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE     TIME   NUM  DIR  SRC-MAC            DST-MAC            SRC-ADDRESS     DST-ADDRESS     PROTOCOL      SIZE  CPU
WAN 2 ether6  0.354    1  <-   10:5A:xx:xx:xx:xx  18:FD:xx:xx:xx:xx  11.33.55.77  22.44.66.88  ip:ipsec-esp   186    5
WAN 2 ether6  0.45     2  <-   10:5A:xx:xx:xx:xx  18:FD:xx:xx:xx:xx  11.33.55.77  22.44.66.88  ip:ipsec-esp   186    5
WAN 2 ether6  0.578    3  <-   10:5A:xx:xx:xx:xx  18:FD:xx:xx:xx:xx  11.33.55.77  22.44.66.88  ip:ipsec-esp   186    5
WAN 2 ether6  0.578    4  <-   10:5A:xx:xx:xx:xx  18:FD:xx:xx:xx:xx  11.33.55.77  22.44.66.88  ip:ipsec-esp   186    5
WAN 2 ether6  0.578    5  <-   10:5A:xx:xx:xx:xx  18:FD:xx:xx:xx:xx  11.33.55.77  22.44.66.88  ip:ipsec-esp   186    5
WAN 2 ether6  1.042    6  <-   10:5A:xx:xx:xx:xx  18:FD:xx:xx:xx:xx  11.33.55.77  22.44.66.88  ip:ipsec-esp   186    5

Without reinitiating the tunnel or doing something else, if we ping from a local net behind the Mikrotik environment to a host behind the opnSense, we got a response and from this moment, the traffic is working from both side, so also from the hosts behind the opnSense can ssh or ping hosts behind the Mikrotik net.
This works for some hours and then we have to “initiate” the connection again from a host behind the Mikrotik net.

We have two IPSec tunnels to different opnSense, both with the same problem and three other IPSec tunnels to Mikrotik endpoints, where works fine.

Any idea where we have to start to looking for to solve this?

Thanks a lot
Ivo

2

As both peers are on public addresses and therefore bare ESP is used for Phase 2, you have to make sure that ESP packets coming from the internet are allowed in. The firewall has no way to do that automatically based on information in the IKE (or IKEv2) exhange.

So add a rule protocol=ipsec-esp src-address=ip.of.the.opnsense action=accept to chain input of /ip/firewall/filter.

3

Solved: There was a missing firewall rule, where allow new ipsec connections on the WAN interface.
For me, it doesn’t make sense, that Phase 1 and 2 can be established, but anyway…

4

Yes, this solve the problem… Thank you.

5

For Phase 1, it is enough if one of the peers accepts incoming connections and the other one has a stateful firewall that automatically accepts responses to outgoing requests sent by the router itself or by devices on its LAN side, which is the default configuration on the SOHO models of Mikrotik. Because if both peers run on public or global addresses and none of them is set to passive (responder-only) mode, both keep actively trying to establish the connection.

The management of Phase 2 uses the same UDP ports like Phase 1, and no data plane check is made. So even if ESP was unable to pass in either direction, Phase 2 would nevertheless indicate success and perform rekeying if triggered by timers rather than just amount of data transported.