I am trying to use bastion and not quite getting something. My goal is to enable access to a cloud hosted server that sees very high loads and that I don’t want any additional overhead on it from running cloudflared locally, so I want client traffic to pivot from a bastion server for just this application in the same subnet. The server presents six different TCP ports to a thick client that runs on user end points, and I have a Cloudflare DNS entry for its non-routable address. Currently end users start up the thick client, the thick client resolves the server hostname to its non-routable address, and traffic for that non-routable subnet is tunneled to a VPN point of presence that carries traffic for this subnet, and the thick client makes the connection with no issues.
So I spun up another VM with a NIC in the same subnet and I used hello world mode to ensure that the Cloudflare Tunnel is up and that my AAD group ACL for access is behaving as intended (works for group members and prompts for authentication for non-members). From this bastion server, I can resolve and ping the non-routable address for the server I want clients to reach. But… I cannot figure out the correct syntax for cloudflared on the client side.
Cloudflared responds with “failed to start forwarding server: listen tcp 10.x.x.x:8080: bind: The requested address is not valid in its context.”
The 10.x.x.x:8080 address is the non-routable address resolved when querying cloudserver.ZZZ.com. I figure there is something I am misunderstanding with the --url and --destination switches but I’ve tried a few permutations with no luck. he address is valid in context of the bastion, as it resolves and can be pinged. I figure there is something obvious I’m doing wrong and I just need an outside perspective for it to click.
Nothing really happens on the bastion server side when the client throws this error, so it is not initiating anything before seeing the syntax error. I should have noted that cloudserver.ZZZ.com resolves to 10.x.x.x in my example. So cloudflared on the client is resolving that for either the url or the destination and then saying the requested address is not valid.
I think there is something I’m missing with the url and destination logic. I have not had time to poke at it since I posted this on Sunday (it was in moderation for a long time for some reason).
With a bit of time to look at this again, I realized that the logic is that --url Is really to set a local port that when touched will have its traffic routed to the destination url and port, so I set this up for the 6 services and oddly get 5 of them to work correctly but the 6th does not. In exploring this, those 5 are all http on random high ports, and this one is some other kind of TCP traffic. I’m not sure why this is as yet.
Otherwise, it seems that the correct syntax was right under my nose. I had hoped that I could roll this out without having to have end users make changes to their thick client configurations. Having to tell everything to look at localhost vs leaving the human readable FQDN in place takes a fair amount of shine off of using access and bastion mode.
Well, I figured this out but don’t have a solution. The application that is not working is a license key server for a per-seat licensed CAD product. When the CAD program on the end user system reaches out for a license, one of the things it passes to the license server is the URL it is connecting to for its license. The license server is looking at its cryptographically signed license bundle and dropping the connection because the license was not issued for a machine named “localhost”.