Issue:
When clicking on a link which is external on a OWA session which is published via web resource, the browser just times out saying "Cannot access the Web Site. Please check your proxy settings. Made http request for GET / HTTP/1.1 to xxx.xxx.xxx. The URL entered is incorrect or the Web site is not accissible"
Port 80 is open going to the internal network. DNS works ok because of SAM working and the SAM client being able to resolve. No proxy settings are set on the browser so it cant be that. I am not sure how the box will route the traffic.
I have had a quick look at this, and I may be wrong in this, but it looks like the 4500 is trying to make the request and not sure how to get out to an external link. If trying to click on an external link causes this effect, then whats the best place to start looking at this? Or what is the default behavior of the box when trying to make this kind of request?
I have looked at policy based routing, and im sure that this is not the reason why its not working and ill keep looking to find out what else it is.
I have not got around to doing some tracing yet that my next step to find the path its taking, but I could do with cloning myself about 7 times to I have time to sit down and look at this.
Thank you
Solved! Go to Solution.
Solved this at last, after looking at it today.
Basically, the path of the packets have to go from the internal interface, to the internal network and then back out again. We have multiple firewalls which allowing the VPN clients to connect to specific hosts.
When trying to access www.google.com, the firewalls treat this as another network which the vpn is trying to access, so it will allow/deny access to this site on the firewall.
Adding in http from the juniper vpn to allow on port 80 for all sites fixed the issue
Given that you are using web access, when a user clicks on a link within an OWA email (example http://www.juniper.net ) the traffic flow will be:
Client PC < > SA External interface < > SA Internal Interface < > External Webserver (www.juniper.net)
Check the connectivity between internal interface of the SA 4500 and the external webserver.
I did a little bit of work on this.
Our clients can access the net at the moment without a proxy on because this is on a trial basis. So if i plug my laptop in, the routes take me out on the internet via our firewall. The gateway I use is exactly the same gateway which the VPN's internet NIC can see.
When I do a packet trace from the VPN, I can see the box connect to DNS, resolve the IP. It then sends a SYN to the IP, with the next hop as the gateway. However, nothing happens to the packet. It just tries to SYN, SYN, SYN and then will time out.
Again, I could do with more time to look at this, but I will look again with using proxy and see if that behaves the same way.
Solved this at last, after looking at it today.
Basically, the path of the packets have to go from the internal interface, to the internal network and then back out again. We have multiple firewalls which allowing the VPN clients to connect to specific hosts.
When trying to access www.google.com, the firewalls treat this as another network which the vpn is trying to access, so it will allow/deny access to this site on the firewall.
Adding in http from the juniper vpn to allow on port 80 for all sites fixed the issue
I'm having the same issue, the problem is :
1.while OWA is published with SA i cannot access internal or external links within the emails
2.when using WSAM to use outlook i cannot access internal or external links within the emails
The First thing you need to make sure of is that DNS is working. This is the first thing which I looked at, because the timeout could have been a DNS problem.
Just configure your DNS in the nework overview page. Also put in a hostname of your appliance which can be resolved both internally and externally. Then, on your internal firewall, open up and NAT udp/tcp 53 for DNS. Then on your internal firewall, open up http and https from the juniper physical and virtual interfaces if you have a cluster setup. Make sure you open up http and https for all destinations.
Next, from the box, make sure you can lookup hostnames. Goto the Troubleshooting/tools/commands section and run a ping to www.google.com or something. This should do an external lookup with the IP address. Dont worry about if the ping does not get back, so long as it does a DNS lookup with an external address, then this is working.
If it does not do a dns lookup, then you have a dns problem, and I suggest why it is not looking up DNS.
If it does a DNS lookup, and you just timeout on web pages, then its a firewall rule problem. Remember, the internal interface of the SA to a firewall will be treated like any other clien trying to get internet access to certain sites via a firewall. If you deny everything from the juniper box, to the internal network, apart from certain ip addresses, then your web sites are not going to work. You need to allow http/https - juniper internal interface > any.
Hey Guys,
Can you help me with the solution that will meet the underlisted requirements:
Minimal requirement for to meet the deadline is for Forefront TMG to be able to publish the CAS server for web access to email, and also SMTP (depends if this is preffered option)
However in the broader picture, here is the list of what is expected of the Forefront TMG to do in the larger scope of this project, as we hope to offer users more options for accessing their mailboxes.
1. Publish Microsoft Office Outlook Web App using forms-based authentication
2. Publish Outlook Anywhere using Basic or NTLM authentication.
3. Publish Microsoft Exchange ActiveSync using Basic authentication
4. Provide load balancing for HTTP-based protocol accessing from the Internet.
5. Support two-factor authentication for Outlook Web App.
6. Support two-factor authentication for Exchange ActiveSync
7. Provide certificate-based authentication for Exchange ActiveSync, Outlook Web App.
8. Perform mail hygiene for Exchange with installation of Microsoft Forefront Protection 2010 for Exchange Server
let me know how the SSL can achieve this.
Thanks