Port-Forward on WAN with private IP

Started by ChrisVH1982, February 27, 2021, 10:59:08 PM

Previous topic - Next topic
Dear community,

I've been trying getting Port-Foward to work from WAN to LAN using a private IP for WAN interface. Yes, a private IP address for testing!

I created a Port Forward rule which seem to be okay. It works when selecting the LAN interface as source interface and destination but it does not work out on WAN interface.

WAN: 192.168.19.67
LAN: 192.168.20.68


  • WAN interface does NOT block private networks
  • WAN interfaces does NOT block bogon networks
  • Reflection for port forwards is ON

What is the special thing about the WAN interface?



Are you testing this from a host in the LAN subnet, the WAN subnet or somewhere beyond the WAN upstream gateway?
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

I am testing from a host in WAN subnet using a private
IP subnet, different from LAN subnet.

Most likely: Firewall -> Settings -> Advanced -> Disable reply-to on WAN rules
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).


Network plan please:)
(Unoffial Community) OPNsense Telegram Group: https://t.me/joinchat/0o9JuLUXRFpiNmJk

PM for paid support


Quote from: ChrisVH1982 on February 28, 2021, 11:05:17 PM
Sure :-)


What are you trying to do?
That looks very strange to me

Lan and Wan interface in the same switch? Where's your ISP?
(Unoffial Community) OPNsense Telegram Group: https://t.me/joinchat/0o9JuLUXRFpiNmJk

PM for paid support

This is for testing and getting familiar with opnsense. I would like the WAN interface accept requests from a private IP. Technicially speaking this must be feasible.

Hi
can you share associated pf rule string from
Firewall: Diagnostics: pfInfo -> Rules tab?

Not sure if that string will help?!

@0 scrub on lo0 all fragment reassemble
  [ Evaluations: 1051590   Packets: 64        Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@1 scrub on hn1 all fragment reassemble
  [ Evaluations: 1051517   Packets: 545136    Bytes: 19245212    States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@2 scrub on hn0 all fragment reassemble
  [ Evaluations: 506377    Packets: 506334    Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@0 block drop in log on ! hn1 inet from 192.168.20.0/24 to any
  [ Evaluations: 381920    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@1 block drop in log inet from 192.168.20.68 to any
  [ Evaluations: 335661    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@2 block drop in log on ! hn0 inet from 192.168.19.0/24 to any
  [ Evaluations: 294085    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@3 block drop in log inet from 192.168.19.67 to any
  [ Evaluations: 294088    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]

no. there should be a rule with tcp port 8080 on WAN

8080 is not showing up at all and I already attemped to open 192.168.19.67:8080 to trigger such message.

Just the WAN IF IP is showing up:

@3 block drop in log inet from 192.168.19.67 to any
  [ Evaluations: 319832    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]


--------------------------------
But 8080 appears on Firewall: Diagnostics: pfInfo -> NAT tab

@0 no nat proto carp all
  [ Evaluations: 2210      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@1 nat on hn1 inet proto tcp from (hn1:network:1) to <SVRWEB2:1> port = http -> (hn1) port 1024:65535 round-robin
  [ Evaluations: 2210      Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@2 nat on lo0 inet proto tcp from (lo0:network:1) to <SVRWEB2:1> port = http -> (lo0) port 1024:65535 round-robin
  [ Evaluations: 19        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@3 nat on hn0 inet proto tcp from (hn0:network:1) to <SVRWEB2:1> port = http -> (hn0) port 1024:65535 round-robin
  [ Evaluations: 3         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@4 nat on hn0 inet proto tcp from (hn0:network:1) to <SVRWEB2:1> port = http -> (hn0) port 1024:65535 round-robin
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@5 nat on hn1 inet proto tcp from (hn1:network:1) to <SVRWEB2:1> port = http -> (hn1) port 1024:65535 round-robin
  [ Evaluations: 3         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@6 nat on lo0 inet proto tcp from (lo0:network:1) to <SVRWEB2:1> port = http -> (lo0) port 1024:65535 round-robin
  [ Evaluations: 3         Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@0 no rdr proto carp all
  [ Evaluations: 413640    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@1 no rdr on hn1 proto tcp from any to (hn1:2) port = http
  [ Evaluations: 413633    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@2 no rdr on hn1 proto tcp from any to (hn1:2) port = https
  [ Evaluations: 14        Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 36645 State Creations: 0     ]
@3 rdr log on hn1 inet proto tcp from any to (hn1:1) port = 8080 -> <SVRWEB2> port 80 round-robin
  [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]

the rule should be there for the packets to pass (the rule should have been created automatically when you created the port forward rule).
Quoteattemped to open 192.168.19.67:8080 to trigger such message
not just "open". firewall rules evaluation occurs after the translation. that is in the firewall rule the destination should be the redirection address. to avoid mistakes you can try to delete and re-create the port-forward rule. a pass-rule should be automatically created.

I re-created it a couple of times already and thanks to refleciton setting, I find the rule in "FW > Rules > WAN".