@zach The latest update in 1.32.3498.90 for the user-agent is awesome. Thank you!
It looks like the x-forwarded-for address if pulling a variable called remote_ip defined in authorizer.py perhaps. With our server hosted in AWS us-west-2 (oregon) the location in the Okta Push is misleading. Is it possible to update this value to be the requesting users public IP?
The remote IP is set to the clients IP address. If a load balancer is used the load balancing documentation has information on using the load balancer forwarded address.
Hey @zach – We don’t use a load balancer but it seems like the IP in the connection log is correct, but that is not what is passed to the api call in okta.py.
In my screenshot, The greyed out section is my actual IP:
But when I initiate the push it shows a different IP/location.
I can verify that this works by manually making an API call to okta verify push. If I set that 63.81... address in the X-Forwarded-For, it sets the correct location.
A lot of connection methods will use HTTPS requests before the OpenVPN connection such as single sign-on connection authentication. The IP address would be obtained from that request not the VPN connection.
Got it. So is there anything I can do here to update that value?
I will try reproducing the issue. I believe the header stopped working a while ago. You can try editing /usr/lib/pritunl/lib/python3.8/site-packages/pritunl/sso/okta.py and modifying the header to verify it isn’t an issue with sending the wrong address.
Thanks @zach this is interesting. When I go into that py file and add 'X-Forwarded-For': '63.81.xx.xx' restart the service, it doesn’t pick it up and still uses the Oregon IP.
When you are making the API call manually that is likely using the IP address of that computer. The issue will likely need to be fixed by Okta to use the header.
Try adding pritunl public IP as a Trusted proxy IPs in Okta admin settings:
Okta → Security → Networks
This does work well for us.
thanks for the tip!