** command. Use the question mark todetermine the syntax for your timezone. For example to set the timezone for New York City then use the following: **set system time-zone America/New_York**.
2. Commit the configuration.
3. Verify the new timezone.
4. If the SRX does not have the correct synched time, then use the **run set date ntp** command to initiate the synchronization of time on the SRX.
Repeat the command **run show system uptime** to verify the time synchronization with the SRX. Please contact the
instructor if the issue continues.
SD-Cloud has many templates to set configuration items on the SRX. The next part of the lab configures an
NTP server on the SRX using a template. SD-Cloud provides two methods to create or modify templates.
Configure the NTP template for a single SRX – complete the following:
1. In the SD-Cloud portal navigate to the vSRX – SRX > Device Management > Devices.
2. Click on the link that highlights the vSRX. On the landing page, select the “Configuration Template” tab. The list of templates is displayed.
3. Select the “NTP” option. Click “Configure” button on the top right corner of the page. The Set Configuration Template Parameters window opens.
4. Click the chevron next to the VSRX-NGFW Parameters title. The NTP server list is displayed.
5. Add an NTP server to the list – students’ choice of server.
6. Click the OK button to accept the values. The window closes.
7. The Configuration Template window is displayed. Ensure that NTP is selected. Click the Deploy button. The Deploy window opens.
8. Run now is the default setting. Click the OK button to deploy the template. Observe the Deployment Status for the NTP template to ensure a successful deployment.
Note: An alternate method is to navigate to SRX > Device Management > Configuration Templates. This option applies the template to multiple SRX devices. The student is encouraged to explore this method.
#### Configure SSL Forward-Proxy
To save some time with SSL-FP configuration, we have completed the following stages:
- Loaded the Trusted CA to the SRX.
- Loaded the local certificate/key to the SRX.
- Loaded the certificate to Windows 10 “Trusted Root Certification Authorities” (so you should not get the browser error when SSL-FP is activated)
The additional steps to complete in this section include:
- Configure an SSL proxy profile (called “ssl-ins” profile in SD Cloud)
- Apply it to existing security rule(s)
Note: for your reference, the complete guide for SSL-FP including the preparations steps we have done in advanced, could be found here:
[security-ssl-proxy-forward-reverse-proxy](https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-ssl-proxy-forward-reverse-proxy.html)
[SRX-How-to-configure-SSL-Forward-Proxy-on-SRX-using-J-Web](https://supportportal.juniper.net/s/article/SRX-How-to-configure-SSL-Forward-Proxy-on-SRX-using-J-Web)
To create the decrypt profile, complete the following:
1. Navigate to **SRX > Security Subscription > Decrypt Profiles**, The Decrypt Profiles panel is displayed.
2. Create a new profile – click the “+” button. The Create Decrypt Profile window opens.
3. The parameters to enter are as follows:
- Name it “ssl-ins”
- “Root certificate” to be used is “ssl-inspection”
- Trusted Certificate Authorities set to “All”
4. Click the OK button to add your profile. The window closes.
The next step is to apply the decrypt profile to a security policy. Complete the following:
Navigate to **SRX > Security Policy > SRX Policy**, Select the **vSRX** link. The security policy
page for the device is displayed.
In the Zone section select the chevron for the InterZone:Trust To Untrust (Rule 1). The rules are displayed.
Select the checkbox for the policy named “outbound-traffic”. To edit a rule, you should check box it and hit the
pencil/edit icon (marked in the screenshot below).
To add the ssl-ins profile to the Advanced Security options of the rule: enable “Decrypt” under “Security
Subscriptions”, click the “ **customize** ” option to select the SSL profile. Click “OK” and save the rule by clicking
the “✓” and do not forget to Deploy!
Now, go to the Windows 10 – local user machine and point your Chrome browser to https://www.juniper.net
or any other site. Open the lock icon next to the URL and click on Certificate (Valid) to see the certificate
details – it should show you the SRX certificate you just assigned to your SSL-FP profile, issued by “SRX POC”.
Note: If you see any other certificate, it means the SSL-FP profile was not properly configured, you forgot to assign the profile to the policy, or your traffic flows through a different rule for some reason and you should FW logs and troubleshoot.
#### FW logs and Dashboard
You can view and filter FW logs by going to Monitor> Logs > Session given you have enabled session-
int and session-close options during your FW log creation (already enabled on existing policies). Note the
“group by” option which will allow you to easily find what you are looking for (per policy-name), per event-
name, per nested-application, etc.) you can also sort the list on any column, right-click on a cell to exclude /
filter on its content, etc.
Note: If you can’t see the logs under the expected log category, try the Monitor> Logs > All Security Event view.
Navigate to the Dashboard – explore the content and layout. Modify your widgets as needed. An example of
the SD Cloud Dashboard is next.
#### Update Application Identification Database
Unified policies allow granular control and enforcement of dynamic Layer 7 applications within the security
policy. A proper license and AppID signature database must be updated to allow this capability.
Note: Detailed explanation of the process for installing and verifying licenses AppID: Predefined Application Signatures for Application Identification | Application Security User Guide for Security Devices | Juniper Networks TechLibrary
Go to **SRX > Device Management > Security Packages** to update IPS and ApplD security packages.
You can check the version of AppID (and IDP) by probing your SRX, and only install the security packages if
needed.
This might take few minutes, and you can always check the status by going to **Administration > Jobs** and
check the status:
Alternatively, you can also select the option for auto-update and the signatures will be automatically updated
when new ones are available.
## Lab 1 – Unified Security Policies
Note: Detailed procedure and additional instructions can be found here:
https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/configuring-unified-policies.html
### What are Unified Policies?
Unified policies are the security policies that enable you to use dynamic applications as match conditions as
part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application
changes over time. The use of unified policies keeps the flexibility to have also legacy security policy (L4) when
App ID is not needed.
Note: L4 security policies are prioritized over L7 unified policies. L4 policies are those where dynamic-
application match condition is not configured or set to “none”.
#### Redirect message
Since we want the users to know that their session was intentionally blocked, we will create a blocking
message to be presented in the client browser once a L7 application or URL category has been prohibited.
Go to **Shared Services > Firewall Profiles > Redirect Profiles** and add a redirect text
message of your choice. Click the plus sign +. The Create Redirect Profile window opens.
As an alternative to the custom text message, we could have redirected the browser to a specific URL which displays a message or any other HTML object. You may try redirecting it to https://www.juniper.net for example.
### L7 Applications Rules
Our goal in this section is to block Twitter, YouTube and Facebook Access using dynamic applications as a match condition in the FW rule.
#### Choosing Application Signatures
You can view and search the list of pre-defined supported dynamic applications available from **Shared Services > Objects > Applications**. Use the filter button on the right to locate an application locate the application YouTube. however, if you want to do it off-line you can access our publicly available webpage here: https://threatlabs.juniper.net/signatures/search/#/list/app
#### Blocking Applications
Now, let us go to **SRX > Security Policy > SRX Policy**. The Security Policies pane is displayed. From the displayed list, select the vSRX-NGFW link in the Name column. The vSRX-NGFW pane is displayed. From the Zone rules click the greater-than chevron for the InterZone: Trust to Untrust rule. The rules are displayed. Position the mouse over the rule and use the right click button to display the rule menu. Select the Clone option. A new rule is displayed.
Alternatively, you could create a new rule instead of cloning an existing one
- What is the positioning of the new rule?
- What is the significance of the position of the new rule?
- What is the name of the rule?
- Review the content of the new cloned policy.
Create a new rule with the following:
- Source Zone trust to Destination Zone untrust.
- Applications: choose selected list of apps which you could check later. You MUST use the + button for the list to appear.
**Rule Action:** Redirect the user using the type of URL. Note: the redirect profile option will only be visible after
you change the rule action to “Redirect”.
- Security Subscription: assign the SSL FP profile created earlier.
- Rule options: choose logging of session Initiate so you can see the related applications blocked.
Do not forget to:
- Do not forget to check the ✓ so the rule changes will be saved.
- Do not forget to reorder the rules so the new blocking policy is on top.
- Do not forget to Deploy.
The detailed instructions for editing the cloned rule are next:
- In the name field change the name to **blocklist-APP**.
- Add the required applications for the rule. In the Applications/Services field select the plus sign (+). The Applications & Services window opens.
- Click the Applications slider button – the slider shifts to the right. The Application selection bar opens.
- Select the option named Specific. The Application pane opens.
- Note: which applications are selected by default?
Select the plus sign (+). The Select Application Signatures window opens.
- The applications that the SRX is required to block are as follows: “YouTube”, “Facebook-Access”, and “Twitter”.
Select the applications from the list. Use the filter option to quickly locate the applications.
Click the Okay button to accept the configuration. The Application & Services window closes.
Change the action option to Redirect. In the action field for the rule use the mouse to select the action. The
action drop-down menu is displayed. Select Redirect. The Redirect Options window opens.
Note: When a policy blocks HTTPS traffic with a deny or reject action, SSL proxy decrypts the traffic and application identification functionality identifies the application. Next, you can take action to redirect or drop the traffic as per the configuration.
Do NOT test this yet until you complete the Reordering L4/L7 Rules section below!!!
#### Reordering L4/L7 Rules
Before we test the new rule for blocking apps, note that the existing L4 rule (“outbound-traffic”) takes precedence by default over a L7 rule (“Blocklist-App”) although it is placed below it (therefore the L7 reject rule will not kick in). To change this, make sure the application knob of the outbound-traffic rule is enabled and set to “Any”, so it is now also a L7 rule/ To accomplish this task, complete the following:
- Edit the rule named outbound-traffic. Select the rule – click the checkbox to the left of the rule. Select the edit icon. The rule is now ready for modification.
- In the Applications/Services field select the plus sign (+). The Applications & Services window opens.
- Click the Applications slider button – the slider shifts to the right. The Application selection bar opens.
- Use the selection of Any application.
- Click the OK button to accept the configuration selections. The window closes.
- Check the check mark to the right of the rule (✓ ) to save the rule.
Deploy the rule.
Note: L4 security policies are prioritized over L7 unified policies. L4 policies are those where dynamic application match condition is not configured or set to “none”.
#### Rule-Matching
Note: make sure to clear the cache of your browser or use incognito mode when testing application blocking. This is to avoid a situation where you have accessed the same app (like facebook.com) before and your browser uploads a partial page from cache instead of showing the blocking message.
Now deploy and check the access to the blocked applications from your Win-10 Local User machine – you
should see the reject message appear in your browser!
If things don’t behave as expected, you can monitor the FW logs as detailed in the FW logs section, and you
should see the application blocked on the correct rule.
Also, you can see the traffic hits on the FW policy itself. To make sure the hit count value is updated you can
reset the policy hit value for all rules, test your traffic and then probe for the latest policy hits. See below how
to do it from the **SRX > Security Policy > SRX Policy** section:
Now you can check the hit count value like this:
### Configure a URL Category with Unified Policies
Note: Detailed procedure and additional instructions can be found here: https://www.juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/configuring-unified-policies.html#id-url-category-with-unified-policies
Our goal in this section is to block gaming and gambling site access using URL categories as a match conditionin the unified FW rule.
#### Configure and Test Web-Filtering
First, we need to configure “Juniper Enhanced” web filtering capability. It is an integrated URL filtering solution based on HTTP and the HTTPS requests sent from SRX to Websense ThreatSeeker Cloud (TSC), which in return categorizes the site into one of the 95 or more predefined categories and provides site reputation information. If you want to learn more about this capability refer to: https://www.juniper.net/documentation/us/en/software/junos/utm/topics/topic-map/security-utm-web-filtering.html
Go to **SRX > Security Subscriptions > Content Security > Content Security Profiles**. You can see the pre-defined profiles which include a combination of services.
Note: You can’t edit any of these profiles and will need to clone them and edit the copy if needed.
The “default-utm-policy” (note the name of the profile, as there is another defaultUTMPolicy which we will not use) which we will use, includes a web filtering profile “wf-enhanced-default” which blocks several categories by default.
To view details of the web filtering profile, navigate as can be seen below (no edit is required):
We will now apply the default UTM policy to “global options” under: **SRX > Security Policy > SRX Policy** (both for “Default-security settings” and “Default Security Subscriptions”):
To allow SRX to use URL categorie as a match condition, we must assign the UTM profile to one of the rules, therefore, we will now enable UTM for the exisiting “outbound-traffic” rule:
Deploy and verify that the web filtering server is reachable by SRX. Basically, the Websense cloud service host (rp.cloud.threatseeker.com) should be DNS resolved and accessible from SRX on port 80.
```
admin@vSRX-NGFW> show security utm web-filtering status
```
UTM web-filtering status:
```
Server status: Juniper Enhanced using Websense server UP
```
#### URL Category Match Criteria
Now, let us go to SRX > Security Policy > SRX Policy, and create a rule called **“blocklist-URL”** to
block the required URL categories between **trust** to **untrust** zones.
The details of this rule are listed below:
- Source Zone trust to Destination Zone untrust.
**In the Destinations column enable the URL Category option.** You can now choose from a selected list of URL
categories which you will check later. For example: Gambling and Games.
Note: the search engine in SD Cloud is case sensitive. Search for “Games” and not “games”.
- Applications: Make sure you enable both Applications and Services so the match condition on the rule will
be L7 (based on the URL category).
- Rule Action: Redirect. Note: the redirect profile option will only be visible after you change the rule action
to “Redirect”.
- Security Subscription: enable and assign the SSL FP profile created earlier, by selecting “customize”
- Rule options: choose logging of session Initiate to see the related applications blocked.
Do not forget to reorder the rules so the new blocking policy is on top. You can do it by right clicking the rule
and choosing to move it up / down:
Don’t forget to deploy!
#### Test URL Match Criteria
Now check the access to the blocked URL categories from your Win-10 Local User machine (try for example: https://www.casinoworld.com/ or https://play.bingoblitz.com/). As in the blocking application section, you should see both the reject message appear in your browser and the proper FW logs.
Go to **Monitor > Logs > All Security Events** - you can see in the screenshot below Twitter blocked as well as a gaming site per the configured policy.
Note: you can drag-and-drop to order the columns as I did in this view.
Note: both application and URL match criteria could have been used in the same rule, but we chose to show it
on two different rules for clarity and modularity of this lab.
### Creating Reports
Go to **Monitor > Reports > Report Definitions**, and create a report to be emailed to you.
Note: Make sure you actually run the report after you configure it with your email.
You have completed Lab 1 - well done!
## Lab 2 – User Identity
This section will add the user identity capability using Juniper Identity Management Service (JIMS) - a FREE standalone Windows service application that collects and maintains a large database of user, device, and group information from Active Directory domains. In essence it provides a robust and scalable user identification and IP address mapping implementation to the SRX device, that includes endpoint context and machine ID. JIMS is synced with AD and SRX to maintain the User-Group-IP mapping.
We have already installed JIMS on the AD server of this lab and will use it to communicate with both the AD and the SRX to enable user identity in this lab section.
Go to Microsoft Active Directory VM and open Juniper Identity Management Service (it is pinned to the Taskbar) using the following AD credentials:
- Username: Administrator
- Password: On50qyoKXc (can be copied from AD machine Connection Details in CloudShare)
### User Identity with Juniper Identity Management (JIMS)
This section details the config to support user-identity for AD users. It requires connecting both AD and SRX to the JIMS service by performing the following tasks:
- Configure AD in JIMS – used for user/group mapping.
- Configure event log source – used for user login/logout into AD.
- Connect SRX to JIMS (through SD Cloud)– to populate the SRX authentication-table.
Note: detailed procedure and additional instructions can be found here: _Configure Juniper Identity Management
Service to Obtain User Identity Information - TechLibrary - Juniper Networks https://www.juniper.net/documentation/us/en/software/jims/jims-guide/jims-guide.pdf
#### Configure Active Directory in JIMS
You can configure up to 100 Microsoft Active Directories as user information sources for Juniper Identity Management Service. Luckily, we have only one in this lab...
Select **Data Sources > Info Sources** from the left menu and **add** a new event source entering the following details:
- Description: AD20120.LOC
- AD IP Address: 192.168.1. 100
- Login ID: Administrator
- Password: On50qyoKXc
- SSL connection: keep the default as No
#### Configure Event Log Source
An event log source can be a Microsoft Active Directory domain controller or a Microsoft Exchange server. In our case we will use the AD: select “Data Sources > Event Sources” from the left menu and add a new event source entering the following details:
- Description: AD20120.LOC
- AD IP Address: 192.168.1. 100
- Login ID: Administrator
- Password: On50qyoKXc
#### Connect SRX to JIMS
Select **Clients>SRX Clients** from the left menu and add a new SRX client entering the following details:
- RX IP Address: 192.168.1.253
- Client ID: vSRX
- Client Secret: jnpr123jcl!
- You may also add a description. The rest of the fields can be left as default.
Note: Client ID_ and _Client Secret_ values must match those which you will configure on the SRX.
We will now move to SD Cloud to configure the SRX side. Go to SRX > Identity > JIMS and configure a new profile.
Remember that you must use the same Client ID and Client Secret that you already configured in JIMS:
- Name: JIMS_Server
- Primary JIMS Server IP: 192.168.1.100
- Assign Devices
- Primary Client ID: vSRX
- Primary Client Secret: jnpr123jcl!
- Connection Settings:
- Connection type: HTTPS (default)
- Port: 443 – this is the default configured in JIMS during its installation
- Keep all other fields (also in the next tab) with their default values.
Don’t forget to **deploy** when you are done!
Now test the basic connectivity with JIMS in the following way:
#### Test User Identity
On JIMS side you can see the SRX client statistics, the AD connectivity statistics, and the event source statistics accumulated (with no errors) by checking the “ _Status”_ option on the left side menu:
To check the user-identity mapping, access the “Win10-AD user” machine from the CloudShare portal using the following domain credentials (it should log in automatically if you are using the rdp access method from the CloudShare portal):
- Username: AD2012.LOC\alice
- Password: jnpr123jcl!
The key command on SRX to check whether the authentication table is populated are (you may also see the “Administrator” username as well as “alice” logged-in from different IP addresses):
There is no group mapping in this view since no specific source-identity was configured in the FW policies.
Note: if you cannot see “alice” at all with this command, try to sign out of the Win10–AD User machine, and then refresh the RDP connectivity to force “alice” to login to AD again.
#### Identity-based FW Policy
We will now add a rule named **“Domain_Users”** BEFORE the existing rules from trust to untrust, to allow all services and applications, only if the user is authenticated. This will require choosing the “domain users” group from the source-identity option in the newly created rule. For ease of operation, you may clone the existing **outbound-traffic** rule (right click on it), rename the copy and edit it as required:
- From **trust** zone, source identity address, choose “specific” and then **“authenticated-user”**
- To **untrust** zone destination any
- Services: any
- Action: permit
- Enable logging on the rule option to ease troubleshooting.
Note: you can easily reorder rules as needed by right-click the rule. Make sure this rule is placed BEFORE “outbound-traffic” and deploy.
Now that user identity is configured you may see “alice” listed as the user in the SRX session logs under **Monitor > Logs > Session**:
If you are doing this lab after Lab 1 – Unified Security Policies, you may note the difference between the privileges assigned to Win10 – Local User (blocked applications since it matches the **“blacklist-APP”** rule) and Win10 – AD User (which matches the newly created **“Domain_Users”** rule). Therefore, if you place the rule first, “alice” will be able to access Facebook and games sites from the Win10 – AD User machine, while the Win10 – Local PC access will be blocked.
**You have completed Lab 2 -** Take a few minutes off and continue to the next one!
## Lab 3 – Site to Site VPN
**Onboard Branch SRX**
To configure IPsec VPN from SD Cloud, we first need to onboard another SRX to the setup. and follow these stages (already done earlier in SRX Onboarding) with the vSRX-Branch node:
- Log into SRX directly- this time you may use the vSRX WebUI to on-board the device. Recall the way to access vSRX WebUI directly in the Topology and Connectivity section.
- The credentials for vSRX-Branch are identical to vSRX-NGFW (admin/jnpr123jcl!).
- Find the option on the upper right corner of WebUI to connect it to SD Cloud.
- Use the SD Cloud credentials (email, password, location, org-ID you configured when you created your own account in Access your SD Cloud Demo Account.
Note: the following screenshot is taken from vSRX and NOT SD Cloud! It shows how to on-board SRX to SD
Cloud using WebUI.
- Deploy SRX policy – repeat the steps done when onboarding the vSRX in Lab 0 (manage subscription, deploy NAT policy, deploy FW policy)
- Enable SRX Logging - repeat the steps done when onboarding the vSRX in Lab 0.
- Note : remember you must enable session-init and/or session-close on the FW rule itself (under rule options) in order to see the logs!
**Site-to-site VPN**
Note: Detailed procedure and additional instructions can be found here:_ Create a Site-to-Site VPN | Juniper Networks
The goal of this section is to create a simple, site-to-site VPN allowing traffic from the vSRX-Branch trust zone to access the Webserver located on vSRX-NGFW DMZ zone.
The stages to follow are:
- Preparations
- Create a dedicated VPN Zone on vSRX-NGFW site
- Add the address objects to indicate the protected hosts/networks on both sides
- Create an IPsec tunnel between vSRX-Branch untrust zone to vSRX-NGFW VPN zone.
- Use traffic selectors^1 to permit traffic through a tunnel when the traffic matches a specified pair of local and remote addresses.
- Configure the policies required to control traffic from the Branch to the Webserver on DMZ zone in vSRX- NGFW site.
#### IPsec Preparations
Go to **SRX > Device Management > Devices**, click on the vSRX-NGFW and select the Network Tab. The network settings are displayed. Select the Zones tab. The zone configuration is displayed. Click the + sign in the Zones panel. The Add Security Zone window opens. Create the new zone with the name “VPN”. There is no need to assign any interfaces or change any default settings (and don’t forget to deploy).
We will also create address book entries for the protected resources accessed through the tunnel. Go to **Shared Services > Objects > Addresses** and create a host address entry for Webserver 192.168.1.3/32, and a network address entry for the Branch-Lan subnet 192.168.10.0/24.
The address entries should look like this:
Note: A traffic selector is an agreement between IKE peers to permit traffic through a tunnel if the traffic matches a specified pair of local and remote addresses.
#### Create VPN Tunnel
Go to **SRX > IPsec VPN > IPsec VPNs**, and create a new site-to-site VPN:
- Name: “S2S”
- Add the two devices.
- SRX NGFW w/ external interface ge-0/0/0.0 and tunnel zone VPN protecting WebServer
- SRX branch w/ external interface ge-0/0/0.0 and tunnel zone untrust protecting Branch-LAN subnet.
- Keep all other fields (also in the next tab) with their default values.
Note that traffic selectors are the default routing topology. Once done, don’t forget to save and deploy.
You can view to CLI configuration pushed to each of the two devices before you confirm deployment:
You can also see that traffic selectors modify the routing table on the SRX according to the protected assets you have defined (the example below is for the vSRX-Branch device):
#### Create VPN Polices
Now that we configured the tunnels and allowed connectivity with traffic selectors, we must make sure that traffic can flow through the ruleset.
- For the vSRX Branch device, there is already a rule which supports traffic from trust zone to untrust zone, so no need to add additional rules.
- For the SRX-NGFW device, we need to add a rule to enable http and https from VPN zone (where the st0.0 tunnel interface is located) to the DMZ zone (where the WebServer is located).
- You may choose to allow http and https to the Webserver address object o
You can now access the WebServer from the Branch’s Windows machine called Win10 - Branch: http://vault-tec.org/ or https://192.168.1.3.
Note: you cannot access any other resource on the DMZ since both traffic selectors (routes) and the VPN DMZ policy allow access only to the WebServer.
**Monitoring VPNs**
You may check the tunnel status directly on the SRXs:
```
admin@vSRX-Branch> show security ike security-associations
Index State Initiator Cookie Responder cookie Mode Remote Address
697655 UP cb515cd84a223824 592c10ca57f19a0c IKEv2 10.160.0.253
admin@vSRX-Branch> show security ipsec security-associations
Total active tunnels: 1 Total Ipsec sas: 1
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<67108865 ESP: aes-gcm-256/None 829741a0 expir/ expir - root 500 10.160.0.253
>67108865 ESP: aes-gcm-256/None 5c10ddc3 expir/ expir - root 500 10.160.0.253
```
You can also go to Monitor > Tunnel Status to check that the tunnel is up. Note this view is based on poll interval, so it might take few minutes to show the correct status.
**You have successfully completed this Hands-On Lab!**
## Lab Survey
Please take 2 minutes and complet the [Security Director Cloud Hands-On Lab Survey](https://www.surveymonkey.com/r/TBP7MFX)
