Hi,

ROS 6.48.6 (long-term)

I have to setup ipsec policy for a external party that uses some uncommon netblock: 9 C class nets, say it is 192.168.4.0 - 192.168.12.255.
There is no problem to include such range in /ip firewall filter or /ip filter nat or /ip filter address-list but when I try to:
I get:
Does it mean that only solution is to split that policy into three policies for separate nets: 192.168.4.0/22, 92.168.8.0/22 and 192.168.12.0/24 ?

Thanks,

If you put that range into /ip/firewall then if possible it gets converter into a range: 192.168.4.0/24 for example. If not then you use there a begin and end.

In /ip/ipsec/policies you can't do that and you have to use a range /24 and so you have to use three ranges if that is possible in policies.

Ok, so you say, that if possible, range (ie. 192.168.4.0-192.168.7.255) gets converted to normal CIDR prefix notation (192.168.4.0/22 in this example). I know that, I already seen that even in cases where for legibility it was not exactly right to do (but it helped performance).

And so as I understand you confirm that dst-address (ans src-address) properties in /ip ipsec policy have to be written only in CIDR prefix format (no way of using ranges)?

Thanks,

Move from 192.168.4.0-192.168.12.255 (near 2300 hosts)

to
192.168.8.0/21
192.168.8.0-192.168.15.255 (near 2000 hosts)

or
192.168.16.0/20 (near 4100 hosts)
192.168.16.0-192.168.31.255

Unfortunately that is not an option. That range is used by peer for their workers and is set in stone. I have to convince them to split policy into three groups, now I'm sure of it.

Thanks,

You can try if instead of an IPsec tunnel they can provide you with a GRE/IPsec or IPIP/IPsec tunnel (a tunnel over IPsec transport), so in your policies you will only have the endpoint addresses of the tunnel (external internet address) and what you route through the tunnel is only determined by the IP routes, which of course can be setup to handle this range using some separate routes.

Yeah! We use GRE over IPsec a lot between our own locations, but again the other party policy is to have only policy based tunnels. And in fact we are glad it is that way. We don't want to have to filter their mess, and based on the ip ranges they choose, they certainly have some of it.

Thanks,