My setup involves a public IP address (18.104.22.168) that resides on the firewall, NAT'ed to a private IP address (10.0.0.6).
It seems that ldap-proxy cannot bind to the IP address because it doesn't reside on the server. Which makes sense.
We'd need to either change the binding to 0.0.0.0 (all IP addresses) or to specify the private IP address in the JSS when configuring.
Here's the tutorial I used:
Error I have:
2016-08-30 14:43:16,834 INFO c.j.j.l.LpsServerSocketListener [lps: /22.214.171.124:31337 (ssl)] Sleeping for 5000 ms before retry of server socket bind for address /126.96.36.199:31337 2016-08-30 14:43:21,835 INFO c.j.j.l.LpsServerSocketListener [lps: /188.8.131.52:31337 (ssl)] Waking for retry of server socket bind for address /184.108.40.206:31337 2016-08-30 14:43:21,839 ERROR c.j.j.l.LpsServerSocketListener [lps: /220.127.116.11:31337 (ssl)] Failed to obtain server socket for address /18.104.22.168:31337 com.jamfsoftware.jsam.lps.LpsException: Failed to bind server socket to [/22.214.171.124:31337] at com.jamfsoftware.jsam.lps.socket.LpsSocketSupplier.bindServerSocket(LpsSocketSupplier.java:136) ~[11:ldap-proxy:0.0.1.20160714202842] at com.jamfsoftware.jsam.lps.socket.LpsSocketSupplier.createSslServerSocket(LpsSocketSupplier.java:61) ~[11:ldap-proxy:0.0.1.20160714202842] at com.jamfsoftware.jsam.lps.LpsServerSocketListener.safeCreateServerSocket(LpsServerSocketListener.java:150) [11:ldap-proxy:0.0.1.20160714202842] at com.jamfsoftware.jsam.lps.LpsServerSocketListener.bindServerSocket(LpsServerSocketListener.java:114) [11:ldap-proxy:0.0.1.20160714202842] at com.jamfsoftware.jsam.lps.LpsServerSocketListener.execute(LpsServerSocketListener.java:93) [11:ldap-proxy:0.0.1.20160714202842] at com.jamfsoftware.jsam.lps.LpsServerSocketListener.run(LpsServerSocketListener.java:72) [11:ldap-proxy:0.0.1.20160714202842] Caused by: java.net.BindException: Cannot assign requested address at java.net.PlainSocketImpl.socketBind(Native Method) ~[?:?] at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) ~[?:?] at java.net.ServerSocket.bind(ServerSocket.java:375) ~[?:?] at java.net.ServerSocket.bind(ServerSocket.java:329) ~[?:?] at com.jamfsoftware.jsam.lps.socket.LpsSocketSupplier.bindServerSocket(LpsSocketSupplier.java:132) ~[?:?] ... 5 more 2016-08-30 14:43:21,840 INFO c.j.j.l.LpsServerSocketListener [lps: /126.96.36.199:31337 (ssl)] Sleeping for 5000 ms before retry of server socket bind for address /188.8.131.52:31337
There isn’t currently any logic in the LDAP Proxy to account for this scenario; as it is right now, all it will do is forward traffic through a specified port (assuming you have that specified port open on your network, of course) and does not have anything built into it to account for using NAT.
Currently, the method you're trying to use simply will not work.
I would recommend filing a Feature Request to have this added into future releases.
You can do so by going to Feature Requests and clicking on the New Feature Request button on the upper right of the page.
I may be wrong but I believe there is logic.
In order for ldap-proxy to forward traffic from one port to a service, it needs to bind to an interface. Today the interface is determined by its public IP Address.
In some setup, the interface doesn't have its public IP assigned but rather a private IP. The public IP address is shared by a firewall that translate requests using NAT to the private IP address.
I may have overlooked something but I believe it's quite a basic feature that is easy to implement. You just have to change an attribute from the json file that is pulled from the JSS.
I actually spoke with two of the senior developers on the LDAP Proxy project prior to my first post just to verify that there was no method built in in the current release to handle NAT, as I wasn't entirely sure and didn't want to post until I knew for certain it was behaving as intended due to that logic not being something currently built into the product; they confirmed that there is not logic built in to properly deal with NAT in the current version, which is why the binding fails.
The LDAP Proxy + Infrastructure Manager is a pretty passive thing right now in that it just passes traffic through the port specified to the address specified during the Infrastructure Manager setup; if that IP address or FQDN specified in the setup isn't directly accessible, it will fail as there wasn't anything built in to account for the need to use NAT or any other redirection of that nature.
For the time being, you will not be able to use NAT and have this work.
I can't speak to how easy or difficult implementing a feature is, as I don't work in development myself, but I would still recommend you create a Feature Request for this so that it can get on their radar as something that customers would like to see added to the product in future releases.
I just came across this problem too (if I understood it correctly):
- Linux server that is inside a local network with a local ip address.
- Public IP Address is just used on the firewall / router.
-> Binding to the public IP address fails (of course)
We got past this error through adding an entry into /etc/hosts so that the name is reoslved locally to the internal ip address.
Just in case someone else comes across this problem.