Troubleshooting

Contacting IBKR support

When contacting IBKR support make sure your ticket doesn't include any executable code, such as curl commands. These seem to be silently flagged as dangerous by their website client and will not be submitted.

Access Denied.

Access Denied. is a cryptic message that Gateway sends when it receives a request from an IP address it doesn't allow requests from. To fix it specify your client's IP address in the conf.yaml under ips/allow and ensure your IP is not listed in ips/deny.

Eg.:

ips:
  allow:
    10.148.0.0
    10.149.*

Learn how to provide IBeam with a custom conf.yaml in Gateway Configuration section.

This error can also appear when communicating with a locally running IBeam image using 'localhost' as the hostname of your request. To fix this, ensure 172.17.0.* is listed in the ips/allow. See #15 for more.

Hostname X doesn't match Y

This should only appear if you use your own TLS certificates. It means your certificate was created without specifying the client host IP or DNS you're trying to communicate from. You will need to recreate your certificates including the IP or DNS of the machine you're communicating from.

See the optional SAN specification in Step 1 of either Keytool or OpenSSL certificate generation.

Invalid username password combination

There are some indications that the IP location from which you are attempting to log in may define whether this error could appear. Some users have observed that using a VPN can help with this issue.

See https://github.com/Voyz/ibeam/issues/100 for more.

Authentication loop

Ie. IBeam keeps on re-authenticating over and over again. See https://github.com/Voyz/ibeam/issues/152.

As much as I'd like to suggest a fix, this authentication loop doesn't seem to be something that is in our control. Ever since I remember IBKR servers will just sporadically refuse to allow you to authenticate successfully over a large period of time despite successfully completing the authentication flow, and cause IBeam to get into this loop.

Remember that what happens is:

1. IBeam notices we don't have an authenticated session, ie. the /tickle response reports authenticated:false. There seem to be a number of reasons for this, such as: fresh startup, conflicting session, IBKR servers restart, etc.
2. We attempt to reauthenticate. In Strategy A it means a full re-login, in Strategy B it means attempting to reauthenticate for a number of times before killing the Gateway and reattempting the login. (see #147 for more info on strategies)
3. We do this until we succeed, indicated by the login website displaying Client login succeeds. The interpretation we go with is that IBKR server has accepted our authentication flow and our session should be authenticated, yet:
4. /tickle response still reports authenticated:false

And so we're back where we started and we end up with the famous authentication loop.

What we've observed so far is:

1. There isn't any obvious fix for this. Different users suggested a variety of methods, involving calling various endpoints or adding sleep periods in order to break the loop. There's been reports of these working for some users, unfortunately, none is a definitive winner. I implement most of the ideas that are suggested in order to try them out, however there hasn't been a significant breakthrough yet.
2. IBKR doesn't seem to want to acknowledge that it is happening and provide support to solve this. We've been letting them know for a couple of years already. We shouldn't assume malice or negligence on their side, however also we shouldn't exclude the possibility that they dislike the fact that some users automate the authentication which was intended to be executed manually, and hence refuse to address this issue. The best I can do is to ask every user to submit tickets describing this issue.
3. There is no clear pattern on when and why this happens. Sometimes it works, sometimes it breaks for hours. There's a good amount of reports that start along the lines of 'It's been working fine for months and then one day...'.
4. Changing your server's location (eg. using VPN) or manually wrangling conf.yaml file to call a different server may help.

Honestly, this, along with other IBKR-side issues (eg. 'Invalid username and password' error) is what keeps me from upgrading IBeam to version 1.0.0, despite it being used in production by various users. I think everyone here should be aware that until the service is reliable, we're using this system acknowledging that there are and will be long and unexpected drops in connectivity to the broker. There's a good chance that for you it will work for months on end without interruption. There's a good chance that for you it will break every other day.

Best we can do is to:

1. Speak to IBKR about this as much as possible and hope one day they'll help. Every support ticket counts, so let them know if you haven't, but especially if you're a whale, or an institution, or have some connections: please try pulling some ropes to get more attention to this.
2. Try out various methods of getting over this issue and hope one of them will actually solve it. Feel free to experiment - add timeouts, call different endpoints, wrangle servers, change your IP, etc. - and report back here.

Paper Account

From: https://github.com/Voyz/ibeam/issues/152#issuecomment-2065027874 thanks to @dabrazhe

Every Live account can have a linked paper account. Only one paper account is allowed, it’s their tech limitation. If your Live account is approved you can leave it non-funded, and open the linked paper one.