I was recently tasked with assisting a customer in deploying a VPN solution for one of their solution providers. The unique challenge in this scenario was the provider’s insistence on directing all requests through a NATed IP, individually assigned to each customer through their solution.
Despite the scarcity of readily available information on this specific configuration, I have documented my journey and experience to provide a resource for those navigating similar challenges.
To tackle this challenge methodically, I established a foundational LAB environment in GNS3, featuring two distinct sites equipped with Fortigate firewalls. At the service provider site, I configured a WordPress Server (Container) alongside a set of clients to validate the reachability and accessibility of the server. Meanwhile, the company site mirrored this setup with two dedicated clients serving the same purpose.
My approach involves addressing issues incrementally; thus, I began by ensuring the Site-to-Site VPN functionality was operational, I confirmed seamless connectivity and accessibility across both sites.
Once I got this working, I then moved into creating the NAT. For this, I created an IP Pool using an overload to the NAT IP as the external IP Address range.
I then modified the policy going to the Service Provider to use nat over this IP Pool.
A sniffer will confirm that the traffic is being sent from the NAT IP, however, just to be sure, I checked the access log on the Apache server.