1

This is a similar but different query to another question I asked back in 2019. I thought it sufficiently different to break out into a new question.

I have written a Node Express app, which uses CORS (Cross Origin Resource Sharing). I'm still trying to develop remotely (SSH to the server). VS Code is working well for that and I can SSH into the server and router (OpenWRT) for admin.

When I run the app, it tells me it's running. Using Links (command line browser) via SSH to the server, I can see the JSON response, so I know it's running.

I have run export PORT=8080 which is now correctly picked up by the code

The app code is:

// Based on a // Tutorial from https://www.bezkoder.com/react-node-express-mysql/ converted to access database of solar power generation values
const express   = require("express");
const cors      = require("cors");
const HOSTNAME  = '0.0.0.0';
const PORT      = process.env.PORT || 8082;
const app       = express();

// const db = require("./app/models");
// db.sequelize.sync();

var corsOptions = {
  origin: `http://${HOSTNAME}:${PORT}`
};

app.use(cors(corsOptions));

// parse requests of content-type - application/json
app.use(express.json());

// parse requests of content-type - application/x-www-form-urlencoded
app.use(express.urlencoded({ extended: true }));

//const PORT = process.env.PORT || 8082;

// simple route
app.get("/", (req, res) => {
  res.json({ message: `Welcome to Greg's application on localhost: ${PORT}.` });
});

// set port, listen for requests
app.listen(PORT, () => {
  console.log(`Server is running on port:- ${PORT}.`);
});

For some reason, it's picking up the fallback port 8082, from const PORT = process.env.PORT || 8082;, not the one specified in var corsOptions = { origin: http://${HOSTNAME}:8080 };

If I run curl -v -X -H http://<my static WAN IP>:8082/ from my remote terminal. I get No route to host - see DNAT rule, below

If I run curl -v -X -H http://<localhost> or <0.0.0.0>:8082/ from my server terminal via ssh. I get

*   Trying ::1:8082...
* TCP_NODELAY set
* Connected to localhost (::1) port 8082 (#0)
> -H / HTTP/1.1
> Host: localhost:8082
> User-Agent: curl/7.66.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Connection: close
<
* Closing connection 0

I believe I've set up a DNAT routing rule for port forwarding correctly (I've got three rules. One for each of 8080,8081 & 8082, for the purposes of experimenting) - edited (see also OpenWRT link for spec and link for explanation of 'option' vs 'list')

config redirect
        option dest_port '8080'
        option src 'wan'
        option name 'Tranq8080'
        option src_dport '8080'
        option target 'DNAT'
        option proto 'tcp'
        option dest_ip '<server's LAN address>'
        option dest 'lan'

I cannot find a way to access the app's http remotely. I don't know if it's the firewall, the code or some sort of cross scripting voodoo in the browser (the remote CURL refusal I think indicates it's not the latter)?

Help?

1 Answer 1

0

For some reason, it's picking up the fallback port 8082, from const PORT = process.env.PORT || 8082;, not the one specified in var corsOptions = { origin: http://${HOSTNAME}:8080 };

My guess is that process.env is checking environment variables, and POST isn't defined in the environment that the process is running in, hence defaulting to 8082. For consistency, I'd define const PORT above your corsOptions and use the PORT variable that's found inside corsOptions. If you want it to use 8080 then set the PORT environment variable to 8080. But that's a side issue to the question at hand.

If I run curl -v -X -H http://<my static WAN IP>:8082/ from my remote terminal. I get No route to host - see DNAT rule, below

...

I cannot find a way to access the app's http remotely. I don't know if it's the firewall, the code or some sort of cross scripting voodoo in the browser (the remote CURL refusal I think indicates it's not the latter)?

Curl's No route to host indicates that it's a routing issue, and thus most likely a problem with the router's DNAT rules. If it were a CORS issue, you'd still get a response back from the server; just one indicating there's a CORS problem.

I'm not familiar with OpenWRT's syntax for port forwarding, but your rules look similar to one example found here for forwarding SSH on port 2222 on the WAN side to port 22 on the LAN side:

config redirect
       option target          DNAT
       option src             wan
       option dest            lan
       option proto           tcp
       option src_dport       2222
       option dest_ip         192.168.10.20
       option dest_port       22
       option enabled         1

The only difference I can see between that example and your setup is the list proto 'udp' and list proto 'tcp' entries. I'm assuming that the Express server is using HTTP and as such, only TCP traffic will be involved. What happens if you update your DNAT rules to use option proto 'tcp' instead of those list lines?

Edit:

As per comments, upon updating the NAT config, the host became reachable, but there was a firewall on the host preventing access on ports 8080 through 8082. Updating the host's firewall rules permitted access.

6
  • Thanks @PrestonManess I made the suggested edits (export PORT=8080, which does now get picked up by the code, I explicitly create a PORT variable, from process.env.PORT and I've cleaned up the firewall port-forward rules to include option proto 'tcp' (excludes udp and avoids list instead of option
    – Greg
    Apr 15, 2022 at 14:10
  • Still Firefox can’t establish a connection to the server
    – Greg
    Apr 15, 2022 at 14:11
  • Incidentally, I just tried curl again. *From remote with my static IP: Connection refused *From Server with my static IP: No route to host *From server with 0.0.0.0: Connected to localhost (::1) port 8080 (#0) > -H / HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.66.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 400 Bad Request < Connection: close < * Closing connection 0
    – Greg
    Apr 15, 2022 at 14:25
  • 1
    Yessss! I don't usually have the firewall 'on' on that machine, so it didn't even occur to me but I'd upgraded recently and obvs the default was firewall 'on'!
    – Greg
    Apr 15, 2022 at 17:17
  • 1
    Thanks for your help Preston
    – Greg
    Apr 15, 2022 at 17:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .