Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- From: Peter-Paul <PeterPaul@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 14 Aug 2008 09:38:00 -0700
Phillip,
Thank you for your reply, the issue is that we are using the FQDN as the
name for the application, the actual url used is
http://wbcoda1.mab.intra/icorpnet/timeclaimWeek.aspx?week=200833.
The browser has a proxy deny rule to point allow all mab.intra traffic to go
directly, bypassing the proxy. Even turning off the proxy in the browser or
the proxy service on ISA doesn't help. The domain is also configured to
bypass the proxy within the ISA server.
This also goes for the ip ranges.
"Phillip Windell" wrote:
You have to separate in you mind the concept of the VPN -vs- the Internet.
Traffic even though they both use the ISA and even though the VPN works over
the Internet.
Everything that works over the VPN is private *local* traffic. Geography is
irrelevant.
Therefore you have to make sure that everything that happens with that Web
Application has to be properly treated as local private traffic on the LAN.
Your problem "element" needs to be examined in detail to make sure that
everything involving it and the Client using it must be treated a local
traffic. It appearantly is not,...if you look at the Log entries you posted
you will see that the Web Proxy is involved,...but it should not be
involved.
I see one problem right off the top. It is using http://10.10.3.9 . Well,
never ever ever ever use IP# in links in websites. IP# have "dots" in
them,...this causes them to be interpreted [incorrectly] by Internet
Explorer as FQDNs,...and all FQDNs are treated by Internet Explorer as
Internet Locations and it will *blindly* send them to the proxy if IE
posseses proxy settings,...but if IE does not have proxy settings this does
not occur. Using IP#s in URLs does *not* simplify things as most people
think,...it makes things *more* undependable and unpredictable. You can
verify this be removing all proxy settings from IE and then try the Web
Application again.
There are measures to deal with it, and there is at least one article
explaining how to deal with it,..but the best thing is to not create the
situation in the first place. Use *names* in the URLs that consistantly and
dependably resolve to the correct address. You also need to make sure that
all Domain Names used on the LAN are correctly configured into the correct
Network Definitions. The same has to be true for what might be used in any
Absolute Links (as opposed to Relative Links) that are embedded into the
Site.
There may be other things to consider but this is the best I know to do for
the moment.
--
Phillip Windell
www.wandtv.com
The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------
Technet Library
ISA2004
http://technet.microsoft.com/en-us/library/cc302436(TechNet.10).aspx
ISA2006
http://technet.microsoft.com/en-us/library/bb898433(TechNet.10).aspx
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html
Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/download/9/1/8/918ed2d3-71d0-40ed-8e6d-fd6eeb6cfa07/ts_rules.doc
Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.mspx
Microsoft ISA Server Partners: Partner Hardware Solutions
http://www.microsoft.com/forefront/edgesecurity/partners/hardwarepartners.mspx
-----------------------------------------------------
"Peter-Paul" <PeterPaul@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7F8858D9-3B17-48C8-AA9F-388C22797C1D@xxxxxxxxxxxxxxxx
We are experiencing some strange behaviour with a web based application
for
our users in the Branch office site.
The branch site is connected using a ISA to ISA site to site VPN and there
is a firewall rule applied which allows ALL traffic to pass in both
directions. The network policy is set to route the traffic.
From a VPN site the behaviour we are seeing is:
We open the web application: http://server/app.
We receive the application login form and continue to login.
The application opens and we can browse most ellements.
When we try to use a specific element the client receives the following
message:
Error Code 64: Host not available
Background: The gateway or proxy server lost connection to the Web server
When I review ISA monitoring logs at the branchsite I see the same error.
When I review the ISA logs at the HQ site I see:
Log type: Web Proxy (Forward)
Status: 0xc0040001 FWX_E_TERMINATING
Rule: VPN to Den Haag
Source: VPNFR ( 192.168.254.3:0)
Destination: Internal (APPServer 10.10.3.9:80)
Request: GET http://10.10.3.9/app/timeclaimWeek.aspx?week=200833
Filter information: Req ID: 0d69305d; Compression:None
Protocol: http
User: anonymous
Additional information
Client agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Object source: Internet Processing time: 110
Cache info: 0x41040010 MIME type:
The web application works well for all users within the HQ site, however
when it passes the ISA FW it stops working.
- Follow-Ups:
- Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- From: Phillip Windell
- Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- From: Phillip Windell
- Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- References:
- Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- From: Peter-Paul
- Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- From: Phillip Windell
- Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- Prev by Date: Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- Next by Date: Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- Previous by thread: Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- Next by thread: Re: Site2Site VPN - Web page requests returns FWX_E_TERMINATING
- Index(es):
Relevant Pages
|