This topic has 2 replies, 2 voices, and was last updated 8 months, 3 weeks ago by mockykid.
-
AuthorPosts
-
October 1, 2021 at 3:01 am #28711
mockykid
ParticipantI have successfully deployed ForgeRock (CDK) on Azure and have enabled the RADIUS server per the instructions HERE. That was the easy part…
I now can’t figure out how to test this and where to send my RADIUS requests (udp/1812) so that it actually hits the AM RADIUS service? Is there any documented procedure or script to configure this? Can I modify the same ingress gateway (and leverage the same externally accessible DNS alias) or do I need to set up a new public IP for this use case?
Thanks in advance for any guidance…note that this is for lab testing only at this stage so any “quick hacks” are extremely welcome. :)
October 5, 2021 at 8:43 pm #28713Warren Strange
ParticipantYou will want to create a Kubernetes service of type “LoadBalancer” that targets the AM backend/port. This will give you an external TCP IP address that routes all TCP (including UDP) to that AM port.
https://kubernetes.io/docs/concepts/services-networking/service/
October 7, 2021 at 7:29 am #28714mockykid
ParticipantThanks!!! This helped immensely – I created a Kubernetes “LoadBalancer” service for RADIUS on udp/1812 and all looks good on the Azure side (public IP and ingress forwarding rule as expected), and on the Kubernetes the service correctly points to the backend AM port. A single command appeared to have resolved this!!!
Having said that – my RADIUS requests are timing out with no response from the server…
Where do I enable and access the RADIUS debugging logs on the AM server, and how do I map RADIUS requests to a specific journey that I’ve configured in the ForgeRock GUI?
-
AuthorPosts
You must be logged in to reply to this topic.