It's all about the answers!

Ask a question

A tweak on the Eclipse-based client to go through the firewall to RTC server ? How to unblock client access through the TMG?

long TRUONG (3654121147) | asked Mar 25 '15, 11:06 p.m.
edited Jul 23 '15, 7:16 p.m.
 We are on Windows RTC/RRC 4.0.6.

Thus far, we have external users who use Eclipse client with a different URI (than the one we use internally), tweaked so that they can go through the firewall opening to access the RTC.

As we are about to upgrade to 5.0.2, hence 3.x clients will no longer work, we are pushing 4.0.6 Eclipse clients out to these external users in preparation for the upgrade.

They can no longer access the RTC through the firewall with 4.0.6 clients, though their clients still work. The 4.0.6 clients can access, successfully, RTC internal to them.  Needless to say 4.0.6 clients can access our RTC remotely from our issued laptop via our VPN.

Any thoughts? 
  • If the firewall tweak is actually in the configs of clients, which need to be transferred to 4.0.6 clients. If so, how ?
  • Or the tweak, actually is in the firewall, but specific to to clients.

Donald Nong commented Mar 26 '15, 5:15 a.m.

I wonder whether the "firewall" is actually a "proxy". If so, it should be something like this:
If it's indeed a firewall, check with your network administrator.

long TRUONG commented Mar 26 '15, 5:57 p.m.

Thx Ralph / Thx Don,

Was told "we have a Threat Management Gateway (TMG), which essentially proxies for us.  The certificate exists there". External users actually use the URL to this TMG in the Eclipse clients. The TMG redirect the traffic to the RTC real URL.

Current network team now don't know any more than us about this setup. We are puzzled  as the tracert went through several last timed out hops to the TMG, how do the traffic reach the TMG.

2 answers

permanent link
Ralph Schoon (63.3k33646) | answered Mar 26 '15, 3:24 a.m.
Try to read your question, assuming you don't know details. Would you be able to help?

Absent more information the Eclipse client provides Preferences in Window>Preferences, Category General>Network connection, where you can manage how to access the network.

I would suggest to work with support to figure out what your problem is.

long TRUONG commented Mar 31 '15, 11:25 p.m.

Ralph, This is our latest guess along the line of your suggestion: 

Open client/Select “Window –> Preferences”/Preferences box prompt out/expand General/Choose “Network Connections”

A window should pop up similar to the OOTB one shown below. 

Eclipse Config

Default OOTB is Native with HTTP, yet proxy URL in use had been https://<proxyServer>/ccm/ 

Hence must have been configured to HTTPS. If it is indeed so, i.e. HTTPS is ticked in manual mode, 

then edit the HTTPS line and copy all configured items over to correspondent fields on 4.0.6 client, 

of course switch to manual (from default OOTB native) mode first

long TRUONG commented Apr 01 '15, 4:15 p.m.

 NO dice. There was no configuration on the old client, Not only that, the preferences window does not show the Native config line like the client on our site, the same client unzipped from a common zip:


Ralph Schoon commented Apr 02 '15, 2:55 a.m.

If there was no configuration in Eclipse, was there one in the Internet Explorer? I am not sure how we can help here. You might want to contact support.

long TRUONG commented Apr 08 '15, 12:17 a.m.

We have contacted support escalated to SWAT after confirming to support that their suspicion of our TMG blocking high-bit was right on.

We have, however, discovered that 4.0 Eclipse client would work too: and neither or 4.0 clients have a 64-bit version while there is one for 4.0.6, and which we used, running into this issue.

We are hypothesizing that the 64-bit version of the client is using 64-bit encryption that uses high-bit, in turn blocked from our TMG. Our test with 32-bit 4.0.6 client will tell.

The obvious errors with a 64-bit 4.0.6 client are from logging in to the repo connection to the proxy/TMG with below message: But no Denied entry was found in TMG log for the testing period, only Failed (besides Allowed) with a request URL not consistent with logins.
error logging in to proxy repo connection

permanent link
long TRUONG (3654121147) | answered Jul 23 '15, 6:48 p.m.
 Below is the right answer, but it does bring more question(s).

IBM had turned to URL double encoding, starting with Eclipse client 4.0.3, to fix Defect 251859, found in 4.0.1: and our TMG is blocking double encoded URL (with option "Verify Normalization" turned on). Both this option and high-bit blocking option can just be on or off systemwide, it cannot be configured to individual app access.

This dead end (our security team would not turn off this option for everyone to accomodate our team & app) bring more questions:
  • Is there another way for our external (& offshore) customers to access CLM through the firewall ?
  • Does IBM need to turn to URL double encoding, increasing security risk:
    • to deal with "Error: Invalid URI encountered when uri contains user with a space in their login name (as an approver)"
    • which only happens in limited circumstances; instead of just either disallow blank in  login name or offer a different fix which is of limited scope and affecting less of other normal use of the RTC.
    • Also, why it has to be full URL double encoding when the URL only needs to go through a second pass of encoding only unencoded blanks.

long TRUONG commented Jul 23 '15, 7:19 p.m.

 We are now on RTC 5.0.2 (still works with 4.0 client), and this issue is blocking any thoughts of going to 6.x

Ralph Schoon commented Jul 24 '15, 3:26 a.m.

Did you ever consider to open a PMR with support?

long TRUONG commented Jul 24 '15, 8:10 p.m. | edited Jul 24 '15, 8:11 p.m.


The results presented on this answer, and also the dead end, are the fruits of the long running [PMR 07202,49R,000] : Problems connecting Eclipse through TMG.

IBM support going only as far as identifying the URL double encoding blocking, and offering the advice to turn it off. They contended they cannot advise on MS products (TMG or IIS), when we are looking for infos for our security team to find an alternate solution.

Also our discussions on the necessity of turning to full double encoding did not seem to generate any possibility.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.