This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Can't checkout SVN repository over VPN

We recently deployed the XG 135 and this morning I encountered an error when checking out an SVN repository when connected to VPN (same with both IPsec and SSL VPN).

The SVN repository in question has external repositories defined, so when you check it out it will in turn checkout other child repositories. The SVN checkout succeeds until it reaches these externals, which fail with the message "Error running context: An existing connection was forcibly closed by the remote host". I tried the same thing on a PC connected to the internal network and it checked out successfully.

Looking at the firewall log for my IP I can see corresponding "Could not associate packet to any connection" errors for each external checkout failure for src port 80 and destination port 65258.

We have VPN to LAN firewall rules defined for both IPsec and SSL VPN. I tried creating a rule in the opposite direction, LAN to VPN but this made no difference.

Finally I discovered that the external repositories are defined as HTTP URLs, and the problem happens if I checkout any repository over HTTP rather than HTTPS, not just repositories with SVN externals. When I change it to HTTPS I don't have any problems. I would like to understand what is causing this, and why it only happens over VPN.



This thread was automatically locked due to age.
Parents Reply
  • Hi Emmanuel,

    Thank you for the information. It sounds like this option is enabled for good reason by default so I'd rather not disable it if we can avoid it.

    In case it helps anyone else, I have a workaround for the SVN externals problem. We were explicitly specifying the externals with the http:// protocol although we normally use https:// for the main checkout. It is possible to omit the protocol and simply start the externals with // and then SVN will use the same protocol as the overall checkout. This is good practice as it is generic in case protocols change in future.

    Thanks,

    Alan

Children
No Data