I am trying to setup a VPN client in AWS using Keycloak and Google OAUTH as my IDP. I can log into the VPN just fine and a connection is established but once I disconnect from the AWS VPN Client I am unable to log back in. The connection is stuck on "re-establishing" and it never seems to move from there. It almost seems like the connection to the AWS tunnel is not released as I am unable to access any AWS consoles. The only fix I have been able to find is to disconnect from my WIFI and re-connect. Has anybody encountered this before? As a side point we have separate VPN endpoint that uses user/password authentication and I can log on and off to my hearts content. There are no noticeable difference between the two VPN endpoint configurations
Related
I'm writing an application where multiple users connect to a websocket server with the following url as an example wss://example.com/ws/1234.
Multiple users may connect to the same one and I require them to all connect to the same ec2 instance. All that try to connect to wss://example.com/ws/1234 will go to the same server, and all users that connect to wss://example.com/ws/4325 will also go to the same server. These routes are generated dynamically.
If a client is the first client to connect to an endpoint, it will route them to the server with the least CPU load. If a client is connecting to an endpoint that has already been connected to, they will be sent to the same server.
I've tried going into the listener rules for my ec2 auto-scaling group. But, I couldn't find any settings that seemed like they would do the trick.
My attempt:
I created an AWS client VPN endpoint with a VPC using google federated authentication and server certificate generated using open easy-rsa. I tried to connect the VPN, but I keep getting Error: app_not_configured_for_user on the browser. I have searched online but I haven't found a possible solution. Does anyhow know how I can fix this?
Thank you
Backstory(but possibly can be skipped): The other day, I finished connecting to MySQL full SSL from a Cloud Run service without really doing any SSL cert stuff which was great!!! Just click 'only allow SSL' in GCP and click 'generate server certs', allow my Cloud Run service to have access to database instance, swap out tcp socket factory with google's factory and set some props and it worked which was great!
PROBLEM:
NOW, I am trying to figure out the secure Google Cloud Run service to Cloud Run service security and reading
https://cloud.google.com/run/docs/authenticating/service-to-service
which has us requesting a token over HTTP??? Why is this not over HTTPS? Is communication from my Docker container to the token service actually encrypted?
Can I communicate HTTP to HTTP between two Cloud Run services and it will be encrypted?
thanks,
Dean
From https://cloud.google.com/compute/docs/storing-retrieving-metadata#is_metadata_information_secure:
When you make a request to get information from the metadata server, your request and the subsequent metadata response never leave the physical host that is running the virtual machine instance.
The traffic from your container to the metadata server at http://metadata/ stays entirely within your project and thus SSL is not required, there is no opportunity for it to be intercepted.
We have a very difficult problem here, we have a Windows Server 2019 Base x64 on Amazon EC2, connected through RDP and setup-ed forest and activated AD DS , also activated DNS. But whenever we try to connect we are not allowed to.
We have opened all the relevant ports on inbound traffic rules.
We have added users.
We have tried searching internet and various tutorials.
In Server Manager=:
Added the public ipv4 address to our ipv4 settings of the adapter.
Went to the computer setting in computer domain entered the domain but no fun.
Disabled the firewall in server manager.
We want to connect our clients on different network to connect to the server hosted else-where on AWS.
We are really new into this can some one guide through this?
Please make sure there is network connectivity between your client and you DC which is set up on EC-2 Instance.
[1] In case your clients are on AWS (meaning different EC-2 Instances), and in a different network, you need to create VPC peering or use Transit Gateway, so that it has proper network connectivity.
[2] In case your clients are not on AWS, and in an On-prem Environment, you need to have a VPN connection between your client and your DC.
So in Summary, you need to have network connectivity between your client and DC so that clients can join your Domain.
What do you mean whenever we try to connect we are not allowed to?
What are you trying to connect to, the Windows EC2 instance?
Are you saying that the instance is joined to AWS Directory Service domain but you can't connect to the instance using one of the users in your AWS directory?
Edit: This should have been a comment but couldn't post comments at the time of answering.
Hi there networking experts,
I have a Rails app hosted on Heroku, and I am looking to set up a VPN tunnel on a separate EC2 instance which will connect with a 3rd party.
3rd party <----(VPN tunnel)----> EC2 <----(HTTP/SSH)---> Heroku
Best case scenario would have been to set up the tunnel directly on our Heroku instance, but that doesn't seem possible according to some of these answers.
With my limited knowledge, I figured that the next best thing would be to set up a 'middle-man' EC2 instance with the capability to listen to the VPN tunnel as well as send HTTP requests to our Heroku server over SSH. The most important consideration in this integration would be security. I would like to encrypt end-to-end, and only decrypt on our Heroku server.
What would be the best practice for achieving something like this, if possible at all?
Thank you!
AWS has a managed VPN offering.
You configure a customer gateway for the client side, attach a virtual private gateway to your VPC, and the VPN connects the two. You can then set up routes which will allow them to connect securely to any services running inside your VPC.
A VPN in AWS can use static or dynamic routing. Static is generally simpler, especially if there is a limited IP range on the client side.