Does cloudflare has outbound connection filtering options? - cloudflare

I want to filter my server outbound connections and would like to know whether cloudflare supports outbound connection filtering?

Related

WebRTC: Force iceTransportType relay with coturn

I just set up a coturn server and managed to let my WebRTC based app use this TURN server to relay all traffic. I do this to hide the IP addresses of the peers in the WebRTC traffic.
In order to ensure that the IP addresses of my peers are always hidden, I would like to enforce that the iceTransportType always has to be "relay" when someone connects to my TURN server..
Is it possible to enforce this at the side of my coturn server, and if so, how would I enforce this?
Enforcing this is only possible on the client. The TURN server has no control over any peer-to-peer path.

Why do we use STUN servers?

If stun servers give the browser the public IP for the clients, why couldn't the signaling server give us this as well?
Or is there something else that I am missing
I was reading this here: https://bloggeek.me/google-free-turn-server/
UDP and TCP might be routed differently, in particular when there is a HTTP proxy.
Also, a signaling server will know some address of the client, but it will not know a port that going to result in a connection as one needs UDP holepunching for that.

Can expose Rabbitmq on internet?

I want to use rabbitmq in a project, some clients have to comunicate with the rabbitmq server over internet
What is the best way to expose rabbitmq on the Internet ?
should i use a http gateway or directly expose the rabbitmq port ?
Guillaume.
Yes, you can, it is what https://www.cloudamqp.com/ does.
You need to implement the same security policies you'd use for a web site.
For example, put a load-balancer in front of your rabbitmq cluster, use the SSL connections, you could also configure your firewall to accept the connections only from specific ip addresses etc etc..

BizTalk admin console firewall

I'm setting up the windows firewall on my SQL nodes. All outbound traffic is allowed. I'm restricting the incoming traffic.
I have the correct database port open however when trying to connect through the BizTalk admin Console the connection times out.
Is there a specific set incoming firewall rules which need to be enabled on the SQL server for the BizTalk admin console to work?
Having the ports for your specific database instance open are probably not enough. Here are some additional things you should open for admin connectivity:
If you are not using the default DB Instance you will need to open UDP in/out on port 1434 unless you specify the port number in the connections strings.
For access to primary DTC ports, you will need TCP in/out on port 135
For access to secondary DTC ports, you will need TCP in/out on port 50000-50200 (maybe more if your load is very high)
Good Luck!

Determine SSL connection behind a load balancer

Looking for best practice here. We deal with SSL connection at our load balancer level and hence all the connection from our load balancer to our web servers are http. With that we have no way of telling what kind of connection the client is making to our web server since all connection is through http. We currently have 2 solution, one is to have the load balancer to append a port number in the URL string so that we can determine the kind of request (ex. 80 for http and 443 for https). The other solution is for the load balancer to append a special header when it get https request so the web servers knows the type of connection.
Do you see cons in both solution? Is there any best practice regarding SSL being applied at the load balancer level instead of web server level?
I would prefer the header, I think. Adding something in the URL creates the possibility, however slim, that you'll collide with a query string parameter that an app wants to use. A custom header would be easier.
A third option could be to have ssl connections redirect to a different port, say 8080, so on the back end you know that port 80 connections were http to begin with, and port 8080 connections were 443 to begin with, even though they're both http at that point.
I suggest using the header. A related concept is determining the IP address of the client (for logging purposes), since all requests to your web server appear to originate at the load balancer. The x-forwarded-for header is customarily used here.