none
Problem with HTTPS blocking

    Question

  • I have a number of different rules which block sites by catagory.  The rules work fine but, I have a strange issue, if people go to a HTTP site that is blocked then they are correctly redirected to the block page we created, if people access a HTTPS site that is blocked they just get a page not found and not the custom block page.  Why is this ? The blocks are on the same rule for HTTP and HTTPS.  They are blocks via URL sets.

    Example

    Action = Deny

    Advanced = Redirect to URL http://block/socialmedia.html

    Protocols = HTTP / HTTPS

    From = Internal

    To = URL Set - Block Social Media ( sites listed in this group are HTTP and HTTPS )

    Users = All Users

    Exceptions = Allowed Access To Social Media

    Wednesday, August 14, 2013 10:26 AM

Answers

All replies

  • Hi

    Based on your description, I think you would like to block  active traffic from client to external website. Please let me know if I misunderstand it.

    Actually, if you only permit common HTTP traffic, you are able to only allow ‘Get’ type HTTP traffic. In other words , you can filter the HTTP traffic except the request method is ‘Get’.

    Please refer to the link to check detailed steps:

    http://technet.microsoft.com/en-us/library/cc995081.aspx
    Thursday, August 15, 2013 1:53 AM
    Moderator
  • Mr_abdi@live.com

    hi

    http://technet.microsoft.com/en-us/library/cc995114.aspx

    Configuring a PPTP Site to Site VPN with TMG 2010

    If you have branch offices, you need VPN. Without VPN it will be hard to do file sharing, policies and other stuff. If TMG 2010 is your way to go for this, then read on. TMG 2010 supports multiple protocols for VPN like, IPsec, L2TP over IPSEC and PPTP. The last one is the simplest type of VPN you can create with TMG, and this is what I’m going to show you in this guide. I’ll take care of the other two in some future articles. I’m going to put my configuration in the table bellow so you can create an image of what’s going on.

    Site A (Main office) Site B (Branch office)
    TMG name: TMG-Site1
    Public IP: 208.67.110.10
    Internal IP: 192.168.100.254/24
    TMG name: TMG-Site2
    Public IP: 208.67.110.11
    Internal IP:  192.168.50.254/24
    Client Site1
    IP: 192.168.100.10/24
    Gateway: 192.168.100.254
    Client Site2
    IP: 192.168.50.10/24
    Gateway: 192.168.50.254/24

    To start we need to make sure we have connection between our TMG 2010 servers; do a PING and see if it responds.

         

    Now open the TMG console from the main office and go to Remote Access Policy (VPN). Here we have a couple of things to set up; first click the Configure Address Assignment Method link so we can set up how TMG will assign IP addresses to VPN clients.

    We can choose to use a DHCP server, or a static IP address pool. Right now I don’t have a DHCP server for this network, so I’m going to choose the static IP address assignment. Click the Add button, select the server from the drop-down-box, then type the IP address range you want to assign to VPN clients. Click OK when you’re done, thenOK again to close the Remote Access Policy (VPN) Properties window.

         

    Back on the TMG console click the Enable VPN Client Access link. If you don’t do it, the other TMG server (branch office) will not be able to connect. Click the Apply button to save the changes to the configuration store.

    Now go to the Remote Sites tab and click the Create VPN Site-to-Site Connection link.

    Give the connection a distinctive name and click Next.

    Choose Point-to-Point Tunneling Protocol (PPTP) and continue the wizard.

    After clicking Next, a pop-up opens telling us that a user account must be present on the system with dial-in permissions and that it needs to have the same name as the site we are creating now.

    Click OK on the message and open Server Manager. Go to the Local Users and Groups section, right-click Usersand choose New User.

    The name of the user must match the name of the site, Site1-to-Site2 in this case. Provide a strong password and check the User cannot change password and Password never expires boxes then click the Create button.

    Open the account properties, go to the Dial-in tab and select the Allow Access radio button under Network Access Permission section.

    Back on the Create Site-to-Site Connection Wizard, type the FQDN or the IP address of the remote site.

    This is a bit misleading, but here we must provide an account name and credentials that exists on the remote site so the connection can be established. Since the TMG server is not part of any domain I will leave the Domain box empty. The account does not exist right now on the other TMG server, but we need to create it. Because I don’t want to have multiples accounts created on a server for one VPN connection I’m going to call this account Site2-to-Site1; this will be the VPN connection name that we are going to create on the branch TMG, later on. You will see when we start configuring the Site2 TMG.

    Log in to the branch office TMG server, open Server Manager and create the user account.

    Click the Add Range button and type the IP address range of the remote site. If you have multiple IP ranges you need to type them all.

         

    If you are using NLB for the remote site type the IP address of the load balancer, if not clear the box and continue the wizard.

    The VPN connection requires a network rule, and here the rule can be created automatically for us. Just click Next to continue.

    Network Access Rule also needs to be created between the site-to-site VPN and the internal network. Most of the times you will allow only the minimum required traffic, but for this example I will allow all the traffic.

    Click Finish to create the site-to-site VPN connection. If a message pops-up that the Routing and Remote Accessservice needs to be restarted, just click OK to continue; but be careful because if you have users connected trough VPN they will be disconnected once the RRAS service restarts.

    Don’t forget to hit the Apply button so changes can be saved in the TMG configuration store.

    The main office TMG is configured. It’s time to go and take care of the branch office server. Everything we’ve done ’till now needs to be done again with some small name and IP changes. Open the Site 2 TMG console and set the address IP assignment first, then enable the VPN client access. The IP address assignment needs to be on a different subnet. When you’re done click the Apply button to save the changes.

    Give the VPN connection a name; I’m going to call this Site2-to-Site1.

    At the Remote Site Gateway page, type the public IP address or FQDN of the TGM from the main office.

    This is where it gets tricky again. I’ve explain it above so I’m not going to review it. The account name (Site1-to-Site2) already exist on the main office because we created it during the VPN connection wizard.

    After you’re done with the wizard, apply the changes to the configuration store then wait a couple of minutes until the connections initialize. Only then the site-to-site VPN connection will work. If you don’t want to wait you can force them by opening the Routing and Remote Access console > Network Interfaces, right-click the VNP interface and choose Connect.

    It’s time to test and see if is really working. From the main office client ping the client from the branch office, and vice versa.

         

    Create a share on one of the clients and access the share from the other side. That should work to, if not it means you did not allow access trough access rules, or the firewall on the client is blocking the traffic.


    Best Regard Mohammad Reza Abdi

    Tuesday, August 20, 2013 4:23 AM
  • Mr_abdi@live.com

    hi

    http://technet.microsoft.com/en-us/library/cc995114.aspx

    Configuring a PPTP Site to Site VPN with TMG 2010

    If you have branch offices, you need VPN. Without VPN it will be hard to do file sharing, policies and other stuff. If TMG 2010 is your way to go for this, then read on. TMG 2010 supports multiple protocols for VPN like, IPsec, L2TP over IPSEC and PPTP. The last one is the simplest type of VPN you can create with TMG, and this is what I’m going to show you in this guide. I’ll take care of the other two in some future articles. I’m going to put my configuration in the table bellow so you can create an image of what’s going on.

    Site A (Main office) Site B (Branch office)
    TMG name: TMG-Site1
    Public IP: 208.67.110.10
    Internal IP: 192.168.100.254/24
    TMG name: TMG-Site2
    Public IP: 208.67.110.11
    Internal IP:  192.168.50.254/24
    Client Site1
    IP: 192.168.100.10/24
    Gateway: 192.168.100.254
    Client Site2
    IP: 192.168.50.10/24
    Gateway: 192.168.50.254/24

    To start we need to make sure we have connection between our TMG 2010 servers; do a PING and see if it responds.

         

    Now open the TMG console from the main office and go to Remote Access Policy (VPN). Here we have a couple of things to set up; first click the Configure Address Assignment Method link so we can set up how TMG will assign IP addresses to VPN clients.

    We can choose to use a DHCP server, or a static IP address pool. Right now I don’t have a DHCP server for this network, so I’m going to choose the static IP address assignment. Click the Add button, select the server from the drop-down-box, then type the IP address range you want to assign to VPN clients. Click OK when you’re done, thenOK again to close the Remote Access Policy (VPN) Properties window.

         

    Back on the TMG console click the Enable VPN Client Access link. If you don’t do it, the other TMG server (branch office) will not be able to connect. Click the Apply button to save the changes to the configuration store.

    Now go to the Remote Sites tab and click the Create VPN Site-to-Site Connection link.

    Give the connection a distinctive name and click Next.

    Choose Point-to-Point Tunneling Protocol (PPTP) and continue the wizard.

    After clicking Next, a pop-up opens telling us that a user account must be present on the system with dial-in permissions and that it needs to have the same name as the site we are creating now.

    Click OK on the message and open Server Manager. Go to the Local Users and Groups section, right-click Usersand choose New User.

    The name of the user must match the name of the site, Site1-to-Site2 in this case. Provide a strong password and check the User cannot change password and Password never expires boxes then click the Create button.

    Open the account properties, go to the Dial-in tab and select the Allow Access radio button under Network Access Permission section.

    Back on the Create Site-to-Site Connection Wizard, type the FQDN or the IP address of the remote site.

    This is a bit misleading, but here we must provide an account name and credentials that exists on the remote site so the connection can be established. Since the TMG server is not part of any domain I will leave the Domain box empty. The account does not exist right now on the other TMG server, but we need to create it. Because I don’t want to have multiples accounts created on a server for one VPN connection I’m going to call this account Site2-to-Site1; this will be the VPN connection name that we are going to create on the branch TMG, later on. You will see when we start configuring the Site2 TMG.

    Log in to the branch office TMG server, open Server Manager and create the user account.

    Click the Add Range button and type the IP address range of the remote site. If you have multiple IP ranges you need to type them all.

         

    If you are using NLB for the remote site type the IP address of the load balancer, if not clear the box and continue the wizard.

    The VPN connection requires a network rule, and here the rule can be created automatically for us. Just click Next to continue.

    Network Access Rule also needs to be created between the site-to-site VPN and the internal network. Most of the times you will allow only the minimum required traffic, but for this example I will allow all the traffic.

    Click Finish to create the site-to-site VPN connection. If a message pops-up that the Routing and Remote Accessservice needs to be restarted, just click OK to continue; but be careful because if you have users connected trough VPN they will be disconnected once the RRAS service restarts.

    Don’t forget to hit the Apply button so changes can be saved in the TMG configuration store.

    The main office TMG is configured. It’s time to go and take care of the branch office server. Everything we’ve done ’till now needs to be done again with some small name and IP changes. Open the Site 2 TMG console and set the address IP assignment first, then enable the VPN client access. The IP address assignment needs to be on a different subnet. When you’re done click the Apply button to save the changes.

    Give the VPN connection a name; I’m going to call this Site2-to-Site1.

    At the Remote Site Gateway page, type the public IP address or FQDN of the TGM from the main office.

    This is where it gets tricky again. I’ve explain it above so I’m not going to review it. The account name (Site1-to-Site2) already exist on the main office because we created it during the VPN connection wizard.

    After you’re done with the wizard, apply the changes to the configuration store then wait a couple of minutes until the connections initialize. Only then the site-to-site VPN connection will work. If you don’t want to wait you can force them by opening the Routing and Remote Access console > Network Interfaces, right-click the VNP interface and choose Connect.

    It’s time to test and see if is really working. From the main office client ping the client from the branch office, and vice versa.

         

    Create a share on one of the clients and access the share from the other side. That should work to, if not it means you did not allow access trough access rules, or the firewall on the client is blocking the traffic.


    Best Regard Mohammad Reza Abdi

    Tuesday, August 20, 2013 4:24 AM
  • The post by Ehtisham would be ideal but we dont have a licence for URL Filtering, it has now expired.  So I wonder, if anyone can explain why I cant display a block page for https but can for http traffic on the rule ?

    Thanks.

    Tuesday, August 20, 2013 8:43 AM
  • A Quick guess is that in newer browsers, it's not allowed to be redirected from a https to a http site. IE7 and later has this limitation built in to prevent hijacking and other pesky attacks.

    Have you tried to make the block page available on https? I'm not sure if it works, but it's worth a try. Unfortunately, I believe url redirections are also blocked when on https.

    HTH

    Patric

    Tuesday, August 20, 2013 12:36 PM
  • Hi Patric

    Good point, I will recreate a test block page on HTTPS and see if it works or not.  Will update this post once I have tested this.

    Duncan

    Tuesday, August 20, 2013 3:19 PM
  • Hi Duncan,

    Please, find the answer and solution to your question http://msdn.microsoft.com/en-us/magazine/dd565641(VS.85).aspx. As Patric mentioned, it's about IE and not TMG.

    Tuesday, August 20, 2013 7:44 PM