I believe that is supposed to be the behavior of IPSec by itself. Unless there is a reason to the “initiator” won’t initiate the connection. This is a problem for the “responder” side since unless it already has a connection you have a problem.
Personally what I would do is run EoIP/IPIP/GRE or some sort of tunnel instead. Then use IPSec to encrypt it. The tunnels can be setup to be always on… and will come back up themselves if the link fails… This causes IPSec to stay alive. It also gives you Layer 2 stuff and routing if you want it…
I find that it is much cleaner solution than just IPSec by itself.
And I’m not sure if that could be a problem… but its not ideal… since the bridge is technically the interface it should DEFINITELY be the one with the IP.
Thanks, efaden. I will try some type of tunnel in combination with IPSEC next, something that gives me an interface to work with. I found this to be interesting: http://mum.mikrotik.com/presentations/HR13/kirnak.pdf
I have a similar problem with a MikroTik router in one site and a Netgear firewall in the other site. The tunnel is established, but I can only ping in one direction.
No traffic arrives at the MikroTik router until I issue a ping command from the MikroTik router to the Netgear firewall. I had no such problem with a netgear firewall at both ends.
Thanks for your reply. I further investigated the problem and found that the protocol ipsec-esp timed out in the firewall, then I realized that there is no firewall rule for ipsec.
add chain=input comment=“accept IPsec ESP” in-interface=ether1-gateway protocol=ipsec-esp