I’ve got a problem which I’m hoping the community here can help me to overcome.
In the diagram above, you can see our AWS cloud environment on the left. It contains an SBC which we will be using to receive calls from customers. Some of our customers want to deliver these calls over VPN connections. The problem is that some of these customers are using private subnets which overlap our own, and some have private subnets which overlap with each other. In the diagram, Customer A has a subnet which overlaps ours and Customers B and C overlap each other.
We are hoping to deploy a Mikrotik CHR in our AWS environment to terminate the VPNs but we’re hoping that we can do some clever NAT on our side to get around the overlapping ranges. Ideally, we’d like to avoid the customers having to do any NAT on their side, if at all possible. Many of them already struggle with configuring the VPNs and we don’t want to make it any more complicated for them than it has to be.
I’d really appreciate any advice anyone can give to get around the two situations above.
Many SBCs at core side can solve this alone - you bring each customer’s VoIP subnet inside a dedicated VLAN to the SBC (so not more than 4094 customers per SBC) and you create a listening socket in each VLAN and configure the routing in each VLAN separately. So for each customer you set a tailored address set on your side, either from their range but coordinated with them or just non-conflicting with their range.
If your SBC cannot handle this, another possibility is to NAT the whole network of each customer to a single IP address - you bring each customer’s subnet to a virtual interface on the Mikrotik (VLAN, GRE, …) and build on the solution described in this thread. As the CPEs initiate the connections, the signalling connections will always establish in CPE->exchange direction so they will be connection-marked with their respective source port. On top of using the connection-mark to route the exchange->CPE packets, you will also use it to choose the proper one out of the action=src-nat rules in chain=srcnat of /ip firewall nat. But in this case, you have to use public IPs for your SBC, because only for public IPs you can be sure that they don’t overlap with anything else. Using an individual set of addresses representing the SBC per customer and dst-nat’ing them won’t work because the SDPs sent by the SBC would keep indicating the real addresses. Use of public IPs for the SBC removes the conflict. The customer has to configure their routing to route traffic to the public IPs of the core SBC via the VPN tunnel.
Of course this only works if the SBC auto-learns the RTP destination from received RTP traffic, so all the usual issues associated with CPEs behind a NAT apply.
But I don’t get one thing, your picture shows a customer premises SBC for each customer, so why don’t you dedicate a subnet to these SBCs and let them do the topology hiding job? The customer premises SBCs should be capable of using a separate routing table for the WAN and LAN sides (and thus to handle overlapping subnets), and the phones should see the LAN address of the customer premises SBC as the entry point to the service. Are the customer premise SBCs not under your control?
