You expect a lot, but it does not work like that!I do not understand. It is obvious that there should be proper firewall set of rules to pass GRE and IPSec connection but what is such firewall rule for? How it deals with password?This is normal when you do not pay special attention to the firewall.
The IPsec config is only a shortcut to IPsec to setup a Peer and Policy for GRE traffic, but as long as the...
So, make sure your firewall entries are correct. Like:
add action=accept chain=input ipsec-policy=in,ipsec protocol=gre
I assume that I am assigning IPs to secured connection so I assume that addresses are assigned not to pure GRE but to IPSec over GRE so if there is no matching password pair then the IPSec should not be established = no traffic from side to side.
I'm expecting sending data over encrypted tunnel not over simple GRE which carries IPSec traffic.
More, if I have no such rule then there should be no chance to make secured connection so traffic should be blocked.
IPsec policies define what traffic is encrypted and all traffic that does not match the policies is simply sent unencrypted.
As the policies are dynamically generated (first a phase1 association with the peer as defined in the tunnel interface setup and
then a phase2 policy generated from there), in case the IPsec is not defined at both ends there simply is no encryption.
Many examples for using firewall entries for tunnel over IPsec for MikroTik are simply incorrect. E.g. for GRE/IPsec they list
that protocol 47 is to be allowed, for L2TP/IPsec they list that UDP port 1702 is to be allowed. That is simply wrong, the
extra qualifier ipsec-policy=in,ipsec as mentioned above should be present for those allow rules or else unencrypted traffic
for that protocol will be allowed as well! When you would not allow plain incoming GRE traffic the connection would not
be established. And when you are very worried about sending unencrypted traffic, probably you should also use output
rules to drop GRE traffic when not ipsec-policy=out,ipsec ...