Hello @Javon Jackson , apologies for the delayed response and thank you for your patience here.
In Static-NAT there is a fixed address mapping relationship. For a given IP address, it will be mapped to the same address from the target pool
Ingress SNAT:
As mentioned in the documentation An IngressSNAT rule defines the translation of the source IP addresses coming into the Azure VPN gateway from the on-premises network.
So basically, for communication from on-prem to Azure, in Ingress SNAT the on-prem's address is translated. As the document further states It also handles the translation of the destination IP addresses leaving from the VNet to the same on-premises network.
For communication from Azure to On-prem the destination IP (this is also on-prem's IP) is translated.
For example, if a IngressSNAT rule has Internal Mapping of 10.0.1.0/24
(On-prem) address and External Mapping of 192.168.1.0/24
. When an on-prem device with IP 10.0.1.5
initiates a communication with Azure the source IP '10.0.1.5' is translated to 192.168.1.5
and the Azure Device replies with destination IP of 192.168.1.5
which is translated to 10.0.1.5
at gateway and then sent back to on-prem.
In EgressSNAT the Azure VNET IPs are translated with external mapping.
From your question above
Also, I'm using all only Egress rules because when I try Ingress rules I can't ping an IP on the on-premise network to confirm connectivity for some reason. Ping works just fine with Egress rule, which is odd to me. I thought the IP would be translated both ways based on this statement:
I think the connectivity should work even if both IngressSNAT and EgressSNAT are present. To debug this issue you can do a packet capture at both clients and see if SNAT is working as expected and also validate if any firewall, NSG is not blocking this connectivity.
Hope this helps! Please let me know if you have any additional questions. Thank you!