We are having issues publishing a Windows based VisualSVN Server via an Appache mod_proxy.
Company IS policy does not allow SSL connections to be initiated from external networks and enter into the company network unterminated. To allow SSL connections to be initiated by external parties they use an Apache mod_proxy that accept the SSL connection transforms it to another protocol such as HTTP and then forwards it to the appropriate internal resource. This service runs as a proxy for all externally published resources so is quite sensitive for both security and availability. What we are seeing from the perspective of our team is that our infrastructure for publishing this service is working 100%. We are able to simulate external connections coming to the server and all data is being returned and function as expected with either Internet Explorer or repo browsing tools like TortoiseSVN.
The issue seems to be in the mod_proxy mentioned earlier; run by the network team. Simple HTTP connections to the SVN server work brilliantly. However, as soon as we attempt to use tools that require extensions to the HTTP protocol (TortoiseSVN for example) everything breaks down. WireShark reveals that the protocol being used is HTTP/XML and that the requests for the resources are not hitting the VisualSVN server at all.
Does anyone know if there are special configuration options needed to get mod_proxy to work with WebDAV tools like TortoiseSVN?
Here is what happenswhen browising via IE:
SSL Connetctopn initiated on client ---> mod_proxy -- transforms request to port 80 --> ISA Server 2006 --> VisualSVN Returns web Page
Works like a charm.
Here is what we see when we try to browse using Tortoise:
SSL connection initiated on client ---> mod_proxy no packects sent to ISA Server
WebDAV uses a number of HTTP methods that are outside the scope of what you'd see in normal web traffic, but aren't being used by your IE connection. My guess? Some or all of those methods are blocked in the proxy server.
What response gets sent back to Tortoise (should be displayed in the error message, as well as what exact method failed; probably
PROPFIND)? My money's on a 403.By the way, tell whoever came up with that policy that unencrypting all the sessions internally is doing it wrong; if they need to monitor the plaintext traffic that badly, they can give a monitoring device a copy of the relevant private keys without compromising the end-to-end integrity of the connection. Attackers don't just come from outside.