To my knowledge, there's no current support for BMI callback through a SOCKS proxy. There are some techniques to work around this, but opening up this port back through is basically the only supported way to make this work.
i've used iptables and rarpd to deal w/ this.
I would be very interested in any pointers/examples you could provide using
iptables/rarpd. That sounds workable. Would you have to set up iptables on
the target provisioned system to route the 9831 call to the appserver back
through the proxy?
We use SOCKS servers to manage most of our customers and we use iptables on the same SOCKS server to re-route BMI callback and PXE server to database.
:PREROUTING ACCEPT [367685:64059971]
:POSTROUTING ACCEPT [31596:2023624]
:OUTPUT ACCEPT [31596:2023624]
-A PREROUTING -d SOCKS_OUT_IP_ADDRESS -p tcp -m tcp --dport 1433 -j DNAT --to-destination DB_SERVER_IP_ADDRESS:1433
-A PREROUTING -d SOCKS_OUT_IP_ADDRESS -p tcp -m tcp --dport 9831 -j DNAT --to-destination APP_SERVER_IP_ADDRESS:9831
-A POSTROUTING -d DB_SERVER_IP_ADDRESS -p tcp -m tcp --dport 1433 -j SNAT --to-source SOCKS_IN_IP_ADDRESS
-A POSTROUTING -d APP_SERVER_IP_ADDRESS -p tcp -m tcp --dport 9831 -j SNAT --to-source SOCKS_IN_IP_ADDRESS
-A OUTPUT -d SOCKS_OUT_IP_ADDRESS -p tcp -m tcp --dport 1433 -j DNAT --to-destination DB_SERVER_IP_ADDRESS:1433
-A OUTPUT -d SOCKS_OUT_IP_ADDRESS -p tcp -m tcp --dport 9831 -j DNAT --to-destination APP_SERVER_IP_ADDRESS:9831
If pxe is in the remote network (or some other box) I just forward through there. options 211 and 212 would point to the pxe server in that case instead of the appserver.
Would setting the dhcp setting to the PXE server work for a
solaris/jumpstart build though? Would I also have to make an adjustment in
the package/job for that setting?
you would also need to set the bmi call back info in the system packages.
So if you are using the SOCKS server to do the IP forwarding as in my example, then DHCP option 211 and the system package point to the SOCKS_OUT_IP_ADDRESS - different for each environment behind a different SOCKS proxy
1 of 1 people found this helpful
Okay, we took some time and made some progress through playing with the traffic forwarding and we do have a specific request in to get 9831 traffic open that is under review by the security team but just to clarify on your comments for using the PXE server. I understand you would set options 211/212 to the PXE server which makes sense but for option 212 since the PXE server does not seem to listen on port 9831 and from re-reading your comments you mean that you would suggest allowing port 9831 traffic from the remote PXE server to the BSA Appserver and then setting up iptables to forward 9831 traffic from the PXE server to the Appserver correct? Initially I took your comments to mean that the remote PXE server could accept those requests natively without having to forward the traffic (which would be extremely good and I could see that being extremely useful). I had assumed this would be done through the existing PXE -> BSADB connection and the job would be set to complete but checking the PXE server I see that port 9831 is not being hosted there (which is understandable with no CM server) so unless the PXE server listens on a different port for this specific purpose then you meant just forward the traffic through the PXE server. Is that correct?
1 of 1 people found this helpful
I think Bill's comment was because he said "If pxe is in the remote network (or some other box) I just forward through there" - see above.
So you could run iptables on the PXE server to do the forwarding or you could use the SOCKS proxy, either way the 9831 needs to go back to the application server
yep. if for some reason you can't open up the connection directly from the target to the appserver on 9831 (or whatever the ssl port is) then you can setup some sort of forwarding or proxying from somewhere on the remote network so the target will connect to that system which is forwarded to the appserver. a logical choice for the forwarder would be the pxe server.