Community discussions

 
nishadul
Member Candidate
Member Candidate
Topic Author
Posts: 152
Joined: Thu Dec 13, 2012 12:04 pm
Location: Bangladesh

GRE tunnel with IPsec problem

Mon Jul 08, 2019 2:01 pm

Hi all,

I am using GRE tunnel with IPsec but IPsec make problem, problem is : some times suddenly R (running) not show of tunnel interface (and tunnel not work).
when I am removing IPsec from tunnel then show R. (and work tunnel)
OR
I am informing to my ISP they reboot there router then show R of tunnel interface.
I am not understanding why make problem and where.

Regards,
Nishadul
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: GRE tunnel with IPsec problem

Mon Jul 08, 2019 10:14 pm

What RouterOS version do you use? Are there Mikrotiks at both ends of the tunnel, and you administer both, or is one end of the tunnel under your administration and the other one is administered by the ISP staff?

Older versions of Mikrotik had issues with rekeying of the SAs.

When you use GRE without IPsec encryption, the IP protocol type travelling through the ISP's gear is GRE itself; when you use IPsec-encrypted GRE, the IP protocol type travelling through the ISP's gear is ESP, so the ISP may treat them differently.
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.
 
nishadul
Member Candidate
Member Candidate
Topic Author
Posts: 152
Joined: Thu Dec 13, 2012 12:04 pm
Location: Bangladesh

Re: GRE tunnel with IPsec problem

Thu Jul 11, 2019 6:01 am

My main router (head office) is x86 ROS version 6.45.1 another 4 side is RB951Hu-2hnd ROS version 6.45.1
yes I am administrator of both side router's
 
sindy
Forum Guru
Forum Guru
Posts: 3814
Joined: Mon Dec 04, 2017 9:19 pm

Re: GRE tunnel with IPsec problem

Thu Jul 11, 2019 11:27 am

As you can use GRE without IPsec, I assume that all routers have static public IP addresses on their WAN interfaces. Is this assumption correct?

In 6.45.1, a CVE has been fixed, so your firewall rules must now provide for acceptance of incoming GRE packets in some way. As the attributes of the GRE packets decapsulated from incoming ESP packets are slightly different than those of GRE packets which come directly, there could theoretically be an issue in this, but this theory doesn't play well with your other observation, that a reboot of ISP's router fixes the issue.

So please set the keepalives at both /interface gre to something like 5s,3, so that each end would be frequently sending GRE packets regardless whether the tunnel is up or not (when the tunnel is down, payload packets are not sent through it, so no GRE packets are sent), enable IPsec for the tunnel, and see what /ip ipsec installed-sa print interval=1s where dst-address~"ip.of.remote.peer" or src-address~"ip.of.remote.peer" shows. Even without any payload traffic, you should see the packet and byte counters on both installed-sa to grow at both ends at least every 5 seconds (depending on the keepalive interval you've set on the /interface gre).

Now wait until the R disappears from the tunnel, and see whether the packet and byte counters keep growing at installed-sa at both ends. If they only grow at tx ends but not at rx ends, check whether the rx installed-sa at one end shows the same ephemeral keys like its corresponding tx installed-sa on the other end. If the keys don't match, there is an issue with SA rekeying; if the keys do match, there is an issue with ESP delivery through the internet.

To confirm the ESP delivery problem, use /tool sniffer quick interface=your-wan-interface-name ip-protocol=ipsec-esp. If the problem exists, you should see no incoming ESP packets at least at one end, while the outgoing ones should still be there.

The restart of ISP's router may fix either of the two issues - if the issue is with ESP forwarding on that router itself, it is likely that it works for some time after reboot; if the issue is with rekeying, the restart of the ISP's router causes the IKE session to restart, which makes the SAs be established from scratch rather than rekeyed.

Yet another possibility could be that something on the LAN side of one of the routers is sending ESP packets to the IP address of the remote one, which may confuse the firewall. The ESP protocol uses no ports, so only one ESP "session" can exist between any pair of IP addresses.
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: Google [Bot] and 66 guests