• State Not Answered
  • Replies replies
    2
  • Subscribers subscribers
    25
  • Views views
    171
  • Users 0 members are here
  • Locked Locked
Related
Options
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

ID-provider ports shennanigans

MigrationDeletedUser

Hi all,
I have a weird issues with the id-provider. We want to use it to create
unique numbers for the userapp. Everything works nicely in the dev
environment but in acceptation we are running into network issues
because the uapp is running in a seperate LAN. I used wireshark on both
ends to see what is happening and this is it:

1. UAPP requests on tcp 1199 from random port - Firewall OK
2. IDV replies from tcp 1199 to that port - Firewall OK
3. A new stream is opened from the IDV to Uapp on port 56995 - Firewall
Blocks
4. I get -1:(

I see nothing about this in the documentation but I did find some people
with the same problem so I thought I'd try and get to the bottom of it.

I have some questions:
1. What is the best way to solve this.
2. Is there a set range of ports for the RMI traffic?
3. Can you lock it down to a certain range?

Regards,

Albert-Jan Stevens


--
ajstevens
------------------------------------------------------------------------
ajstevens's Profile: https://forums.netiq.com/member.php?userid=3153
View this thread: https://forums.netiq.com/showthread.php?t=53205

  • 0
    The RMI stuff is documented on Java's site if you want details, but
    basically RMI, like RPC and FTP data and other protocols, arranges for an
    alternate port to be used for the real work, and that is now an option as
    well using the latest shim and packages, documented as shown below:

    https://www.netiq.com/documentation/idm45drivers/idprovider/data/b4dd0y2.html

    RMI Service port: The TCP port for the RMI ID Provider service. The server
    uses an ephemeral port if the value of this parameter is zero.

    By default you get ephemeral (high, dynamic) ports for things as you
    witnessed, so the workaround there is either to have a really smart
    firewall, or just to open those really high ports (usually 32768 to 65535
    or so) so that, when listening, things work. Thankfully NetIQ provided an
    option here, so as long as you only have the one request at a time
    (usually a safe-enough assumption considering how quickly these
    transactions happen) you're just fine.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • 0 in reply to MigrationDeletedUser

    Ah so that's where that setting is for!

    Ok I will use that option, I already have code in place to handle
    failures so that should hopefully handle incidents during the go-live.
    Thank's for the tip and response.

    Regards,

    Albert-Jan


    --
    ajstevens
    ------------------------------------------------------------------------
    ajstevens's Profile: https://forums.netiq.com/member.php?userid=3153
    View this thread: https://forums.netiq.com/showthread.php?t=53205

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.