Wan to Wan port redirect

Started by Forged, January 06, 2025, 08:55:21 PM

Previous topic - Next topic
Hello,

A few days ago, I encountered a DDoS issue on my home server. To protect against DDoS attacks, I rented a VM in a data center and installed OPNsense on it. This is my first time working with OPNsense, but I have significant experience configuring network equipment, including MikroTik.

Let's assume:

 - 1.1.1.1 is my OPNsense proxy in the data center, and
 - 2.2.2.2 is my physical server.
On OPNsense, I created a rule to forward traffic from 1.1.1.1:46461 to 2.2.2.2:46461. On the 2.2.2.2 side, there is a MikroTik router, which is already fully configured. However, when I send a request to 1.1.1.1:46461, according to the logs, the traffic is forwarded, but it does not reach 2.2.2.2:46461.

At the same time, if I directly send a request to 2.2.2.2:46461, it works fine.

Here is the rule I am using on OPNsense:

Interface: Loopback: WAN
TCP/IP Version: IPv4
Protocol: TCP/UDP
Destination Port Range: 46461
Redirect Target IP: 2.2.2.2
Redirect Target Port: 46461
How can I resolve this issue?

You probably need an associated firewall rule like

Source: any
Destination: 2.2.2.2
Destination port: 46461
Action: allow

on WAN. Though I doubt this will work, because the destination server will see the original client IP address and send the packets directly instead of through OPNsense. So some additional NAT will be required, too.

I am not sure Port forward from WAN to WAN is supposed to work at all. In common setups the firewall is between the Internet and the server(s).

If it's HTTP(S) traffic you could use Caddy or HAproxy or Nginx to proxy the requests. Since that involves two separate TCP connections that will work.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)


Yes, I do have a firewall rule for this port. I forgot to mention it.

I also thought there should be another firewall rule. It's just that on MikroTik, a single NAT rule is usually enough for everything to work.

Here, it's obviously not that simple.

This is not HTTP traffic; it's TCP/UDP (a game server).

Then the game server should probably be behind the firewall so NAT can be applied properly.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

The game server itself is behind a MikroTik NAT (router).

Initially, when I rented the VM in the data center, I deployed RouterOS on it. With a NAT rule in MikroTik, everything worked fine, but I decided to look for a free alternative and chose OPNsense.

After setting it up, I checked the logs, and on OPNsense, I see something like this:

__timestamp__    2025-01-07T02:10:00 
ack 
action           [pass] 
anchorname 
datalen          0 
dir              [out] 
dst              2.2.2.2 
dstport          46461 
ecn 
id               11702 
interface        vtnet0 
interface_name   wan 
ipflags          DF 
ipversion        4 
label            let out anything from firewall host itself 
length           52 
offset           0 
protoname        tcp 
protonum         6 
reason           match 
rid              fae559338f65e11c53669fc3642c93c2 
rulenr           66 
seq              3034983719 
src              185.155.*.* (My PC IP) 
srcport          63207 
subrulenr 
tcpflags         S 
tcpopts 
tos              0x0 
ttl              117 
urp              65280 

But this packet does not reach the MikroTik router behind which the game server is located.

Perhaps I should connect them through a tunnel, such as WireGuard?