Objective
For the remote site-to-site reachable office, the VPN router needs to have the VPN client pool marked as a VPN-interesting destination network across the VPN. Lastly, for client VPNs configuration on the head office ASA you need to make sure the client VPN configuration allows the client pool network access to the site-to-site VPN reachable. Cisco VPN Clients are available for download from our Cisco Downloads section. The Cisco VPN also introduces the concept of ‘Split Tunneling'. Split tunneling is a feature that allows a remote VPN client access the company's LAN, but at the same time surf the Internet. The Client-to-Site screen is for a connection from devices using the Cisco VPN client software. The SSL VPN screen is for connections through a web browser or using the AnyConnect client. Does the SSL VPN screen appear exactly as in the screenshot? Maybe try 192.168.1.0 as the Address Pool address? Log in to the router web-based utility and choose VPN Client-to-Site. Click the Add button under IPSec Client-to-Site Tunnels section.
Anydesk mac permissions. This article explains how to configure remote access Virtual Private Network (VPN) tunnel from client to gateway on RV016, RV042, RV042G and RV082 VPN Routers with the help of third party VPN client software as The Green Bow or VPN Tracker.
Introduction
A VPN is a private network that is used to virtually connect devices of the remote user through the public network to provide security. Remote access tunnel VPN is the process used to configure a VPN between a client computer and a network. The client is configured in the desktop or laptop of the users through VPN client software. It provides the users to securely connect with the network remotely. Client to gateway VPN connection is useful for the remote employees to connect to the office network remotely and securely.
Applicable Devices
- RV016
- RV042
- RV042G
- RV082
Software Version
- v4.2.2.08
Configure a VPN Tunnel
Step 1. Log in to the web configuration utility and choose VPN > Client to Gateway. The Client to Gateway page opens:
Add a New Tunnel
Step 1. Click the appropriate radio button according to what kind of tunnel you want to add.
- Tunnel - Represents a tunnel for a remote single user.
- Group VPN - Represents a tunnel for a remote group of users.
The Tunnel Number is an automatically generated field that displays the number of the tunnel.
Step 2. Enter a name for the tunnel in the Tunnel Name field.
Step 3. Choose the appropriate WAN interface to use for the VPN tunnel from the Interface drop-down list.
Step 4. (Optional) To enable the VPN, check the check box in the Enable field. By default it is always checked.
Local Group Setup
Step 1. Choose the appropriate router identification method to establish a VPN tunnel from the Local Security Gateway drop-down list. Skip this step if you chose Group VPN in Step 1 of the Add A New Tunnel section.
- IP Only - Access to the tunnel is possible through a static WAN IP address. You can choose this option only if the router has a static WAN IP. The static WAN IP address appears automatically.
- IP + Domain Name(FQDN) Authentication - Access to the tunnel is possible through a static IP address and a registered Fully Qualified Domain Name (FQDN) domain. The static WAN IP address is an auto generated field.
- IP + E-mail Address(USER FQDN) Authentication - Access to the tunnel is possible through a static IP address and an email address. The static WAN IP address is an auto generated field.
- Dynamic IP + Domain Name(FQDN) Authentication - Access to the tunnel is possible through a dynamic IP address and a registered domain.
- Dynamic IP + E-mail Address(USER FQDN) Authentication — Access to the tunnel is possible through a dynamic IP address and an email address.
Step 2. Enter the name of the registered Fully Qualified Domain in the Domain Name field if you choose IP + Domain Name (FQDN) Authentication or Dynamic IP + Domain Name (FQDN) Authentication in Step 1.
Step 3. Enter the Email Address in the Email Address field if you choose IP + E-mail Address(USER FQDN) Authentication or Dynamic IP + E-mail Address(USER FQDN) Authentication in Step 1.
Step 4. Choose the appropriate local LAN user or group of users who can access the VPN tunnel from the Local Security Group drop-down list. The default is Subnet.
- IP - Only one specific LAN device can access to the tunnel. If you choose this option, enter the IP address of the LAN device in the IP Address field. The default IP is 192.168.1.0.
- Subnet - All LAN devices on a specific subnet can access to the tunnel. If you choose this option, enter the IP address and subnet mask of the LAN devices in the IP Address and Subnet Mask field respectively. The default mask is 255.255.255.0.
- IP Range - A range of LAN devices can access to the tunnel. If you choose this option, enter the starting and ending IP address in the Begin IP and End IP fields respectively. The default range is from 192.168.1.0 to 192.168.1.254.
Step 5. Click Save to save the settings.
Remote Client Setup
Step 1. If you choose Tunnel, choose the appropriate client identification method to establish a VPN tunnel from the Remote Security Gateway Type drop-down list. The default is IP Only. Skip this step if Group VPN in Step 1 of the Add A New Tunnel section was chosen.
- IP Only - Access to the tunnel is possible through the static WAN IP of the client only. You must know the static WAN IP of the client to use this option.
- IP + Domain Name(FQDN) Authentication - Access to the tunnel is possible through a static IP address of the client and a registered domain.
- IP + E-mail Address(USER FQDN) Authentication - Access to the tunnel is possible through a static IP address of the client and an email address.
- Dynamic IP + Domain Name(FQDN) Authentication - Access to the tunnel is possible through a dynamic IP address of the client and a registered domain.
- Dynamic IP + E-mail Address(USER FQDN) Authentication - Access to the tunnel is possible through a dynamic IP address of the client and an email address.
Step 2. Enter the IP address of the remote client in the IP Address field if you chose IP Only, IP + Domain Name (FQDN), or IP + E-mail Address (User FQDN) Authentication in Step 1.
Step 3. Choose the appropriate option from the drop-down list to enter the IP address if you know it or resolve the IP address from the DNS server if you choose IP Only or IP + Domain Name (FQDN) Authentication or IP + E-mail Address(USER FQDN) Authentication in the Step 1.
- IP Address - Represents the static IP address of the remote client. Enter the static IP address in the field.
- IP by DNS Resolved - Represents the domain name of the IP address which retrieves the IP address automatically through the local DNS server if you do not know the static IP address of the remote client. Enter the domain name of the IP address in the field.
Step 4. Enter the domain name of the IP address in the Domain name field if you choose IP + Domain Name (FQDN) Authentication or Dynamic IP + Domain Name (FQDN) Authentication in Step 1.
Step 5. Enter the email address in the Email Address field if you choose IP + E-mail Address(USER FQDN) Authentication or Dynamic IP + E-mail Address(USER FQDN) Authentication in Step 1.
Step 6. If you choose Group, choose the appropriate remote client type from the Remote Client drop-down list. Skip this step if Tunnel VPN in Step 1 of the Add A New Tunnel section was chosen.
- Domain Name (FQDN) - Access to the tunnel is possible through a registered domain. If you choose this option, enter the name of the registered Domain in the Domain Name field.
- E-mail Addr.(USER FQDN) - Access to the tunnel is possible through an email address of the client. If you choose this option, enter the Email Address in the Email Address field.
- Microsoft XP/2000 VPN Client - Access to the tunnel is possible through Microsoft XP or Microsoft 2000 windows software. Remote users with Microsoft VPN client software can access to the tunnel through the software.
Step 7. Click Save to save the settings.
IPSec Setup
Internet Protocol Security (IPSec) is an internet layer security protocol which provides end-to-end security through authentication and encryption during any communication session.
Note: Two ends of the VPN need to have the same methods of encryption, decryption and authentication for the IPSec to work. Also the Perfect Forward Secrecy key must be same on the both side of the tunnel.
Step 1. Choose the appropriate mode of key management to ensure security from the Keying Mode drop-down list. The default mode is IKE with Preshared key.
Cisco Anyconnect Vpn Client Download
- Manual - A custom security mode to generate a new security key by yourself and no negotiation with the key. It is the best to use during troubleshooting and small static environment. If you choose Group VPN in Step 1 in Add A New Tunnel section, this option is disabled.
- IKE with Preshared key - Internet Key Exchange (IKE) protocol is used to automatically generate and exchange a preshared key to establish authenticate communication for the tunnel.
Manual Key Mode Configuration
Step 1. Enter the unique hexadecimal value for incoming Security Parameter Index (SPI) in the Incoming SPI field. SPI is carried in Encapsulating Security Payload Protocol (ESP) header which together determine the protection for the incoming packet. You can enter from 100 to ffffffff. The incoming SPI of the local router need to match with the outgoing SPI of the remote router.
Step 2. Enter the unique hexadecimal value for outgoing Security Parameter Index (SPI) in the Outgoing SPI field. SPI is carried in Encapsulating Security Payload Protocol (ESP) header which together determine the protection for the outgoing packet. You can enter from 100 to ffffffff. The outgoing SPI of the remote router need to match with the incoming SPI of the local router.
Step 3. Choose the appropriate encryption method for the data from the Encryption drop-down list. The recommended encryption is 3DES. The VPN tunnel needs to use the same encryption method for both ends.
- DES - Data Encryption Standard (DES) uses a 56-bit key size for data encryption. DES is outdated and should be only used if one endpoint only supports DES.
- 3DES - Triple Data Encryption Standard (3DES) is a 168 bit, simple encryption method. 3DES encrypts the data three times, which provides more security then DES.
Step 4. Choose the appropriate authentication method for the data from the Authentication drop-down list. The recommended authentication is SHA1 as it is more secure than MD5. The VPN tunnel needs to use the same authentication method for both ends.
- MD5 - Message Digest Algorithm-5 (MD5) represents 32 digit hexadecimal hash function which provides protection to the data from malicious attack by the checksum calculation.
- SHA1 - Secure Hash Algorithm version 1 (SHA1) is a 160 bit hash function which is more secure than MD5 but it takes more time to compute.
Step 5. Enter the key to encrypt and decrypt data in the Encryption Key field. If you choose DES as encryption method in Step 3, enter a 16 digit hexadecimal value. If you choose 3DES as encryption method in Step 3, enter a 40 digit hexadecimal value.
Step 6. Enter a pre-shared key to authenticate the traffic in Authentication Key field. If you choose MD5 as authentication method in step 4, enter 32 digit hexadecimal value. If you choose SHA as authentication method in Step 4, enter 40 digit hexadecimal value. The VPN tunnel needs to use the same preshared key for both of its ends.
Step 7. Click Save to save the settings.
IKE with Preshared Key Mode Configuration
Step 1. Choose the appropriate Phase 1 DH Group from the Phase 1 DH Group drop-down list. Phase 1 is used to establish the simplex, logical security association (SA) between the two ends of the tunnel to support secure authenticate communication. Diffie-Hellman (DH) is a cryptographic key exchange protocol which is used to determine the strength of the key during Phase 1 and it also shares the secret key to authenticate the communication.
- Group 1 - 768 bit - The lowest strength key and the most insecure authentication group. But it takes less time to compute the IKE keys. This option is preferred if the speed of the network is low.
- Group 2 - 1024 bit - The higher strength key and more secure authentication group. But it needs some time to compute the IKE keys.
- Group 5 - 1536 bit - Represents the highest strength key and the most secure authentication group. It needs more time to compute the IKE keys. It is preferred if the speed of the network is high.
Step 2. Choose the appropriate Phase 1 Encryption to encrypt the key from the Phase 1 Encryption drop-down list. 3DES is recommended as it is the most secure encryption method. The VPN tunnel needs to use the same encryption method for both of its ends.
- DES - Data Encryption Standard (DES) uses a 56-bit key size for data encryption. DES is outdated and should be only used if one endpoint only supports DES.
- 3DES - Triple Data Encryption Standard (3DES) is a 168 bit, simple encryption method. 3DES encrypts the data three times, which provides more security then DES.
- AES-128 - Advanced Encryption Standard (AES) is 128 bit encryption method which transforms the plain text into cipher text through 10 cycles repetitions.
- AES-192 - Advanced Encryption Standard (AES) is 192 bit encryption method which transforms the plain text into cipher text through 12 cycles repetitions. AES-192 is more secure than AES-128.
- AES-256 - Advanced Encryption Standard (AES) is 256 bit encryption method which transforms the plain text into cipher text through 14 cycles repetitions. AES-256 is the most secure encryption method.
Step 3. Choose the appropriate Phase 1 authentication method from the Phase 1 Authentication drop-down list. The VPN tunnel needs to use the same authentication method for both of its ends.
- MD5 - Message Digest Algorithm-5 (MD5) represents 32 digit hexadecimal hash function which provide protection to the data from malicious attack by the checksum calculation.
- SHA1 - Secure Hash Algorithm version 1 (SHA1) is a 160 bit hash function which is more secure than MD5 but it takes more time to compute.
Step 4. Enter the amount of time in seconds that the Phase 1 keys are valid and the VPN tunnel remains active in the Phase 1 SA Life Time field.
Step 5. Check the Perfect Forward Secrecy check box to provide more protection to the keys. This option allows the router to generate a new key if any key is compromised. The encrypted data is only compromised through the compromised key. So it provides more secure and authenticate communication as it secures other keys though a key is compromised. This is a recommended action as it provides more security.
Step 6. Choose the appropriate Phase 2 DH Group from the Phase 2 DH Group drop-down list. Phase 2 uses security association and it is used to determine the security of the data packet during the data packets pass through the two end points.
Step 7. Choose the appropriate Phase 2 Encryption to encrypt the key from the Phase 2 Encryption drop-down list. AES-256 is recommended as it is the most secure encryption method. The VPN tunnel needs to use the same encryption method for both of its ends.
- DES - Data Encryption Standard (DES) uses a 56-bit key size for data encryption. DES is outdated and should be only used if one endpoint only supports DES.
- 3DES - Triple Data Encryption Standard (3DES) is a 168 bit, simple encryption method. 3DES encrypts the data three times, which provides more security then DES.
- AES-128 - Advanced Encryption Standard (AES) is 128 bit encryption method which transforms the plain text into cipher text through 10 cycles repetitions.
- AES-192 - Advanced Encryption Standard (AES) is 192 bit encryption method which transforms the plain text into cipher text through 12 cycles repetitions. AES-192 is more secure than AES-128.
- AES-256 - Advanced Encryption Standard (AES) is 256 bit encryption method which transforms the plain text into cipher text through 14 cycles repetitions. AES-256 is the most secure encryption method.
Step 8. Choose the appropriate authentication method from the Phase 2 Authentication drop-down list. The VPN tunnel needs to use the same authentication method for both ends.
- MD5 - Message Digest Algorithm-5 (MD5) represents 32 digit hexadecimal hash function which provide protection to the data from malicious attack by the checksum calculation.
- SHA1 - Secure Hash Algorithm version 1 (SHA1) is a 160 bit hash function which is more secure than MD5 but it takes more time to compute.
- Null - No authentication method is used.
Step 9. Enter the amount of time in seconds that the Phase 2 keys are valid and the VPN tunnel remains active in the Phase 2 SA Life Time field.
Step 10. Enter a key which is shared previously between the IKE peers to authenticate the peers in the Preshared Key field. Up to 30 hexadecimal and character can be used as the preshared key. The VPN tunnel needs to use the same preshared key for both of its ends.
Note: It is strongly recommended to frequently change the preshared key between the IKE peers so the the VPN remains secured.
Step 11. Check the Minimum Preshared Key Complexity check box if you want to enable strength meter for the preshared key. It is used for determine the strength of the preshared key through color bars
Note: Preshared Key Strength Meter shows the strength of the preshared key through colored bars. Red indicates weak strength, yellow indicates acceptable strength and green indicates strong strength.
Step 12. Click Save to save the settings.
Advanced IKE with Pre-shared Key Mode Configuration
Step 1. Click Advanced to display the advanced settings for IKE with Preshared key.
Step 2. Check the Aggressive Mode check box if your network speed is low. This exchanges the IDs of the end points of the tunnel in clear text during SA connection (Phase 1), which requires less time to exchange but is less secure.
Note: Aggressive Mode is not available for group client to gateway VPN connection.
Step 3. Check the Compress (Support IP Payload Compression Protocol (IPComp)) check box if you want to compress the size of the IP datagrams. IPComp is an IP compression protocol which is used to compress the size of IP datagram. IP compression is useful if the network speed is low and the user wants to quickly transmit the data without any loss through the slow network, but it does not provide any security.
Step 4. Check the Keep-Alive check box if you always want the connection of the VPN tunnel remain active. Keep Alive helps to re-establish the connections immediately if any connection becomes inactive.
DJ RR (Ricardo Roberto) DJ, VJ, Video Editor, Video Producer. When I'm not on a stage, in a booth, or behind the decks I am somewhere creating state-of-the-art video remixes. I take great pride in my work, audio or video. That being mentioned, you can expect that when you contract me you will receive. Free music streaming for djs.
Step 5. Check the AH Hash Algorithm check box if you want to enable Authenticate Header (AH). AH provides authentication to origin data, data integrity through checksum and protection into the IP header. The tunnel should have the same algorithm for both of its sides.
- MD5 - Message Digest Algorithm-5 (MD5) represents 128 digit hexadecimal hash function which provides protection to the data from malicious attack by the checksum calculation.
- SHA1 - Secure Hash Algorithm version 1 (SHA1) is a 160 bit hash function which is more secure than MD5 but it takes more time to compute.
Step 6. Check NetBIOS Broadcast if you want to allow non-routable traffic through the VPN tunnel. The default is unchecked. NetBIOS is used to detect network resources like printers, computers etc. in the network through some software applications and Windows features like Network Neighborhood.
Step 7. Check NAT Traversal check box if you want to access to the internet from your private LAN through a public IP address. If your VPN router is behind a NAT gateway, check this check box to enable NAT traversal. Both ends of the tunnel must have the same settings.
Step 8. Check Dead Peer Detection Interval to check the liveliness of the VPN tunnel through hello or ACK in a periodic manner. If you check this check box, enter the desired duration or interval of the hello messages.
Note: You can configure Dead Peer Detection Interval only for single client to gateway VPN connection, not for group client to gateway VPN connection.
Step 9. Click Save to save the settings.
You have now learned how to configure remote access VPN tunnel from client to gateway on RV016, RV042, RV042G and RV082 VPN routers.
-->Note
This topic is part of a set of topics that address Office 365 optimization for remote users.
- For an overview of using VPN split tunneling to optimize Office 365 connectivity for remote users, see Overview: VPN split tunneling for Office 365.
- For information about optimizing Office 365 worldwide tenant performance for users in China, see Office 365 performance optimization for China users.
For many years, enterprises have been using VPNs to support remote experiences for their users. Whilst core workloads remained on-premises, a VPN from the remote client routed through a datacenter on the corporate network was the primary method for remote users to access corporate resources. To safeguard these connections, enterprises build layers of network security solutions along the VPN paths. This security was built to protect internal infrastructure and to safeguard mobile browsing of external web sites by rerouting traffic into the VPN and then out through the on-premises Internet perimeter. VPNs, network perimeters, and associated security infrastructure were often purpose-built and scaled for a defined volume of traffic, typically with most connectivity being initiated from within the corporate network, and most of it staying within the internal network boundaries.
For quite some time, VPN models where all connections from the remote user device are routed back into the on-premises network (known as forced tunneling) were largely sustainable as long as the concurrent scale of remote users was modest and the traffic volumes traversing VPN were low. Some customers continued to use VPN force tunneling as the status quo even after their applications moved from inside the corporate perimeter to public SaaS clouds, Office 365 being a prime example.
The use of forced tunneled VPNs for connecting to distributed and performance-sensitive cloud applications is suboptimal, but the negative effect of that may have been accepted by some enterprises so as to maintain the status quo from a security perspective. An example diagram of this scenario can be seen below:
This problem has been growing for many years, with many customers reporting a significant shift of network traffic patterns. Traffic that used to stay on premises now connects to external cloud endpoints. Numerous Microsoft customers report that previously, around 80% of their network traffic was to some internal source (represented by the dotted line in the above diagram). In 2020 that number is now around 20% or lower as they have shifted major workloads to the cloud, these trends are not uncommon with other enterprises. Over time, as the cloud journey progresses, the above model becomes increasingly cumbersome and unsustainable, preventing an organization from being agile as they move into a cloud first world.
The worldwide COVID-19 crisis has escalated this problem to require immediate remediation. The need to ensure employee safety has generated unprecedented demands on enterprise IT to support work-from-home productivity at a massive scale. Microsoft Office 365 is well positioned to help customers fulfill that demand, but high concurrency of users working from home generates a large volume of Office 365 traffic which, if routed through forced tunnel VPN and on-premises network perimeters, causes rapid saturation and runs VPN infrastructure out of capacity. In this new reality, using VPN to access Office 365 is no longer just a performance impediment, but a hard wall that not only impacts Office 365 but critical business operations that still have to rely on the VPN to operate.
Microsoft has been working closely with customers and the wider industry for many years to provide effective, modern solutions to these problems from within our own services, and to align with industry best practice. Connectivity principles for the Office 365 service have been designed to work efficiently for remote users whilst still allowing an organization to maintain security and control over their connectivity. These solutions can also be implemented quickly with limited work yet achieve a significant positive impact on the problems outlined above.
Microsoft's recommended strategy for optimizing remote worker's connectivity is focused on rapidly alleviating the problems with the traditional approach and also providing high performance with a few simple steps. These steps adjust the legacy VPN approach for a few defined endpoints that bypass bottlenecked VPN servers. An equivalent or even superior security model can be applied at different layers to remove the need to secure all traffic at the egress of the corporate network. In most cases this can be effectively achieved within hours and is then scalable to other workloads as requirements demand and time allows.
Common VPN scenarios
In the list below you'll see the most common VPN scenarios seen in enterprise environments. Most customers traditionally operate model 1 (VPN Forced Tunnel). This section will help you to quickly and securely transition to model 2, which is achievable with relatively little effort, and has enormous benefits to network performance and user experience.
Model | Description |
---|---|
1. VPN Forced Tunnel | 100% of traffic goes into VPN tunnel, including on-premise, Internet, and all O365/M365 |
2. VPN Forced Tunnel with few exceptions | VPN tunnel is used by default (default route points to VPN), with few, most important exempt scenarios that are allowed to go direct |
3. VPN Forced Tunnel with broad exceptions | VPN tunnel is used by default (default route points to VPN), with broad exceptions that are allowed to go direct (such as all Office 365, All Salesforce, All Zoom) |
4. VPN Selective Tunnel | VPN tunnel is used only for corpnet-based services. Default route (Internet and all Internet-based services) goes direct. |
5. No VPN | A variation of #2, where instead of legacy VPN, all corpnet services are published through modern security approaches (like Zscaler ZPA, Azure Active Directory (Azure AD) Proxy/MCAS, etc.) |
1. VPN Forced Tunnel
This is the most common starting scenario for most enterprise customers. A forced VPN is used, which means 100% of traffic is directed into the corporate network regardless of the fact the endpoint resides within the corporate network or not. Any external (Internet) bound traffic such as Office 365 or Internet browsing is then hair-pinned back out of the on premises security equipment such as proxies. In the current climate with nearly 100% of users working remotely, this model therefore puts high load on the VPN infrastructure and is likely to significantly hinder performance of all corporate traffic and thus the enterprise to operate efficiently at a time of crisis.
2. VPN Forced Tunnel with a small number of trusted exceptions
This model is significantly more efficient for an enterprise to operate under as it allows a few controlled and defined endpoints that are very high load and latency sensitive to bypass the VPN tunnel and go direct to the Office 365 service in this example. This significantly improves the performance for the offloaded services, and also decreases the load on the VPN infrastructure, thus allowing elements that still require it to operate with lower contention for resources. It is this model that this article concentrates on assisting with the transition to as it allows for simple, defined actions to be taken quickly with numerous positive outcomes.
3. VPN Forced Tunnel with broad exceptions
The third model broadens the scope of model two as rather than just sending a small group of defined endpoints direct, it instead sends all traffic directly to trusted services such Office 365 and SalesForce. This further reduces the load on the corporate VPN infrastructure and improves the performance of the services defined. As this model is likely to take more time to assess the feasibility of and implement, it is likely a step that can be taken iteratively at a later date once model two is successfully in place.
4. VPN selective Tunnel
This model reverses the third model in that only traffic identified as having a corporate IP address is sent down the VPN tunnel and thus the Internet path is the default route for everything else. This model requires an organization to be well on the path to Zero Trust in able to safely implement this model. It should be noted that this model or some variation thereof will likely become the necessary default over time as more and more services move away from the corporate network and into the cloud. Microsoft uses this model internally; you can find more information on Microsoft's implementation of VPN split tunneling at Running on VPN: How Microsoft is keeping its remote workforce connected.
5. No VPN
A more advanced version of model number two, whereby any internal services are published through a modern security approach or SDWAN solution such as Azure AD Proxy, MCAS, Zscaler ZPA, etc.
Implement VPN split tunneling
In this section, you'll find the simple steps required to migrate your VPN client architecture from a VPN forced tunnel to a VPN forced tunnel with a small number of trusted exceptions, VPN split tunnel model #2 in Common VPN scenarios.
The diagram below illustrates how the recommended VPN split tunnel solution works:
1. Identify the endpoints to optimize
In the Office 365 URLs and IP address ranges topic, Microsoft clearly identifies the key endpoints you need to optimize and categorizes them as Optimize. There are currently just four URLS and 20 IP subnets that need to be optimized. This small group of endpoints accounts for around 70% - 80% of the volume of traffic to the Office 365 service including the latency sensitive endpoints such as those for Teams media. Essentially this is the traffic that we need to take special care of and is also the traffic that will put incredible pressure on traditional network paths and VPN infrastructure.
URLs in this category have the following characteristics:
- Are Microsoft owned and managed endpoints, hosted on Microsoft infrastructure
- Have IPs provided
- Low rate of change and are expected to remain small in number (currently 20 IP subnets)
- Are bandwidth and/or latency sensitive
- Are able to have required security elements provided in the service rather than inline on the network
- Account for around 70-80% of the volume of traffic to the Office 365 service
For more information about Office 365 endpoints and how they are categorized and managed, see the article Managing Office 365 endpoints.
Optimize URLs
The current Optimize URLs can be found in the table below. Under most circumstances, you should only need to use URL endpoints in a browser PAC file where the endpoints are configured to be sent direct, rather than to the proxy.
Optimize URLs | Port/Protocol | Purpose |
---|---|---|
https://outlook.office365.com | TCP 443 | This is one of the primary URLs Outlook uses to connect to its Exchange Online server and has a high volume of bandwidth usage and connection count. Low network latency is required for online features including: instant search, other mailbox calendars, free / busy lookup, manage rules and alerts, Exchange online archive, emails departing the outbox. |
https://outlook.office.com | TCP 443 | This URL is used for Outlook Online Web Access to connect to Exchange Online server, and is sensitive to network latency. Connectivity is particularly required for large file upload and download with SharePoint Online. |
https://<tenant>.sharepoint.com | TCP 443 | This is the primary URL for SharePoint Online and has high-bandwidth usage. |
https://<tenant>-my.sharepoint.com | TCP 443 | This is the primary URL for OneDrive for Business and has high bandwidth usage and possibly high connection count from the OneDrive for Business Sync tool. |
Teams Media IPs (no URL) | UDP 3478, 3479, 3480, and 3481 | Relay Discovery allocation and real-time traffic (3478), Audio (3479), Video (3480), and Video Screen Sharing (3481). These are the endpoints used for Skype for Business and Microsoft Teams Media traffic (calls, meetings, etc.). Most endpoints are provided when the Microsoft Teams client establishes a call (and are contained within the required IPs listed for the service). Use of the UDP protocol is required for optimal media quality. |
In the above examples, tenant should be replaced with your Office 365 tenant name. For example, contoso.onmicrosoft.com would use contoso.sharepoint.com and constoso-my.sharepoint.com.
Optimize IP address ranges
At the time of writing the IP ranges that these endpoints correspond to are as follows. It is very strongly advised you use a script such as this example, the Office 365 IP and URL web service or the URL/IP page to check for any updates when applying the configuration, and put a policy in place to do so regularly.
2. Optimize access to these endpoints via the VPN
Now that we have identified these critical endpoints, we need to divert them away from the VPN tunnel and allow them to use the user's local Internet connection to connect directly to the service. The manner in which this is accomplished will vary depending on the VPN product and machine platform used but most VPN solutions will allow some simple configuration of policy to apply this logic. For information VPN platform-specific split tunnel guidance, see HOWTO guides for common VPN platforms.
If you wish to test the solution manually, you can execute the following PowerShell example to emulate the solution at the route table level. This example adds a route for each of the Teams Media IP subnets into the route table. You can test Teams media performance before and after, and observe the difference in routes for the specified endpoints.
Example: Add Teams Media IP subnets into the route table
In the above script, $intIndex is the index of the interface connected to the internet (find by running get-netadapter in PowerShell; look for the value of ifIndex) and $gateway is the default gateway of that interface (find by running ipconfig in a command prompt or (Get-NetIPConfiguration | Foreach IPv4DefaultGateway).NextHop in PowerShell).
Cisco Rv260 Client To Site Vpn
Once you have added the routes, you can confirm that the route table is correct by running route print in a command prompt or PowerShell. The output should contain the routes you added, showing the interface index (22 in this example) and the gateway for that interface (192.168.1.1 in this example):
To add routes for all current IP address ranges in the Optimize category, you can use the following script variation to query the Office 365 IP and URL web service for the current set of Optimize IP subnets and add them to the route table.
Example: Add all Optimize subnets into the route table
If you inadvertently added routes with incorrect parameters or simply wish to revert your changes, you can remove the routes you just added with the following command:
The VPN client should be configured so that traffic to the Optimize IPs are routed in this way. This allows the traffic to utilize local Microsoft resources such as Office 365 Service Front Doors such as the Azure Front Door that deliver Office 365 services and connectivity endpoints as close to your users as possible. This allows us to deliver high performance levels to users wherever they are in the world and takes full advantage of Microsoft's world class global network, which is likely within a few milliseconds of your users' direct egress.
Configuring and securing Teams media traffic
Some administrators may require more detailed information on how call flows operate in Teams using a split tunneling model and how connections are secured.
Configuration
For both calls and meetings, as long as the required Optimize IP subnets for Teams media are correctly in place in the route table, when Teams calls the GetBestRoute function to determine which local interface corresponds to the route it should use for a particular destination, the local interface will be returned for Microsoft destinations in the Microsoft IP blocks listed above.
Some VPN client software allows routing manipulation based on URL. However, Teams media traffic has no URL associated with it, so control of routing for this traffic must be done using IP subnets.
In certain scenarios, often unrelated to Teams client configuration, media traffic still traverses the VPN tunnel even with the correct routes in place. If you encounter this scenario, then using a firewall rule to block the Teams IP subnets or ports from using the VPN should suffice.
Important
To ensure Teams media traffic is routed via the desired method in all VPN scenarios, please ensure users are running Microsoft Teams client version 1.3.00.13565 or greater. This version includes improvements in how the client detects available network paths.
Signaling traffic is performed over HTTPS and is not as latency sensitive as the media traffic and is marked as Allow in the URL/IP data and thus can safely be routed through the VPN client if desired.
Security
One common argument for avoiding split tunnels is that it is less secure to do so, i.e any traffic that does not go through the VPN tunnel will not benefit from whatever encryption scheme is applied to the VPN tunnel, and is therefore less secure.
The main counter-argument to this is that media traffic is already encrypted via Secure Real-Time Transport Protocol (SRTP), a profile of Real-Time Transport Protocol (RTP) that provides confidentiality, authentication, and replay attack protection to RTP traffic. SRTP itself relies on a randomly generated session key, which is exchanged via the TLS secured signaling channel. This is covered in great detail within this security guide, but the primary section of interest is media encryption.
Media traffic is encrypted using SRTP, which uses a session key generated by a secure random number generator and exchanged using the signaling TLS channel. In addition, media flowing in both directions between the Mediation Server and its internal next hop is also encrypted using SRTP.
Skype for Business Online generates username/passwords for secure access to media relays over Traversal Using Relays around NAT (TURN). Media relays exchange the username/password over a TLS-secured SIP channel. It is worth noting that even though a VPN tunnel may be used to connect the client to the corporate network, the traffic still needs to flow in its SRTP form when it leaves the corporate network to reach the service.
Information on how Teams mitigates common security concerns such as voice or Session Traversal Utilities for NAT (STUN) amplification attacks can be found in 5.1 Security Considerations for Implementers.
You can also read about modern security controls in remote work scenarios at Alternative ways for security professionals and IT to achieve modern security controls in today's unique remote work scenarios (Microsoft Security Team blog).
Testing
Once the policy is in place, you should confirm it is working as expected. There are multiple ways of testing the path is correctly set to use the local Internet connection:
- Run the Microsoft 365 connectivity test that will run connectivity tests for you including trace routes as above. We're also adding in VPN tests into this tooling that should also provide additional insights.
- A simple tracert to an endpoint within scope of the split tunnel should show the path taken, for example:You should then see a path via the local ISP to this endpoint that should resolve to an IP in the Teams ranges we have configured for split tunneling.
- Take a network capture using a tool such as Wireshark. Filter on UDP during a call and you should see traffic flowing to an IP in the Teams Optimize range. If the VPN tunnel is being used for this traffic, then the media traffic will not be visible in the trace.
Additional support logs
If you need further data to troubleshoot, or are requesting assistance from Microsoft support, obtaining the following information should allow you to expedite finding a solution. Microsoft support's TSS Windows CMD-based universal TroubleShooting Script toolset can help you to collect the relevant logs in a simple manner. The tool and instructions on use can be found at https://aka.ms/TssTools.
HOWTO guides for common VPN platforms
This section provides links to detailed guides for implementing split tunneling for Office 365 traffic from the most common partners in this space. We'll add additional guides as they become available.
- Windows 10 VPN client: Optimizing Office 365 traffic for remote workers with the native Windows 10 VPN client
- Cisco Anyconnect: Optimize Anyconnect Split Tunnel for Office365
- Palo Alto GlobalProtect: Optimizing Office 365 Traffic via VPN Split Tunnel Exclude Access Route
- F5 Networks BIG-IP APM: Optimizing Office 365 traffic on Remote Access through VPNs when using BIG-IP APM
- Citrix Gateway: Optimizing Citrix Gateway VPN split tunnel for Office365
- Pulse Secure: VPN Tunneling: How to configure split tunneling to exclude Office365 applications
- Check Point VPN: How to configure Split Tunnel for Office 365 and other SaaS Applications
FAQ
The Microsoft Security Team has published an article that outlines key ways for security professionals and IT can achieve modern security controls in today's unique remote work scenarios. In addition, below are some of the common customer questions and answers on this subject.
How do I stop users accessing other tenants I do not trust where they could exfiltrate data?
The answer is a feature called tenant restrictions. Authentication traffic is not high volume nor especially latency sensitive so can be sent through the VPN solution to the on-premises proxy where the feature is applied. An allow list of trusted tenants is maintained here and if the client attempts to obtain a token to a tenant that is not trusted, the proxy simply denies the request. If the tenant is trusted, then a token is accessible if the user has the right credentials and rights.
So even though a user can make a TCP/UDP connection to the Optimize marked endpoints above, without a valid token to access the tenant in question, they simply cannot log in and access/move any data.
Does this model allow access to consumer services such as personal OneDrive accounts?
No, it does not, the Office 365 endpoints are not the same as the consumer services (Onedrive.live.com as an example) so the split tunnel will not allow a user to directly access consumer services. Traffic to consumer endpoints will continue to use the VPN tunnel and existing policies will continue to apply.
How do I apply DLP and protect my sensitive data when the traffic no longer flows through my on-premises solution?
To help you prevent the accidental disclosure of sensitive information, Office 365 has a rich set of built-in tools. You can use the built-in DLP capabilities of Teams and SharePoint to detect inappropriately stored or shared sensitive information. If part of your remote work strategy involves a bring-your-own-device (BYOD) policy, you can use app-based Conditional Access to prevent sensitive data from being downloaded to users' personal devices
How do I evaluate and maintain control of the user's authentication when they are connecting directly?
Client To Site Vpn Setup
In addition to the tenant restrictions feature noted in Q1, conditional access policies can be applied to dynamically assess the risk of an authentication request and react appropriately. Microsoft recommends the Zero Trust model is implemented over time and we can use Azure AD conditional access policies to maintain control in a mobile and cloud first world. Conditional access policies can be used to make a real-time decision on whether an authentication request is successful based on numerous factors such as:
- Device, is the device known/trusted/Domain joined?
- IP – is the authentication request coming from a known corporate IP address? Or from a country we do not trust?
- Application – Is the user authorized to use this application?
We can then trigger policy such as approve, trigger MFA or block authentication based on these policies.
How do I protect against viruses and malware?
Again, Office 365 provides protection for the Optimize marked endpoints in various layers in the service itself, outlined in this document. As noted, it is vastly more efficient to provide these security elements in the service itself rather than try to do it in line with devices that may not fully understand the protocols/traffic.By default, SharePoint Online automatically scans file uploads for known malware
For the Exchange endpoints listed above, Exchange Online Protection and Microsoft Defender for Office 365 do an excellent job of providing security of the traffic to the service.
Can I send more than just the Optimize traffic direct?
Priority should be given to the Optimize marked endpoints as these will give maximum benefit for a low level of work. However, if you wish, the Allow marked endpoints are required for the service to work and have IP addresses provided for the endpoints that can be used if necessary.
There are also various vendors who offer cloud-based proxy/security solutions called secure web gateways which provide central security, control, and corporate policy application for general web browsing. These solutions can work well in a cloud first world, if highly available, performant, and provisioned close to your users by allowing secure Internet access to be delivered from a cloud-based location close to the user. This removes the need for a hairpin through the VPN/corporate network for general browsing traffic, whilst still allowing central security control.
Even with these solutions in place however, Microsoft still strongly recommends that Optimize marked Office 365 traffic is sent direct to the service.
For guidance on allowing direct access to an Azure Virtual Network, see the article Remote work using Azure VPN Gateway Point-to-site.
Why is port 80 required? Is traffic sent in the clear?
Port 80 is only used for things like redirect to a port 443 session, no customer data is sent or is accessible over port 80. Encryption outlines encryption for data in transit and at rest for Office 365, and Types of traffic outlines how we use SRTP to protect Teams media traffic.
Does this advice apply to users in China using a worldwide instance of Office 365?
No, it does not. The one caveat to the above advice is users in the PRC who are connecting to a worldwide instance of Office 365. Due to the common occurrence of cross border network congestion in the region, direct Internet egress performance can be variable. Most customers in the region operate using a VPN to bring the traffic into the corporate network and utilize their authorized MPLS circuit or similar to egress outside the country via an optimized path. This is outlined further in the article Office 365 performance optimization for China users.
Does split-tunnel configuration work for Teams running in a browser?
Yes it does, via supported browsers, which are listed in Get clients for Microsoft Teams.