Hi there, you should be able to set up an additional service as a firewall to stop inbound traffic. Will also ask the team if this is an upgrade we can do but given the payment provider is requiring this, the fastest path might be blocking the incoming traffic.

Thank you. I am waiting for your team's reply.

Hey, cannot guarantee this upgrade in the short term hence I was recommending setting up an additional service that can stop the inbound traffic as that might be the quickest way around this.

Hi,

Can you guide me in how to deploy the firewall service?

Thanks,

Fahad

Hi Fahad, we're unable to guide you on setting up a firewall but I can give you a starting point.

You might consider deploying a reverse proxy or using a third-party firewall service that can be configured to block incoming traffic and can check our templates to see if there are any good fits for your usecase https://railway.com/templates , or use external services like Cloudflare for DDoS protection and firewall capabilities.

For more detailed guidance on managing public networking and understanding how Railway handles inbound traffic, you can check our Public Networking documentation.

Hi,

Is the outbound Static IP shared?

Thanks,

Fahad

Yes, the static outbound IP may be shared with other customers. You can check out our docs on it here: https://docs.railway.com/reference/static-outbound-ips

I am mentioning this because I am not how to put the shared static behind the Cloudflare firewall. However, if is not possible, the static IP should be behind a stateful firewall that don't allow inbound traffic. Not sure why I can reach an only outbound IP that shouldn't be reached. Moreover, it has a vulnerability.

We need a solution for the vulnerable outbound static IP.

Can you please provide any further information, reproduction steps on how you are able to successfully reach the static outbound IP with inbound traffic?

Hi Chandrika,

Sorry, I thought I replied to you. I did scan with an ASV entity. I have attached the report. The IP is 34.168.253.122.

They were able to reach the IP 34.168.253.122 and do vulnerability check.

We don't have firewall rules to prevent ingress to IP blocks we use for outbound traffic. You might be able to configure it behind some external proxy and send all traffic through it, but that's not something we support right now.