Photo by AbsolutVision on Unsplash Final notesįirst, big thanks to Kirill Merkushev whose blog got me starting with the idea of automating my VPN Endpoint in AWS. Remember, just because in your code it comes first, doesn’t mean that Cloudformation process it in the same order. So with the addDependency() call, we inform Cloudformation that it should first create the CfnClientVpnTargetNetworkAssociation before doing the Routes. Cloudformation somehow doesn’t respect the rule that you cant create a Route without having created a NetworkAssociation before. You also see a weird “node.addDependency(dependables)” call at the end. If you have splitTunnel to true, there is no need to push those routes but then you need to change also the dnsServers value. Because routes need to be applied for each subnet, we iterate over those again and apply the 0.0.0.0/0 route. The last thing we need to do is to create Routes that allow us to reach more than just our subnet IP range. There is also the possibility to add SecurityGroups to the VPN to create more fine grained permissions but for now we leave it quite open. Then we create a VpnAuthorizationRule which is quite non-permissive as you an easily see. You will notice that we “save” those associations in a ConcreteDependable object. For that we just iterate through our private subnets and apply the association. Setup targetNetworkAssociations, AuthRules and Routesįirst we create two NetworkAssociations for our private Subnets of the VPN. If you are working for a pretty big corporation, make it large enough so that enough of the employees can connect simultaneously. Lastly the clientCidrBlock defines the IP range clients will get when connecting. You could for instance use internal DNS servers of your private subnet, but i wont go into that. Because of that, i am also able to define public DNS Server in the dnsServers attribute, because my client will sill be able to resolve those Google DNS server while inside the VPN. In my case i wanted to have all the traffic go through the VPN, so i turned it off. SpitTunnel means that if true, traffic to all other IP destinations other than the pushed route (normally all the internet traffic from your client) will *not* be handled by the VPN interface. The last three attributes i will discuss here are splitTunnel, dnsServers and clientCidrBlock. Remember that you pay for all those logs in CloudWatch, so its always a good idea to have an expiration time. I created a logGroup and a stream right at the start of the stack code and applied a retention of one month to it. BTW, its not possible to add the tag via Tag.add(endpoint, ‘Name’, ‘My super VPN’) Īnother section is about logging exposed by the attribute connectionLogOptions. When you think why is there no “name” attribute as top level property… you are right. To have a proper name in the AWS GUI for the VPN, we need to tag the resource and that’s what we do in tagSpecifications. If you created multiple client certs, you can just reference one out of those to define the clientRootCertificateChainArn. If you have done all the outlined steps, you just need go to the Certificate Manager in the AWS web console and obtain the ARN. The documentation only creates one cert in Step 5. Remember it’s better to create a client certificate for every client who wants to connect to the VPN. The creation of the certificates is best documented here. We use a hard coded ARN to obtain our server and client certificate from the AWS Certificate Manager, which we manually put there before. For that to work we also need to supply a serverCertificate and a clientRootCertificateChainArn. We start by creating the CfnClientVpnEndpoint and decide to use certificateAuthentication which is based on asymmetric keys. As can be easily seen, we use Cfn* Resources all over the place because there is no higher level abstraction in CDK yet.
0 Comments
Leave a Reply. |