Web-Application Routing

Scenario / Problem

Your customer has whitelisted the URL for your web application, and would like you to access via your own Dull Network, but it will cost them too much money or take too much time to get one or more of your Dull meet servers whitelisted. You use NGINX on Virtual Machine that's running Ubuntu 18.04 or above.


You install Dull on the same Virtual Machine that hosts the web application. You add a forwarding rule to nginx on a virtual folder. That forwards to Dull with particular HTTP duct-configuration that removes the unnecessary HTTP header. The HTTP connection is long lived, and is established to look like a web-socket connection, but doesn't have the message encapsulation. From there Dull can be configured as normal to customise the tunnel.

Configuration Files

Web Host

The following is a snippet to add to your nginx config file.

location /dull/ {
proxy_pass http://dull.{your-domain}:80;
proxy_buffering off;
proxy_cache_bypass true;
proxy_no_cache true;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Dull Host

"Services": {
"Meet TCP": {
"TCP-Server": "{External-IP-Here}:3000",
"Meet-Point": ""
"Meet HTTP": {
"TCP-Server": "{External-IP-Here}:8080",
"HTTP-Strip": "",
"Meet-Point": ""

Ubuntu Limitations

On Ubuntu, Dull can't listen directly on any ports lower than 1024, this rules out port 80. To listen to port 80, the application would need to run as root, but Dull is not installed to run as the root user for security reasons. So instead, use the following iptables rule so that port 80 is forwarded to port 8080 for Dull to listen to.

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

Internally, Dull listens on port 8080. Externally, connect to the host using port 80.


When testing, you can try the full channel and it might work: nice. But if not, you should debug your channel by trying to connect directly to your Dull host which has the HTTP Strip duct-point first. Then you can work backwards trying via your webserver, then through your CDN gateway (if you have one).