I just bought 2 new Mikrotik routers RB1100AHx4 and did a configuration of local networks as usual and configured IPSEC btw them. IPSEC works fine btw clients in both local networks but then I had to configure an OpenVPN server on Mikrotik 1 and I have to make communicate OpenVPNClient1 to the clients on another site connected via IPSEC. This does not work for me.
Can you please be so kind and take a look on my configuration and point me to some solution?
I am attaching network schema and also configuration from Mikrotik router 1 and also configuration od Mikrotik router 2.
The OpenVPN implementation on Mikrotik is unable to push routes to clients (at least in ROS 6.x), have you added a route to 192.168.2.0/24 to OpenVPN’s configuration file on the client?
Your firewall rules are unusual, and connections that need IPsec handling will stop working after 10000 bytes are transported, which is just a few packets in case of TCP.
To prevent these connections from ever getting fasttracked, add action=accept ipsec-policy=in,ipsec connection-state=established,related and action=accept ipsec-policy=out,ipsec connection-state=established,related rules before the action=fasttrack-connection one in chain=forward of /ip ipsec filter, at both machines.
adding a route 192.168.2.0 255.255.255.0 to clients openvpn config file did a trick. Thanks a lot for your help.
I also added additional accept rules based on your information to both of the routers. Looks like they works fine now. Could you please be so kind and check new config file of router 1 if the order of IPSEc rules is correct?
Thanks again for your support. I’ll buy a good beer for you when you visit Slovakia router1_configuration.rsc (7.43 KB)
From the point of view of IPsec protection against fasttracking, yes.
From the point of view of CPU load and, more important, security, I’d rearrange the forward chain a bit, the last rule there (“accept established,related”) is useless where it is as it is effectively followed by the default “accept the rest” one. So I’d place it instead of the “accept connection-bytes>10000 in-interface=!ether1” one, which itself is also useless for the same reason - if this one doesn’t accept the packets coming in via ether1, the default one will. By moving the “accept established, related” right after the “fasttrack-connection” one, you’ll speed up the processing of non-fasttracked & non-IPsec-handled packets as they will not have to pass through all the “drop if …” rules. But it’s cosmetics, the real impact will not be measurable as the bulk of packets will either get fasttracked or be handled already by the “accept if matching an IPsec policy” rules.
Security-wise, if the actual intention is to prevent connections coming in via WAN from establishing, which I’d highly recommend, you need to place an explicit action=drop in-interface=ether1 as the last rule in chain=forward of /ip firewall filter.
Takmer nechodím inam ako do Blavy, a teraz to hádam ešte pár mesiacov nevyzerá ani na ňu
