Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 458 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN to XG in Azure - Is SNAT required to access LAN resources?

LarryWarrington

I am having the same exact issue that Dirk was having in this post. Our situations sound almost identical. Unfortunately, that question was never answered and the post was closed, so I am re-asking the same question.

From what I have found elsewhere, some users are using SNAT for their SSL VPN clients when attaching to XG in Azure to allow access to LAN resources. I was able to have success doing that, but we don't have to use SNAT for our SSL VPN clients when they connect to our on-prem network and this feels like it's a patch, not a solution. This leads me to believe it's an Azure specific issue. Routing or NSG related. The VPN is receiving the packets, but the response is not making it back to the SSL client.

Another user mentioned having user defined routes that cover the VPN ip range, but that didn't seem to help me. perhaps I added them wrong.

on the lan subnet, my UDR routes are:

0.0.0.0/0 > Virtual appliance [10.4.4.4] (ip of the lan interface of the XG router)

10.4.3.0/24 > Virtual appliance [10.4.4.4] (ip of the lan interface of the XG router)  - 10.4.3.x is the IP range of the SSL VPN clients.



This thread was automatically locked due to age.
Parents
  • 0

    I think I may have answered my own question. I believe my mistake was using an IP range for my SSL VPN clients that was within my range for my Azure VNET. So Azure was seeing that as VNET traffic. I changed my SSL VPN IP range to one outside that range and it started working. Perhaps its possible to use an ip range within the Azure vnet range with the right combination of UDR and NSG entries, but for now, I am OK with using an address range outside the vnet address range.

Reply
  • 0

    I think I may have answered my own question. I believe my mistake was using an IP range for my SSL VPN clients that was within my range for my Azure VNET. So Azure was seeing that as VNET traffic. I changed my SSL VPN IP range to one outside that range and it started working. Perhaps its possible to use an ip range within the Azure vnet range with the right combination of UDR and NSG entries, but for now, I am OK with using an address range outside the vnet address range.

Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?