B
Bardo33
Hi,
Sorry for the long post. Providing as much detail as possible for clarity.
I have a configuration similar to Connect an on-premises network to Azure using VPN - Azure Reference Architectures whereby I am implementing an Azure VPN gateway to on-premises RRAS VPN connection. In this case, I am building the "on-premises" in Azure also, for example purposes. Therefore the on-premises has it's own Azure VNet and network isolation.
The "on-premises" RRAS server has 2 NICs; 1 with a public IP address (which the Azure S2S VPN connects to) and an internal. Internal IP of the public NIC is 192.168.1.50 and IP of the internal RRAS NIC is 192.168.2.50. The public NIC is the Azure "primary". Each NIC is bound to separate Azure VNET subnets. On the "on-premises" internal subnet I also have a PDC running (192.168.2.60). I can RDP from the RRAS to the PDC without issue.
The cross VPN connection is working fine in that a VM (e.g. 172.16.0.10) in a "real" Azure VNET (i.e. not the simulated on-premises one) can RDP to the RRAS server across the VPN. However, I am unable to communicate with any other VMs on the "on-premises" network via the VPN. E.g. from Azure VM across VPN/RRAS to the PDC.
I have installed Netmon 3.4 on all VMs and can see packets reach the RRAS server but are never forwarded to the PDC. I have also used PSPing (PsPing - Windows Sysinternals) and configured as a "server" on a different port (with "-f" option to ensure firewall is open) and Netmon indicates the same - no packets forwarded beyond the RRAS server.
Other relevant configuration:
- "enableIPForwarding" enabled on both RRAS NICs at the Azure NIC level
- "forwarding" enabled on all RRAS IP interfaces at the Windows OS level (as verified by "Get-NetIPInterface" command and "netsh interface ipv4 show interface l=verbose" command)
- RRAS is configured for IPv4 forwarding, as per screenshot in RRAS VPN (SSTP) in Azure - cannot ping other VMs in subnet
- I have a static route configured in RRAS which is the Azure VNET address space. I assume this is fine given RRAS can connect to the Azure VM, it's just that VMs DOWNSTREAM of the RRAS can't?
- DNS servers for the "on-premises" Azure VNET is set to the PDC IP
- DNS servers for the Azure VNET is left as default/Azure provided
- I have tried setting the default gateway for the internal PDC server to the INTERNAL NIC IP (192.168.2.50) of the RRAS server. It did not make any difference
Questions:
- What does it look like I have not configured correctly to get this network flow working?
- Am I correct in thinking this is most likely a RRAS IPv4 forwarding issue?
- What is the best way to troubleshoot RRAS forwarding (and routing, essentially any non client VPN access) issues? Event logs are not yielding anything, should the RRAS debug logs provide insight?
Other references:
social.technet.microsoft.com
social.technet.microsoft.com
Thanks very much in advance
Continue reading...
Sorry for the long post. Providing as much detail as possible for clarity.
I have a configuration similar to Connect an on-premises network to Azure using VPN - Azure Reference Architectures whereby I am implementing an Azure VPN gateway to on-premises RRAS VPN connection. In this case, I am building the "on-premises" in Azure also, for example purposes. Therefore the on-premises has it's own Azure VNet and network isolation.
The "on-premises" RRAS server has 2 NICs; 1 with a public IP address (which the Azure S2S VPN connects to) and an internal. Internal IP of the public NIC is 192.168.1.50 and IP of the internal RRAS NIC is 192.168.2.50. The public NIC is the Azure "primary". Each NIC is bound to separate Azure VNET subnets. On the "on-premises" internal subnet I also have a PDC running (192.168.2.60). I can RDP from the RRAS to the PDC without issue.
The cross VPN connection is working fine in that a VM (e.g. 172.16.0.10) in a "real" Azure VNET (i.e. not the simulated on-premises one) can RDP to the RRAS server across the VPN. However, I am unable to communicate with any other VMs on the "on-premises" network via the VPN. E.g. from Azure VM across VPN/RRAS to the PDC.
I have installed Netmon 3.4 on all VMs and can see packets reach the RRAS server but are never forwarded to the PDC. I have also used PSPing (PsPing - Windows Sysinternals) and configured as a "server" on a different port (with "-f" option to ensure firewall is open) and Netmon indicates the same - no packets forwarded beyond the RRAS server.
Other relevant configuration:
- "enableIPForwarding" enabled on both RRAS NICs at the Azure NIC level
- "forwarding" enabled on all RRAS IP interfaces at the Windows OS level (as verified by "Get-NetIPInterface" command and "netsh interface ipv4 show interface l=verbose" command)
- RRAS is configured for IPv4 forwarding, as per screenshot in RRAS VPN (SSTP) in Azure - cannot ping other VMs in subnet
- I have a static route configured in RRAS which is the Azure VNET address space. I assume this is fine given RRAS can connect to the Azure VM, it's just that VMs DOWNSTREAM of the RRAS can't?
- DNS servers for the "on-premises" Azure VNET is set to the PDC IP
- DNS servers for the Azure VNET is left as default/Azure provided
- I have tried setting the default gateway for the internal PDC server to the INTERNAL NIC IP (192.168.2.50) of the RRAS server. It did not make any difference
Questions:
- What does it look like I have not configured correctly to get this network flow working?
- Am I correct in thinking this is most likely a RRAS IPv4 forwarding issue?
- What is the best way to troubleshoot RRAS forwarding (and routing, essentially any non client VPN access) issues? Event logs are not yielding anything, should the RRAS debug logs provide insight?
Other references:
2012 RRAS NAT enabled but not forwarding traffic
social.technet.microsoft.com
RRAS VPN (SSTP) in Azure - cannot ping other VMs in subnet
social.technet.microsoft.com
RRAS: To use RRAS server as an IPv4 router, IPv4 forwarding must be enabled
technet.microsoft.com
Networking Blog
The Official Blog Site of the Windows Core Networking Team at Microsoft
blogs.technet.microsoft.com
Thanks very much in advance
Continue reading...