Good day.
SIP provider suggested using IPsec tunnel to reduce calls cost. They have Cisco.
Provided data for the creation of the tunnel, its external IP 2.2.2.2, its internal 10.250.245.167 and its backup internal 10.104.186.167.
And he communicated what our internal 10.93.240.61 should be. Our external 1.1.1.1
when configuring an own address of the Mikrotik, a convention “host address/mask” is used, but when specifying a subnet (which is what you do everywhere else in the configuration), the bits of the address corresponding to those bits of the mask which are 0 must be also 0. So either specify dst-address=10.250.245.167/32 as you did (for a single address) and add yet another policy with dst-address=10.250.245.3/32, or use dst-address=10.250.245.0/24, but the choice may not be yours - it depends how the gents at the SIP provider have configured their end (adaptive in some range or strict). It may even be possible to use just a single policy with dst-address=0.0.0.0/0 (but the src-address must remain the 10.93.240.61/32 or you may lose access to your device when the tunnel is up!).
2.,1. - this is not a matter of the tunnel settings any more. The SIP provider wants to see all your voice network as a single IP address 10.93.240.61; as they’ve specified a single address rather than a subnet, we can suppose that they will handle it using the same approach as if it was NATed behind a public IP. So you have to add a src-nat rule in your firewall before (above) the usual “src-nat everything that goes out via WAN” one:
As you are connecting a PBX rather than a bunch of individual phones, make sure that the SIP helper in Mikrotik’s firewall is disabled before registering the PBX to the provider for the first time: ip firewall service-port set sip disabled=yes
If the PBX was attempting to register before you’ve set up the NAT rules and disabled the SIP helper, the tracked connections have “remembered” wrong values, so you may need to issue the following commands to clean them up:
If your PBX does not register to the operator, you may need a port-forwarding rule for the incoming calls: /ip firewall nat add chain=dstnat dst-address=10.93.240.61 protocol=udp dst-port=5060 action=dst-nat to-addresses=192.168.0.101
(or maybe they are using TCP, or different port - too much information missing).
Thanks for the quick response.
3. I cannot specify a mask other than 32 in dst-address.
I created a policy with dst-address = 10.250.245.3 / 32, but the tunnel does not work.
[root@SiciliaNew] /ip ipsec policy> print where tunnel=yes
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
# PEER TUNNEL SRC-ADDRESS DST-ADDRESS PROTOCOL ACTION LEVEL PH2-COUNT
0 A MF_peers yes 10.93.240.61/32 10.250.245.167/32 all encrypt unique 1
1 MF_peers yes 10.93.240.61/32 10.250.245.3/32 all encrypt unique 0
2 A MF_peers yes 10.93.240.61/32 10.104.186.167/32 all encrypt unique 1
1-2. I indicated that you advised, I will try.
Unfortunately, I also do not own additional information.
If it doesn’t help, what else would you recommend finding out from provider?
Well, that’s a bit surprising, the provider must have told you whether the PBX should register or not and how to work with the primary and secondary IP at their end. If you are migrating your existing connection which was working without the VPN, I would expect it does register and there is nothing to change. Is it the case, or have you concluded a new contract and you had the option to choose between a VPN connection and a direct connection and you choose the VPN variant?
In any case - if the PBX has to register, the setup I gave should be sufficient even without the dst-nat rule. If not, some surprises may come.
As for the pingable IP, I’d forget about it for the time being.
I do not configure PBXs, I only need to configure a router. Therefore, I do not know if registration is required.
Currently we use a direct connection, with or without registration, I do not know. And we want to transfer to VPN to reduce the cost of calls.
Now the person responsible for the PBX is engaged in further configuration, and if the dst-nat rules are not useful, we will remove them.