By Sam Mitchell, Senior Solution Architect
I remember the days when telcos used public IP addresses for all communications. They gave them out like it was going out of fashion.
Welcome to the telco, can I give you some public IPs?
In a previous role, I was working with a “large telco” who actually used a public IP addresses on every internal interface or port. Believe it or not, they actually used public IP’s on every personal computer for their thousands of employees! At the time several employees’ PCs did not even connect outside the internal telco network, which was entirely made up of public IPs.
If memory serves me, the telco owned a full class A subnet of public IPs. Back then the telco could distribute these valuable IPs quickly and easily. The company used fool-proof Excel to manage them. Just think about that for a second: using Excel to manage a full class A address space of 16 million IPs. They must of lost thousands of IP addresses every week.
One day I asked to assign some IPs to my department to use on some new servers which my team had built. Later that day, I was sent a full /24 subnet of public IP addresses. I used to joke with my engineers that this year’s Christmas present would be their very own public IP.
Flash forward: public IP addresses don’t always mix with public cloud
Today, it’s a common occurrence for Cohesive Networks customers to ask us (usually distraught) if we can help them “act like a telco”.
I have worked with multiple customers who had multiple customers that need to make a connection from their AWS deployment to a telco. But the difficulty comes when the connecting telco company requires that our customer use public IPs for the encryption domain instead of the standard private IP subnets.
Telcos demand that we use public IPs for the remote encryption domains to ensure there is not any address overlap between internal and other remote connections. There is some logic behind this madness, but it is wildly inconvenient.
Welcome to the public cloud, can I connect your public IPs?
To date, I don’t know of any major public cloud vendors who can “act like a telco” and offer up a public IP as the encrypted domain. However this is something we do all the time here at Cohesive Networks, and is fairly straightforward to set up in VNS3.
VNS3 to the rescue
To recap: a third party (not always a telco) is requiring a unique public IP for the “Gateway IP,” as well as another public IP for the “encryption domain.”
Depending on the complexity of the use-case, our VNS3:vpn (Formerly VNS3 Free Edition) might do everything you need. With larger networks and more endpoints, other VNS3 editions might be a better fit. You can always start with VNS3:vpn for free and see how it works.
As an example, let’s pretend the network behind your partner’s device is: 10.10.0.0/16 and their IPsec device is 188.8.131.52
Let’s pretend your VNS3 Overlay Network is in the Amazon (AWS) public cloud and is: 172.16.0.0/22. Your VNS3 instance gets an EIP of 184.108.40.206.
You want to make the basic IPsec endpoint connection between 220.127.116.11 and 18.104.22.168. But, the problem here is you cannot connect the 3rd party to your host on the 172.16.0.0/22 VNS3 Overlay Network of 172.16.0.17 (let’s pretend).
To connect the two networks with your own private subnet:
- In another VPC – preferably a separate AWS account – allocate an EIP but DO NOT associate it to anything. Leave it there, and alone “forever”. Let’s pretend you received 22.214.171.124.
- Use that public IP in VNS3 to define the endpoint to your partner’s IPsec device.
- Instead of trying to create tunnel/cryptomap/policy from 172.16.0.17/32 – 10.10.0.0/16, you will do : 126.96.36.199/32 – 10.10.0.0/16
- In a simple operation in the VNS3 Firewall you can “netmap” the inbound traffic for 188.8.131.52 to 172.16.0.17/32 and back again on the way out.
PREROUTING_CUST -i eth0 -s 10.10.0.0/16 -d 184.108.40.206/32 -j NETMAP --to 172.16.0.17/32 POSTROUTING_CUST -o eth0 -s 172.16.0.17/32 -d 10.10.0.0/16 -j NETMAP --to 220.127.116.11/32
NOTE: in the event you are using the unencrypted underlay VLAN for your cloud network as an alternative to the unencrypted Overlay Network, simple include this additional rule in the VNS3 firewall:
FORWARD_CUST -j ACCEPT
Private subnet problem solved!
By: Margaret Valtierra