I have my own servers and have hosted a few services (game servers, web servers, ...), and use to host these on a publicly accessible dynamic IP using DuckDNS.
I have recently moved to a rural area and use a satellite service for my internet that does not support publicly accessible IP address.
I would really like to host these things again, but the only way I can think of doing that, is to have an IP somewhere in the cloud and route that back into my network. I have been messing around in Azure but I can't seem to get what I want working. I am not stuck on Azure, just happens to be the one I am message about with.
I have pfSense as my router, so I can setup a VPN client on that and pretty much keep that alive indefinitely, so here is what I am thinking and I hope someone can point my in the right direction, or if you like, poke holes in the idea.
I configure a VPN client on pfSense to be an WAN interface
create a VPN gateway in the cloud
connect pfSense VPN client to the VPN gateway
create a static external IP in the cloud
route traffic from the external ip through the VPN back to my pfSense server and into my internal network
once I get the traffic coming into pfSense , I can route to computers / VMs on my internal network.
This way, I do not need a publicly accessible IP from my ISP, I can connect to the Azure and use its external IP and route back through the VPN to my internal network.
If this was real hardware, I would have had this built in 30 minutes, seems this virtual world is messing me up.
Any ideas on how to configure this or maybe another solution?
I am struggling with the whole Azure setup and have watch hours of videos about each of the bit in Azure, but I am lacking some key bits of knowledge to bring this together.
If you know what you are doing with pfSense...
cloudfanatic.net
$2.99 US a month for a VPS running pfSense. They will spin up a VPS with pfSense on it at no extra charge. Open an account, send support an email.
Gives you a static permanent IP. Shared 1GB Internet link. No data limits. I see between 150 and 500Mbps. Perfectly fine for what I use it for.
Wireguard on that pfSense, people connect in, etc...
I've been using it for about 6+ months. Been very impressed.
Chunky
I have configured Azure P2S IKEv2 VPN and downloaded the VPN client (in machine it shows as PPP adapter) into 2 machines, one each in different countries. Say our IP addresses are 170.10.10.121 & 170.10.10.122 . From here on we'll call the site with .121 machine as site A.
My machine(.122) would like to use (.121) as a gateway, so that I could browse the internet in my computer using site A's public IP address. Is this possible or have I got this terribly wrong?
My end goal is that, we have multiple sites(B,C,D) that'd like to use the internal network as well as access public internet using site A. This site has dynamic IP address for public internet and port forwarding is not an option as ISP is non cooperative.
As shown in the below picture, machines PC-B-1,C-1,D-1 are trying to use the PC-A-1 as a gateway to access the internet through Site A.
Thanks.
what you need to do is installing the P2S on all PCs in all sites and setup a FW/NVA in Azure and route the traffic through that one or setup S2S from all sites to Azure and route the traffic to a FW/NVA in Azure. Basically you will need a NVA/FW in Azure to get the same IP for all computers. You cant use a P2S as a gateway.
Prefered solution is to setup S2S VPN with NVA to get the same IP.
So this is the setup I am using as a work around.
Since setting up a S2S is not an option for lack of infrastructure and lack of time,
As given in the question, I installed P2S VPN agents in all the machines that is involved, from the machine whose internet we wanted (in site A) to be used by others, to all the other machines (in B,C,D). Now that all the machines are in Azure Vnet, I installed WinGate application at Site A machine and activated proxy.
Then I configured proxy on the rest of the machines in sites B,C and D to proxy through the machine in Site A using its Azure Vnet ip address.
Machines involved are all Windows 10.
This might not be the best solution, but given the extraordinary list of limitations definitely this was the quickest and easiest.
Let's see if we can get better and quicker solutions for the same :)
Meanwhile thanks for all the suggestions :)
So I have setup a web app, virtual network, application gateway using this link. I also added a virtual network gateway to the vnet so that I can integrate my web app to the vnet.
Now correct me if I am wrong but isn't the purpose of integrating your web app with virtual network to make it more secure? if so then I should only be able to access my web app through the application gateway public IP correct?
Currently when I hit the the myapp.azurewebsites.net, I get to the application.
Do I have to do something extra here?
You are mixing several different things here.
Application gateway is just a proxy (more or less). It has no control over whatever server it is routing traffic to. It cannot magically make it not accept traffic not from application gateway. That is for the server to decide (in your case you need to use web.config as far as I remember to restrict incoming IP addresses only to the IP addresses of the application gateway). So adding application gateway to the mix doesnt make it more or less secure.
Vnet integration works only one way, FROM the webapp inside the Vnet. Things inside the vnet cannot talk back to the webapp using "internal" vnet traffic, they have to use external IP address. So this wont really help you.
If you want your webapp to be available only inside the VNet your best bet is App Service Environment, but its a lot more expensive :(
Is there a way that we can route outbound traffic going out from an ILB ASE to an static internal IP?
I understand that App Service Plans get assigned an IP dynamically from the subnet the ASE belongs to, but we have a need to make sure traffic comes to our on-premise data center from a static IP.
As for as I know, apps running in an App Service environment get static, dedicated IP addresses both for inbound and outbound connections. See here. As you said, we can't beforehand which IP address will be assigned app instance to make the outbound connection if there are scaled-out instances. Even now I could not find any official doc to define this. It's welcome to give feedback here.
Besides, if you want to route your ASE outbound traffic somewhere instead of directly routing to the internet, you can configure your App Service Environment with forced tunneling from this doc.
I've been trying to find an answer to this for a few days.
I want to host a new azure website in either the Basic tier or Standard tier.
The site will be calling a third party service.
I need to give this service provider an IP address that they will whitelist.
So when the new azure website makes requests to this service the IP address for the request needs to always be the same, as this will be the IP whitelisted.
I read that Azure offers "Reserved IPs" for cloud services and VMs but I wanted to know if something similar can be done with Azure Websites as I really don't want to go with cloud/VM.
My knowledge of networking is limited but as I understand it, if I were to get an IP SSL cert and apply that to my Azure Website then the website would have a static IP address.
If that is the case, would any requests to the third party service be hitting the service providers external firewall with this same static IP?
Thanks for any advice people can give.
An SSL cert with Web Sites will be tied to an inbound IP address. However, Web Sites does not provide a static outbound IP address.
If you need a static IP address to align with 3rd-party services, you'd need to have something residing in Azure (e.g. Application tier) running in a cloud service / VM that your web site accesses, and then have that app tier (with static IP address) communicate with your 3rd-party services.
As David Makogon's answer points out, applying an IP-based SSL certificate only gives the website a static inbound IP address.
However, the outbound IP address a website uses when making outbound network calls can be determined based on where your website is hosted. Microsoft has a list of the these IP addresses here. The third-party service would have to whitelist all of the IP addresses used by the scale unit your website is hosted in (e.g. waws-prod-am2-005).
Correct me if I am wrong, but the information shared by Brant Bobby above shows that, in fact:
All Azure websites (/Web Apps) already have a discoverable and published outgoing IP address.
This outgoing IP address will never be unique to their own site however. So one must keep in mind if they use it for a white-list, it will be allowing in a lot of other Azure visitors hosted on the same scale unit.
Simply get the so-called "scale unit" name for your site, which is the same as what's given in your site's FTP address (and so forth), which is in the format: "waws-prod-[3LetterVar]-[3DigitNum]", e.g. waws-prod-blu-007.
As an example from that article, all the East US region Azure websites can find the four IP addresses their site may rely on as follows (so if white-listing, all 4 should be white-listed):
East US Region
Outbound IP addresses for each scale unit, currently 4 for each. They said they may add more IPs to each scale unit in the future, but these should not change.
waws-prod-blu-001: 168.62.48.13, 168.62.48.19, 168.62.48.33, 168.62.48.122
waws-prod-blu-003: 137.117.81.128, 137.117.81.142, 137.117.81.181, 137.117.81.82
waws-prod-blu-005: 137.117.80.189, 137.117.81.52, 137.117.81.90, 137.117.80.178
waws-prod-blu-007: 23.96.33.205, 23.96.34.196, 23.96.35.20, 23.96.36.229
waws-prod-blu-009: 23.96.97.203, 23.96.97.233, 23.96.97.235, 23.96.97.238
waws-prod-blu-011: 23.96.112.60, 23.96.112.117, 23.96.112.152, 23.96.112.15
waws-prod-blu-013: 191.238.8.154, 191.238.9.80, 191.238.9.94, 191.238.9.170
waws-prod-blu-015: 191.236.19.222, 191.236.19.242, 191.236.21.165, 191.236.18.160
waws-prod-blu-017: 191.238.32.104, 191.238.32.154, 191.238.34.67, 191.238.35.12
waws-prod-blu-019: 104.45.138.197, 104.45.142.87, 104.45.128.144, 104.45.142.131
waws-prod-blu-021: 191.237.24.189, 191.237.30.36, 191.237.26.164, 191.237.28.161
waws-prod-blu-023: 191.236.50.206, 191.237.30.215, 191.237.25.148, 191.237.22.195
waws-prod-blu-025: 191.237.31.86, 191.237.26.176, 191.237.20.70, 191.237.18.239
Azure now supports having static outbound IP address as well.
https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
If we do not want to go for costlier App Service Environment setup, we can directly use the outbound IP addresses mentioned in the Azure portal in properties section, Azure assures that it remain 99.9% static. Nothing really changes until there is some changes data center wide. Moreover, the reserved Ip what we use in IaaS is also not 100% reserved for us and azure provides SLA of 99.9% here as well. So, In my opinion, instead of going for ASE and hosting IaaS and using reserved IP, we can just use outbound Ip provided by azure, since we get same reliability in both cases.