Hello,

I have an ipsec vpn configured between two Mikrotiks. Everything is working normally, having traffic coming and going from both sides with no issues. What I need to do now, is to filter the traffic in order to allow specific IP's and protocols to be allowed inside the tunnel, in contrast to what I have today, that all ip range and protocols are allowed.
Any help on the matter will be great.

Thanks

Hi

Do you use bare ipsec? If so, you would want to filter as usual in the forward chain of filter table, on what is allowed to go out to/come in from ipsec.
Ipsec processing is implemented after firewall filter for outgoing and before it for incoming.

Sorry Sebastian, I don't quite understand what you mean by bare ipsec. Also I try creating drop forward rules, but does not seem to work.

"bare IPsec" means that you do not use IPsec to transport some tunnelling protocol like L2TP or GRE which is terminated on a virtual interface on Mikrotik, but rather use IPsec policy to "steal" IP packets already handled by normal routing rules and redirect them into the tunnel.

As this "bare IPsec" with its policies which redirect already routed packets has a couple of specifics in interworking with the firewall, we need to be sure whether you really use IPsec this way before continuing.

Maybe I misunderstood your problem. What do you mean by "specific IP's and protocols to be allowed inside the tunnel"?
Could you give an example of what you want to block?

Hi. Yes I am using bare ipsec.

I'll try to explain what I need to accomplish. Let's say I have site A with an ip range of 192.168.0.0/24 and Site B 192.168.1.0/24. I would like to create a policy that for example allows only ip's from 192.168.0.10 to 192.168.0.20 range to reach only 192.168.1.50 on site B and only RDP protocol. Maybe I am wrong and this is not possible on ipsec. Please let me know. Thanks you both for your time and help.

IPsec policies which are used for bare IPsec match on IP subnets, not ranges, and on IP payload protocols such as TCP, UDP, GRE... and, where applicable, that protocol's ports.

RDP is an application protocol running atop TCP on port 3389 and under circumstances can use also UDP port 3389, both at server side.

So in your case, you could use an IPsec policy to permit access from the whole subnet 192.168.0.0/27 to the single address 192.168.1.50/32 for protocol TCP and port 3389 at the side of the single address. However, it would mean that

• any other packets from 192.168.0.0/27 to 192.168.1.0/24, including packets to 192.168.1.50 except those to TCP port 3389 there, would be routed up to the standard routing rules, so in extreme case they could leak out to the public network
• also hosts 192.168.0.1 to 192.168.0.9 and 192.168.0.21 to 192.168.0.31 could access RDP at 192.168.1.50

For the first point, it seems from the manual that you could use a second policy (order matters) which would match all packets between 192.168.0.0/27 and 192.168.1.50 so it would catch all those not caught by the first policy and would drop them, but the issue of letting other clients from 192.168.0.0/27 through would still exist.

Therefore, I would personally use an IPsec policy matching on the complete /24 subnets and on all protocols (which also implies that no limitations to particular ports could be set), and I would use normal firewall rules to enforce the restrictions, and I would apply them already at the client side to save some tiny bit of bandwidth.

The following rules would have to be placed in this exact order right before the "chain=forward, action=fasttrack-connection" rule in your IP firewall filter table (use place-before while creating them or move or GUI afterwards to place and order them properly):
As this way you're going to make use of connection-tracking, you must not prevent the packets between 192.168.0.0/24 and 192.168.1.0/24 from being connection-tracked as the manual page of IPsec suggests to do if you want to save some CPU. But you do have to prevent them from being src-nated if src-nat would be normally used on the route where the packets are sent before the IPsec policy "steals" them from there.

At the other end of the tunnel, where you do not use these filter rules, you can exclude packets between 192.168.0.0/24 and 192.168.1.0/24 from connection tracking as the manual suggests.

Same what I had in mind with "usual forward chain filter".