0

What is the best way to deal with this problem.

I have a VPN set up on my firewall that runs from a server on my side to a Customer Site.

It is configured as serverA on my side and 172.31.255.1 /24 on the customers side.

I now have a new customer who also needs a VPN set up. But their IP address clashes with the above range.

So they need to run from serverB on my side to 172.31.255.18 /32 on the customers side.

As you can see, the new one is right in the middle of the range used by the other one.

What is the best / recommended way of working around this problem?

marked as duplicate by EEAA Jan 4 '16 at 16:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1

Ok, the solution in this case is probably NAT. Otherwise I suppose you could re-address everything but that's unlikely to be feasible in a production environment.

I'll assume serverA and serverB are in the same subnet on your side of the VPN, and that the sole purpose of the VPN serverB <-> 172.31.255.18 is going to be for this database access. Then, on the client's firewall I would add a NAT rule that translates 172.31.255.18 to something that does not conflict with anything else you want to route at either end. Then change your VPN "interesting traffic" config at both ends to reference the translated address instead of the original one.

If you are using the same firewall at the client end for local internet access/NAT for 172.31.255.18 you might need to be careful that the NAT rule you add does not interfere with the internet NAT (on Cisco ASA I would suggest use "Policy NAT").

At the server end, you need to make sure your database serverB has an IP route for the translated IP address from the client end. If you are just using a default route sending everything to the firewall, you should be fine.

  • sorry, the two servers (A and B) are database servers. The VPNs are Site to Site VPNs configured on the firewall. /24 means it is configured as 172.31.255.1 - 172.31.255.255 (due to a problem on the customers side we had to do it that way instead of a single IP Address). /32 means 172.31.255.18 only. – IGGt Dec 21 '15 at 11:59
  • cheers, technically I need to get from my side serverB to the customers server, rather than the other way round. Would the same principle likely work, if I set the NAT on my side, as I have limited access to the client side, and don't want them to make any more changes than absolutely necessary. – IGGt Dec 21 '15 at 13:51
  • A NAT rule on your side is unlikely to work because it will do its translation before the traffic is evaluated for sending over the VPN tunnel. So you will end up with the traffic for "customer 2" being sent over customer 1's tunnel. – Mintra Dec 21 '15 at 13:56
  • bugger. Ok cheers, so if I get them to change it to (e.g.) 172.31.250.18 via NAT, and then on my side I would set everything up using 172.31.250.18, it should all end up at the right place. – IGGt Dec 21 '15 at 14:04
  • As long as that 172.31.250.18 doesn't conflict with anything else you have anywhere! And don't forget on the customer side that as well as the NAT translation the VPN config needs to match the new translated address not the "real" pre-translation one. – Mintra Dec 21 '15 at 14:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.