Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

XGS IPSec S2S Azure and isolating a shared MAC Mini with SSL VPN Contractor

Hello all,

Network (kinda) and XGS newb is back with another question.  I'm pretty sure the answer is going to be a "yes/no and you're just missing this little step to get it done".  I've included a summarizing picture.

Presently working:

We have an IPSec tunnel setup to our Azure vnet, and anyone using SSL VPN to connect to it is in a full/default gateway policy. There are 2 such policies and remote contractors only have access to the Azure vnet, with nothing internal being accessible. Remote corporate users have access to both internal and Azure vnet.

Issue:

As we are going to be creating an iOS app and Apple requires an Apple device to create said application, we're looking to provide isolated access to a Mac Mini that already exists in our corp environment to an external contractor with an AVD we supplied.  They are going to need access to both the existing and working Azure vnet (done) AND to the mentioned Mac Mini, without being able to access internal networks.

What I have done so far:

Created another LAN/Subnet 10.13.13.0/29 on Port 3 with an IP of 10.13.13.1 for the Port.  On the Mac Mini I gave it a static Ethernet IP of 10.13.13.3, and connected it to Port 3 on the XGS. The Mac Mini also is connected to our corporate network via Wi-Fi.

I still need to make sure that the Mac Mini can get access to the Az vnets from the ethernet port (and I'm even a bigger newb with Macs - but was going to turn off the WiFi and see where I can get).

Q: How can I ensure my Sophos config is correct (while testing the above) and where to start looking trace log wise should the contractor's AVD and his SLL VPN access can not access Mac Mini and finally, once on the Mac Mini, he can't connect to the corp lan? 



This thread was automatically locked due to age.
Parents
  • To understand your topology correctly from the remote contractor perspective, there is a sslvpn remote access tunnel from remote contractor to XGS and then the Mac mini is on a LAN network behind XGS. If that is correct, have you added the LAN network that the Mac mini belongs to, as permitted networks in the sslvpn remote access policy that is used by the remote contractors ? You can check for any dropped packets using drppkt command after doing ssh to the xgs and going to its shell.

  • Hello and thank you for the reply Nikhil.  The remote contractors are setup as (restricted) users (have their own SSL VPN policy) and connect to our XGS which has an Azure GateWay Tunnel IPsec connection to Azure (we use private endpoints on that side). They have resources on Azure that they utilize and no access to our on-premises network.  At the same time, we have employees on the same Azure tunnel, and they connect either on-premise or via another SSL VPN profile/policy/group on the same XGS. 

    The Mmini is connected to the XGS directly via Ethernet on a subnet. At the same time, it is also (WiFi) connected to the corporate network. There are no "local" users (yet) that require access to the Mmini for development, and we need to ensure that the same contractors can't access the corporate network, while on the Mmini.

    Perhaps the easiest explanation is that we need the XGS to isolate two networks from one source?

Reply
  • Hello and thank you for the reply Nikhil.  The remote contractors are setup as (restricted) users (have their own SSL VPN policy) and connect to our XGS which has an Azure GateWay Tunnel IPsec connection to Azure (we use private endpoints on that side). They have resources on Azure that they utilize and no access to our on-premises network.  At the same time, we have employees on the same Azure tunnel, and they connect either on-premise or via another SSL VPN profile/policy/group on the same XGS. 

    The Mmini is connected to the XGS directly via Ethernet on a subnet. At the same time, it is also (WiFi) connected to the corporate network. There are no "local" users (yet) that require access to the Mmini for development, and we need to ensure that the same contractors can't access the corporate network, while on the Mmini.

    Perhaps the easiest explanation is that we need the XGS to isolate two networks from one source?

Children
  • If I understood correctly, this is your requirement and has two parts:

    1) The remote contractors (some or all of them) should be able to connect to the Azure via an IPSec tunnel AND they should also be able to connect to the Mmini (which is directly connected to the XGS through a LAN port). 

    2) The Mmini is also connected to some corporate resources. The remote contractors should not get access to these resources while they access the Mmini

    If the above requirements are correct, I believe the IPSec tunnel part in 1) is already working and the Mmini part can be achieved by sslvpn policy on the XGS but 2) is dependent on the policies on the Mmini (which have to be figured out).