20.7.4 - Port Forwarding issues

Started by Jetro, November 06, 2020, 01:03:33 AM

Previous topic - Next topic
Hi all

I'm trying to set up some port forwarding rules for multiple devices inside my network (1 Asterisk PBX, 2 VPN servers, 2 other servers and a PC which run CoD Warzone, that requires some ports to be exposed on the www).

I had a try following this guide and other tips found on the web, but nothing seems to work.

My test setup is a Fujitsu TX120 S3 with an E3-1260L, 8GB, 120GB SSD dedicaded to OPNsense.
2x Draytek Vigor 120 on the onboard NICs (ADSL via PPPoE)
2x Gigabit SFP: 1 to the existing router and 1 for the new networks (6 VLANs)

I've made several tests with different settings on port forwarding and firewall rules, but it's stil not working.

Thank you in advance!

Davide

Same issue here with 20.7.4

Brand new OPNsense VM. DHCP server enabled (with one reservation).
Followed the exact steps of the guide but port forward does't seem to work (TCP 6666 ->  TCP 3389).

The target computer on the LAN gets its IP address (from DHCP) and can go online (through the OPNsense firewall).
Other computers on the LAN can connect to the target computer (TCP 3389).

The firewall of the target computer sees (and logs) access from other computers from the same LAN.
However it doesn't see anything (ie: it's not refusing/discardin packets, there's no packet) when connection comes from "outside" (through OPNsense).

Tried both an auto rule (WAN) and manual one, same issue.

pfTop show this when trying the connection (xxx.xxx.xxx.xxx is the public IP I'm trying to connect from, 192.168.55.12 is the target computer):
tcp       In  xxx.xxx.xxx.xxx:55458               192.168.55.12:3389                 SYN_SENT:ESTABLISHED  00:00:15  00:00:27       12      720
tcp       Out xxx.xxx.xxx.xxx:55458               192.168.55.12:3389              ESTABLISHED:SYN_SENT     00:00:15  00:00:27       12      720


Then after a few seconds:

tcp       In  xxx.xxx.xxx.xxx:55458               192.168.55.12:3389                 TIME_WAIT:TIME_WAIT  00:00:15  00:00:27       12      720
tcp       Out xxx.xxx.xxx.xxx:55458               192.168.55.12:3389              TIME_WAIT:TIME_WAIT     00:00:15  00:00:27       12      720


Pretty sure the windows firewall is blocking the requests coming from outside of its own subnet.
,,The S in IoT stands for Security!" :)

November 13, 2020, 01:35:25 PM #3 Last Edit: November 13, 2020, 02:04:13 PM by Klug
Quote from: Gauss23 on November 13, 2020, 11:54:38 AM
Pretty sure the windows firewall is blocking the requests coming from outside of its own subnet.
If it was, it would log the discard packets, wouldn't it?
Nothing is logged.
Also, it doesn't work better with firewall disabled on the Windows VM.

But just to be sure, I setup a Linux VM on the same LAN, with the same OPNsense firewall.
Then setup another "port forward" NAT (5000 -> 22).
This one works (beside a huge speed issue).

I'll keep digging Windows VM side.

"port" forwarding ICMP to the Windows VM works.

Port forward (the very same one) works out of the box with 20.1.9.

Also, there's no speed issue with this 20.1.9 : I'm maxing out the available bandwith with a simple wget (110 MBps).
In 20.7.4 I can't go beyond 45 KBps.

20.7.4 and KVM (Proxmox 6.2-15) don't seem to get along very well in my case.

Great.

Not working anymore after a firewall reboot.

Don't guess, troubleshoot!
Install tcpdump, tshark or Wireshark depending on the OS on the destination host and capture to find out what's coming in.
The same on the opnsense firewall, just connect using ssh (Windows 10 >= 1809 has an openssh client that can be installed as free additional feature) and use tcpdump -i $interfacename host $targetip -vvnn for example.

November 14, 2020, 07:39:10 AM #7 Last Edit: November 14, 2020, 07:44:52 AM by Klug
* Klug über stupid.

I enabled the offload features, the three of them (while they are disabled by default).
Offload and virtIO don't match well.

Disabling them and rebooting the OPNsense fixed the NAT issue for 20.1.9 and 20.7.4.
It also fixed the thoughput issue with 20.7.4