Running an energy company involves links to many different organisations, from comparison websites to meter read services. Facilitating network connectivity requires a reliable and secure connection method, IPSec VPN is often the solution chosen within OVO. However, incorporating a third parties IPv4 addressing scheme can sometimes be a challenge, especially when ranges overlap. We’ve experienced most scenarios that you might be faced with when setting up IPSec VPN's so we’ve put together this blog post explaining how, and why, we use NAT to our benefit.
Destination NAT (DNAT) the ingress traffic. This may seem like an over complication but there are good reasons for this. Providing a third party with a Virtual IP rather than the real IP provides us much more flexibility. For instance if the OVO system requires an IP address change using DNAT results in this being transparent to the remote network, on the firewall we simply change the real IP the DNAT is mapped to. Speed of change is a constant challenge within OVO, utilising NAT’d endpoints provides the opportunity to open up access to additional systems without the need to change the IPSec encryption domain by extending the use of the existing DNAT by adding a new TCP port to real IP mapping.
Source NAT (SNAT) the ingress traffic as it leaves the local Firewall. This is more about keeping routing tables nice and tidy as we use MPLS to connect our offices (that’s a discussion for another day). We don’t manage the MPLS network so changes to routing tables as a result of needing to accommodate a third party addressing scheme involves time and cost. To avoid this part of the subnet allocated each office is reserved specifically for NATing. This results in the third party traffic falling within the pre-configured MPLS routing scheme.
Our SecOps team has a great phrase ‘Zero Trust Model’. Simply put, make the firewall rules as specific as possible and if the firewall supports IPS, AV, DNS inspection, Botnet detection etc then use them. It’s much easier to start with a heavily restricted rule set then relax it if necessary. We begin with the mindset that if there was a malicious host on the remote network what could it ‘see’.
We always like to talk directly with the person who will be undertaking the configuration work on the remote firewall as sometimes they, or us, have not been given all the information needed to setup the connectivity. A phone call or email discussion frequently clears up any questions around the configuration.
Exchange the pre-shared keys via a mutually acceptable solution which isn’t email, easy enough to do and means there isn’t an email floating around with all the required information to decrypt the packets.
Here’s a diagram of a typical OVO VPN configuration.
