I want to restrict a few business applications hosted on cloud, to only our employees using Wireguard VPN (client server setup, with split tunnel for their private browsing).
For the applications running on standalone server with static IP, we can achieve this easily, by adding their IPs in wireguard "Allowed IPs" and creating a firewall rule in the application server to only accept connections from our VPN server (also hosted on cloud). Please note that Wireguard routes this in layer 4.
But for applications using a application load balancer or serverless setup, which do not have a static IP, we use a proxy server like Cloudflare which has a IP range, which we then add in Wireguards allowed IPs. This is a layer 7, solution.
Is there a better way (preferably on layer 4), to restrict access to applications without static IPs using Wireguard VPN.
Also, we have a private DNS in the VPN server, which may be used in designing the solution.
Thanks
Vivek
Related
I'm trying to restrict access to my RDS SQL Server instance to my office IP and all resources in my VPC.
This is what I've tried:
MSSQL TCP 1433 xxx.xxx.xxx.xxx/32 Our Office IP
MSSQL TCP 1433 yyy.yy.y.y/16 Our AWS VPC (IPv4 CIDR)
This seems to be working but I have some doubts:
I'm not confident this is the correct approach
Can the VPC IPv4 CIDR change on it's own
I'm not confident this is the correct approach
This is one way of doing this. Its not perfect, but better then exposing your RDS to the entire internet. The better way would be to keep your RDS fully private (no public IP), and access is through VPN from your office, ssh tunnel if you need it for only testing and development.
Can the VPC IPv4 CIDR change on it's own
No it can't.
We've been experimenting with hosting our ASP.NET + SQL Server application in Azure. We've tried two ways so far:
App Service for ASP.NET, VM for SQL Server, both in the same data-centre, so I imagine a LAN connection is possible, but currently the connection string lists the public IP
A single VM for both IIS ASP.NET and SQL Server (an interim solution - we will eventually move SQL behind a firewall)
We'd prefer the first option because of costs and manageability. But it seems slower (I guess because of the public IP in the connection string).
Question
Can the App Service - SQL connection be LAN rather than WAN/internet? Are there any specific tricks during setup to achieve this?
What I've tried
The SQL VM is in a VNet. I've tried adding the App Service into the VNet (based on the guess that it'll then be able to see the SQL VM's internal IP), but the existing VNet is not selectable in the App Service's VNet configuration options.
Can the App Service - SQL connection be LAN rather than WAN/internet?
According to your description, maybe we can use VPN to integrate your app with an Azure Virtual Network.
When we want to select one Vnet for Azure app service, we should setup a point-to-site VPN with a Dynamic routing gateway.
Getting started
Here are some things to keep in mind before connecting your web app to
a virtual network:
•VNet Integration only works with apps in a
Standard, Premium, or Isolated pricing plan. If you enable the
feature, and then scale your App Service Plan to an unsupported
pricing plan your apps lose their connections to the VNets they are
using.
•If your target virtual network already exists, it must have
point-to-site VPN enabled with a Dynamic routing gateway before it can
be connected to an app. If your gateway is configured with Static
routing, you cannot enable point-to-site Virtual Private Network
(VPN).
•The VNet must be in the same subscription as your App Service
Plan(ASP).
•The apps that integrate with a VNet use the DNS that is
specified for that VNet.
•By default your integrating apps only route
traffic into your VNet based on the routes that are defined in your
VNet.
More information about integrate App with an Azure virtual network, please refer to this link.
I am new in AWS VPC. I have question about how to connect mySQLworkbench to RDS in AWS private subnet.
I use VPC wizard to create scenario 2 : VPC with public and private subnets. From a lot of blogs and forums, most of the people recommend the database should be in private subnet, so I created the database in private subnet. I also created NAT gateway (not the instance). Is that anyway I could use mySQLworkbench from public (any) network to connect to the database in private subnet?
Thanks,
Angela
I also followed the Scenario 2 in the AWS Documentation without the NAT parts. But now I can't access the RDS instance from my computer because RDS is in a private subnet.
To solve the accessibility problem I got the idea from this tutorial. I actually did not follow it, so I cannot recommend it.
What I actually did was:
1) I created an EC2 instance and gave it an ellastic IP.
2) Then I allowed the DB to receive traffic from this instance (this was already defined on the AWS tutorial, on the DB server Security Group).
3) Then I allowed an SSH connection from my computer to the EC2 instance.
4) Finnaly I was able to connect to the DB using MySQL WorkBench by establishing a connection "Standard TCP/IP over SSH"
The good thing is that this solution can be achieved using only Free Tier resources (at the time of writing) AFAIK.
Use VPN solution such as OpenVPN.
Configure Openvpn server in public subnet.
Push route of private subnet in server configuration
Adjust the private route table to pass the vpn traffic through vpn server
Connect to vpn using client configuration from your PC.
Use Mysql workbench to connect to your DB instance
Other way as suggested previously, you can configure ssh bastion host and then use it as jump server to ssh into db instance. Accordingly configure mysqlworkbench connection to reach db
Silverlight application is sitting on a server which is accessible from internet and WebApi is sitting on a server behind firewall which is not accessible via internet but can be accessible via intranet. Both Silverlight Application Server and WebApi Server can talk in intranet. Is it possible for Silverlight application which is accessed from internet to talk to WebApi?
You simply need to add a firewall rule that allows Green Server to access Red Server at a given port. You can add MAC filters, IP filters, use an ad-hoc IP in a different subnet in the Red Server, expose the API in an unusual port (not 80), use client certificates, expose the API through SSL, and many other things to protect the server inside the firewall and the communication between servers.
That's the mission of the firewall. If not, you'd simply didn't connect the networks through the firewall.
We are building a client solution that will be hosted on servers in a data-centre. It consists of several servers all related to providing the client solution. There is no internal network to protect but for some reason our UAT environment has the notion of a DMZ in the server diagram.
We have an IIS box which will have a public IP. Then we have two servers DB(Sql Server) and APP that are only on the internal lan with no public IPs. You can only RDP to these servers via VPN. Our IIS server needs sql access so port 1433 is open from IIS box(DMZ) to the sql server. We are also opening several ports from the IIS server to the APP server which hosts WCF services.
My understanding was that a DMZ was meant to protect internal private networks and that these networks should not be accessible from the DMZ but we are now opening up ports to both our APP and DB servers so they are accessible from the DMZ. In the end most of our servers are accessible from the IIS server via certain ports.
We originally wanted to setup our SQL server for AD authentication only but since our IIS server is in the DMZ and has no AD access we will be forced to enable mixed mode authentication in SQL server. This might be another security issue in it's own since we are now forced to store passwords somewhere on the IIS server to be able to auth against sql server.
Are we not perhaps missing the idea of a DMZ?
So with a system where you have a DMZ, there is also a firewall involved.
So your system should look like this I think:
SQL-server hosting internal data
Other servers needed for the company
---- firewall ----
SQL-server hosting data for web solution
AD-server (if needed)
Web-server
FTP-server (could be on the web server also)
With this setup you don't expose company-sensitive database to the outside world and you also don't open up a port in the firewall making it possible for attackers to (maybe) get access to the internal database which has company sensitive data...
Just my suggestion based on the information provided.