opnsense_-_port_forwarding_issues_when_connecting_from_wan_subnet_often_seen_when_wan_is_a_private_subnet

OPNsense - Port Forwarding issues when connecting from WAN subnet (often seen when WAN is a private subnet)

There is a very annoying bug in OPNsense default settings, that prevents clients inside the WAN subnet to communicate correctly with anything behind the OPNsense router.

Most often this problem will be noticed in lab environments, when a opnsense router is connected with its WAN interface to the production network. That's why i have mentioned private subnets in the title, even thought the issue has nothing to do with the WAN being a private subnet.

here is what happens: lets say we have a company network 192.168.10.0/24 with our own PC having 192.168.10.100 and a default gatway on 192.168.10.1. Now we want to setup a little lab, so we set up a new opnsense firewall and connect its WAN interface to our company network. It gets 192.168.10.105 from our dhcp and the same default gateway 192.168.10.1. So far so good. by default the opnsense router creates a LAN with ip 192.168.1.0/24, while it uses 192.168.1.1 as its own IP on the lan interface.

suppose we add a linux server in that LAN subnet behind opnsense with IP 192.168.1.2 and we now create a port forwarding for port 22 on the opnsense router, so that we should be able to connect from our PC to 192.168.10.105:22 and opnsense would forward this to 192.168.1.2:22.

This last step won't work! OPNsense will forward our traffic correclty, all firwall rules will successfully let our traffic pass and we can even see connection requests coming in on our linux server, we even see the the answer from our linux server on the opnsense router but we never get an answer back on our PC at 192.168.10.100

WHY???

well, after some digging you may eventually find out, that the answers end up on your company's default gatway at 192.168.10.1. If your gateway is stateful, it will just discard those packages, as it is not responsilbe for forwarding packets within your lan. So your PC will never get its answer back.

This behavior of OPNsense is wrong and violates RFC1122 section 3.3.1.1 regarding the local / remote decision on a network. It is triggered by a bug in a feature that was added a long time ago to help with multi-WAN setups.

there is a closed issue on the opnsense github site that details what exactly happens. Sadly the decision makers at opnsense decided that this was not important enough judging by their support tickets and that it will not be fixed for now, so the ticke was closed.

the solution to this is pretty simple, under Fireall→Settings→Advanced we have to set the checkbox for Disable reply-to on WAN rules which will disable this feature that causes all these issues. As long as you are not running a multi-wan setup, disabling reply-to on WAN is not going to cause any issues.

  • opnsense_-_port_forwarding_issues_when_connecting_from_wan_subnet_often_seen_when_wan_is_a_private_subnet.txt
  • Last modified: 14.01.2022 14:30
  • by Pascal Suter