ipsec tunnel only works when both sides send data

RouterOS General
1

Hi all!

We have a setup with a RB4011iGS+ in the central and both RB4011iGS+ and hAP ac^2 remote.
There are IPSEC tunnels between the remote locations and the central.

Short issue description: The issue is that the tunnels only work if both sides send a first packet (e.g. a ping) over the tunnel. It does not work for just one side to establish e.g. a TCP connection.

Details:
At the time when the issue arises, the tunnels are already successfully established (PH2 state established), but the packet count for the active peer on both sides is 0.
If any side (central or remote) wants to establish a connection (forwarded or input to the router itself), it times out, unless the other sides also initiates a data transmission to just any destination on the other end of the tunnel.
It is the same behavior in both directions.

IPSEC config central:
policy:
0 A peer=remote tunnel=yes src-address=172.19.0.0/16 src-port=any dst-address=172.17.0.0/16 dst-port=any protocol=all
action=encrypt level=require ipsec-protocols=esp sa-src-address= sa-dst-address=
proposal=remote ph2-count=1
peer:
0 R name=“remote” address= passive=yes profile=remote exchange-mode=ike2
send-initial-contact=no

IPSEC config remote:
policy:
0 A peer=central tunnel=yes src-address=172.17.0.0/16 src-port=any dst-address=172.19.0.0/16 dst-port=any protocol=all
action=encrypt level=require ipsec-protocols=esp sa-src-address=0.0.0.0 sa-dst-address=
proposal=remote ph2-count=1
peer:
0 name=“gwhgb” address= profile=remote exchange-mode=ike2 send-initial-contact=yes

Any advice?

Thanks!

2

it cant be the same for both ends src-address=172.19.0.0/16 src-port=any dst-address=172.17.0.0/16

for example
central src-address=172.19.0.0/16 src-port=any dst-address=172.17.0.0/16
remote src-address=172.17.0.0/16 src-port=any dst-address=172.19.0.0/16

3

Thanks for taking your time to respond! However, I do not understand what you are suggesting. your example matches the actual configuration. Is your example an example of how it should work or an example of how it should not be configured?

Regards

4

May be something with firewall, exactly rule “RELATED, ESTABLISHED”?
Both sides send packets and awaiting reply, so incoming packet is treated as reply.
Also, do you try only ping or some other traffic?

5

I’d look at keepalive mechanisms. If there is no way for the router to detect a tunnel failure, then it will happily send packets via the tunnel that no longer has a valid security association (SA) until the byte counter or tunnel timer expire.

Imagine if router B reboots. It has no knowledge of the tunnel prior to the reboot, so it establishes a new tunnel. However, router A doesn’t detect the old tunnel session has been lost. It now has both the old tunnel and the new tunnel established to router B. However, I believe it will continue using the old tunnel until it expires.

6

Thanks for the replies!

I’d look at keepalive mechanisms. If there is no way for the router to detect a tunnel failure, then it will happily send packets via the tunnel that no longer has a valid security association (SA) until the byte counter or tunnel timer expire.

Imagine if router B reboots. It has no knowledge of the tunnel prior to the reboot, so it establishes a new tunnel. However, router A doesn’t detect the old tunnel session has been lost. It now has both the old tunnel and the new tunnel established to router B. However, I believe it will continue using the old tunnel until it expires.

Good point, however whenever the issues is there, I always just see one association and it is this exact association that counts up as soon as the sides start sending packets. So I assume that isn’t it.

May be something with firewall, exactly rule “RELATED, ESTABLISHED”?
Both sides send packets and awaiting reply, so incoming packet is treated as reply.
Also, do you try only ping or some other traffic?

I think it has to be something around that, but I do not see the flaw.
No connection what so ever is working across the tunnel before both sides send packets. I just use ping to get the connection going (although any kinf of packet does the trick).
The rule set on the central is more complicated, but this is the rule set of the remote site (pretty much the default):

 1    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid

 2    ;;; access to router via VPN
      chain=input action=accept log=no log-prefix="" ipsec-policy=in,ipsec

 3    ;;; access to router via VPN
      chain=output action=accept log=no log-prefix="" ipsec-policy=out,ipsec

 4    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked

 5    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp

 6    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1

 7    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN log=no log-prefix=""

 8    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec

 9    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec

10    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related

11    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked

12    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid

13    ;;; defconf: drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN
7

I can also confirm problem.
Main router ccr1009 and hap ac established ipsec tunnel without any problem but without traffic.
Then on my main router i disable firewall rule for input icmp drop, and everything is working fine.
After that you can enable the drop rule, and tunnel is still working.
But for initial traffic icmp has to be enabled.
Best regards…

8

In my case, I actually do not need to allow icmp, I just need to send ANY data from both directions to make the tunnel work.

 7 X  ;;; Alow IPSEC Tunnels in
      chain=input action=accept log=yes log-prefix="" ipsec-policy=in,none

which actually works. But this rule allows just ANY traffic to the input chain, no matter if ipsec or not. So I do not understand what ipsec-policy=in,none is actually doing.

Anyway, what seems to solve it for me is the rule:

7    ;;; Alow IPSEC Tunnels in
      chain=input action=accept protocol=ipsec-esp log=yes log-prefix=""

Regards

9

That rule number 7 in your first example is BAD, it allows any traffic without IPsec.
The rule to allow ESP is correct when you have an IPsec tunnel between systems that don’t have NAT between them.
For NAT you need UDP port 4500.

A rule with ipsec-policy match is normally used to allow in,ipsec traffic (to allow all traffic coming in via a tunnel, presumably from a trusted network).
Rules with ipsec-policy=in,none are often only used to drop certain traffic, not to accept it.

10

Understood, thanks for the clarification!

Unfortunately allowing site-to-site traffic in, but limit it to certain VLANs is not so well documented (or I am not capable of finding it).
The default ipsec-policy-in allow rule does not work if you have your network segmented in different security zones.

11

As always, when you want to make things more clear I would recommend not to make direct IPsec policies but to create GRE/IPsec tunnels and route the traffic over those tunnels.
This is easy to setup in RouterOS because you can specify an IPsec key in a GRE interface and all policies will be created automatically.
And because you now have a virtual interface where only the site-to-site traffic is passing through, firewall rules will also be easier to make and maintain.

Just set some /30 networks on the tunnel endpoints (outside of the network ranges you are using for LAN) and set static routes or use BGP or OSPF to autoroute.
This also enables the use of multiple redundant tunnels, e.g. GRE over IPv4 and GRE over IPv6 in parallel.