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.

  • I don't recall the exact message returned by Tortoise, it takes some work to connect from outside so I will have to check back. I am certain it's the WebDAV extensions that you are talking about. I was hoping someone could point me to a reliable tutorial on the topic I could send to the network team. And for the policy, we all agree with you, but we rely on having a good relationship with the network guys. So the risk vs. reward ratio is too great for us to try that! :-) – Robert Kaucher Jul 14 '11 at 18:01
  • 1
    Fair enough! A tutorial's tough, since this stuff is allowed by default; the block would have been intentional (or copy-pasted from somewhere that did it intentionally). The config you'll need to have them look for will be something along the lines of a <Limit> or <LimitExcept> block modifying permissions, or a RewriteRule with {REQUEST_METHOD} as a condition. – Shane Madden Jul 14 '11 at 18:22
  • Got it! Thank you for that final comment. I will post back if this is ever resolved. – Robert Kaucher Jul 18 '11 at 19:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.