I have an enterprise subscription and want to setup as follows.
User U1 belongs to Group G1
User U2 belongs to Group G2
EC2 Machine has 2 Ips on eth0, IP1 and IP2
After doing the necessary settings for Server and such, when user U1 connects I want the outgoing IP to be IP1, and for user U2 it to be IP2.
What I have been able to do:
Set up 2 Servers, S1 and S2 on single Host H1.
S1 Binds to Address IP1
S2 Binds to Address IP2
UI connects to S1 and when connecting to external server ES1 shows it’s IP as IP1 U2 connects to S2 and when connecting to external server ES2 shows it’s IP as IP1
The last bolded line above is the error. I want it to show it’s IP as IP2 (as gotten from Bind_addr of Server it is connecting to)
Let me know if I have understood anything incorrect and how to do this?
The route is not working. Another similar route where I put down the NAT Interface as eth0 works. I have added new interface after installing and setting up pritunl. I have reset service/reboot server/added new users/re-downloaded profiles etc to rule out those things.
Any help would be appreciated. Let me know if what I am trying to do is not possible, so that I can try to find any alternate products or solutions.
Hi @zach Are you from Pritunl? Is this an official answer that this is an unsupported right now? If so, can I know the purpose of that particular field, or in what scenarios it would work?
I have an enterprise license and currently doing an POC to understand the features and limitations. It is crucial to know the limitations and maturity of the product.
Yes that would be the official answer. I would need to replicate the configuration to verify what is occurring but the recommended configuration has always been to create separate hosts when multiple default gateways are desired.
It is not recommended to forward all internet traffic on AWS. This will result in significant bandwidth charges and many websites will block AWS IP ranges assuming the client is a web crawler.
Open the server settings and change the replication count to equal the number of hosts attached to the server. Leave NAT enabled on the routes unless a non-NAT configuration is required.
I’ve been closely following this thread as I have a strikingly similar requirement for my setup. I’m looking to create a deviation between user groups and their respective access rights on our AWS infrastructure. The primary objective is to employ AWS security groups as a mechanism to manage access.
For instance, I’d want to restrict access for members of Group G1 to certain resources, while members of Group G2 should have broader or different access permissions. This could apply to EC2 instances, ALBs, and other AWS resources.
@arun were you able to make any progress with the suggestions provided by @zach? I’m keen on understanding any hurdles or workarounds you might’ve encountered.
@zach is there a direct method within Pritunl or AWS to implement such a differentiated access system based on user groupings? Any guidance would be incredibly valuable.
The most secure and effective way to handle that is to create multiple instances and control users access to each server based on requirements. Than firewalls can be configured to control what traffic comes from each server.
A non-NAT routing configuration can also be used to route the VPN subnets to the VPC allowing the firewall to control each VPN subnet. AWS Route Advertisement can be used to handle automatic failover for this configuration.
Multiple Instances Solution: While creating multiple instances and controlling user access to each server based on requirements seems like a logical approach, there are associated cost implications. Setting up additional infrastructure on AWS not only incurs extra charges for the infrastructure itself but also necessitates another enterprise subscription. This approach isn’t the most cost-effective for our current budget and scale.
Non-NAT Routing Configuration: The idea of using a non-NAT routing configuration is intriguing. However, there’s a complexity in our setup that might make this challenging. Our infrastructure spans across multiple AWS accounts, leading to multiple VPCs. To the best of my understanding, VPC peering connections typically deny routing subnets other than the primary VPC subnets over the peering connection. Therefore, this could potentially restrict the flexibility and reach of our setup, given that Pritunl might be running in one specific VPC.
Given these challenges, do you have any other recommendations or tweaks to the suggested solutions while remaining cost-efficient?
The AWS VPC peering will only route the VPC subnets a non-NAT configuration won’t work with VPC peering. There’s no other option in Pritunl to have more detailed control over what resources are accessible.
