What is the problem with OSPF over GRE?

So, we have three virtual FreeBSD, two of them United GRE tunnel with the network 10.0.0.0/30 via external interfaces (for the diagram, sorry):
lan1 -- (gre0 10.0.0.1 | em0 1.1.1.2) gateway -- server1 -- server2 (2.2.2.2 em0 | 10.0.0.2 gre0) -- lan2

On the "servers" gateway_enable=YES frr_enable=YES and running zebra with ospfd.
If all three machines to do routers and cheer on real interfaces OSPF routing works perfectly, hello run every 10 seconds, the neighbors are seen, connectivity what it should and can ping everything from everywhere.
If the gateway is to remove the speaker, connect the server GRE tunnel, configure a transport mode IPsec on the outside interfaces and to allow OSPF through the tunnel ('s, this scheme want in production), then the magic begins:
  • hello start to go straight in one direction, the response come in about dead interval seconds (although the second router similarly sends them straight into the tunnel, just not receiving from the first hello until dead interval);
  • the table of routes, respectively, are updated on time and the routers disappear from each of the neighbors;
  • pings to the lan behind the tunnel does not go, the route to this network if it came via OSPF, is lost from table, you should run the ping;
  • during the passage of the multicast pings are not going even to the other end of the tunnel.

All this is happening on both sides. Firewalls turned off, with static routes LAN s for the tunnel available to each other. But with OSPF that's such bullshit.
Help find where the bodies are buried - in me or anywhere else.
Thank you.
June 10th 19 at 15:28
1 answer
June 10th 19 at 15:30
Solution
Thank you, comrade from the forum opennet.ru sent on the right path: as it was enabled redistribute connected, it was given and the "external" network, through which the worked tunnel. Thus, he was wrapped in on itself. Removed this network from the announcement - everything went like clockwork.

Find more questions by tags OSPFGREPing