Forum Discussion
Connectivity from Azure to On-prem via S2S VPN
Hi,
We've just created new Azure environment with S2S VPN connected to our on-prem firewall. For testing, I've tried to connect to on-prem server via SMB from an Azure VM but I couldn't get it to work. I've already created firewall rules (Palo Alto) to allow incoming traffic from Azure subnets to internal servers over SMB. I've also allowed all outbound traffic on the NSG of the VM.
Is there any routing required to be set up in Azure, or am I missing something?
Many thanks,
James.
- I've managed to sort out the issues. Below is the list of what I had to do to get the whole thing to work.
1. Created a route table for on-prem traffic
2. Remove private DNS zone that was set up by external consultant (this was the root cause of routing issue)
3. Fixed up vnet peerings so the vnet that VPN is set up in works as a hub and the rest of vnets are in spoke setup
3 Replies
Please make sure:
1. Port 445
2. Route traffic are back to Azure
3. DNS resolution
4. SMB version
Kidd_Ip thank you for your reply.
I've managed to get connectivity but I'm seeing weird stuff.
I've done the following:
- created a route table and added static route for on-prem with next hop pointing to virtual network gateway
- allowed any-any traffic for both inbound and outbound
I can now see ping and RDP traffic hitting on-prem firewall but they are blocked as there's currently no policies to allow this. The weird thing is that I've tried to generate other traffic over different ports such as, DNS, SMB, LDAP and other stuff, but they aren't showing up (not hitting) on on-prem firewall at all.
I'm basically trying to join a server on to the domain using on-prem domain controller but none of the Active Directory related traffic is hitting on-prem firewall at all. All I can see if ping and RDP traffic right now.
Am I missing something?
Thanks,
J
- I've managed to sort out the issues. Below is the list of what I had to do to get the whole thing to work.
1. Created a route table for on-prem traffic
2. Remove private DNS zone that was set up by external consultant (this was the root cause of routing issue)
3. Fixed up vnet peerings so the vnet that VPN is set up in works as a hub and the rest of vnets are in spoke setup
