Messages

after considering to file a bug report I found that this has been filed and discuessed with no intent on the opnsense side to fix it in the near future because there aren't enough support tickets realting to this issue.

https://github.com/opnsense/core/issues/3952

sadly this won't be fixed (any time soon)

well it turns out that by modifying the dynamic gateway I simply killed it so that it was no longer working, so all my machines in the LAN behind the opnsense did no longer have internet access..

it also turns out that my problem can be summarized like so: port forwardings on opnsense don't work from the WAN subnet. They do work as soon as a request comes from another network on the wan-side which needs to be routed through the wan side gateway. but as soon as the clinet connecting to a NAT-ed port is on the same subnet as the WAN interface of the opnsense firewall it won't work because opnsense seems to send all outgoing traffic on the WAN interface directly to the standard gateway, even if it is in the same subnet which should not happen.

by disabling the reply-to wan rules this behavior is fixed and all works fine..
i just don't understand how reply-to and this problem is connected.. to me this looks like a bug in how reply-to is implemented.. or the description of this option in the GUI is misleading.

cheers
Pascal

I am really at a loss here:
i am setting up a new opnsense firewall (vesion 21.7.1) for someone else. To prepare everything i have attached the WAN port of the new firewall to my own private Lan network. I have set the WAN interface to request an IP by DHCP which it does.

here is a quick network overview:

my home network: 172.16.51.0/24, Gateway 172.16.51.254 (pfsnese)
new opnsense WAN interface: 172.16.51.128/24 assigned via DHCP, Gateway 172.16.51.254 assigned via DHCP
new opnsense LAN interface: 192.168.30.1/24
Qnap behind new opnsense: 192.168.30.10

clients in the 192.168.30.0 lan can access both my 172.16.51.0 network and the internet without problems.

I have set up a port forwarding for port 8443 on the WAN interface to be forwarded to 192.168.30.10:443 and i have expected to be able to then open the QNAP web-interface from my private lan via https://172.16.51.128:8443 but that does not work.

tcpdump on the opnsense router shows me, that it is getting my requests and it it sending replies to my pc in my own private lan (172.16.51.1) but on my pc tcpdump only shows my requests but no answers.

the same happens with a WAN firewall rule to allow traffic on port 443 to the opnsense web gui via the WAN Port. I simply won't get any answer back to my pc.

after hours of debugging and trying, i finally found out, that it all works perfectly fine, as soon as i hardcode the WAN Gateway IP address!
So i simply go to System -> Gateways -> single and click on the pencil to edit the WAN_DHCP gateway settings. I check the upstream Gateway checkbox and for IP Address, where it currently sais "dynamic" i enter 172.16.51.254, thats the same IP that i got from the DHCP anyway. I then click save and apply the settings.
Magically, all my port forwardings, firewall rules etc. works and i can access bot the opnsense web interface as well as the QNAP web interface from my 172.16.51 network!

i have also tried to just select the upstream gateway checkbox but leave the dynamic ip in there, which did not help, so only hardcoding the IP helps.

in the attachments you can see the non working and the working gateway list entry. as you can see, there is no difference at all in the list, only if you click on edit you can see that the non-working shows "dynamic" and the other one has the IP hardcoded.

can anybody explain to me what I'm missing here? I really don't understand this behavior and it did drive me nuts today! eager to learn why all that is so. Above all i can't understand that this setting as that gateway isn't even involved in the connection!

btw: of course i have disabled the "block private networks" and "block bogon networks" settings for my wan interface. disabling or enabling reply-to wan rules aso did not change anything, i just mention these settings as i found them mentioned in about every thread i found rearding port forwarding issues with a private IP on the wan side ;)

cheers
Pascal

Hi Tom
I just discovered sshpiper myself and saw your issue on the gihub page. My concerns are more with the type of application that would come from using it on opnsense rather than with the tool itself. I can't say anything about the internal security of the tool.

So let's assume that you are using opnsense as a firewall between the internet and your corporate network. The idea of using sshpiper might be, to allow (root?) access to some servers in your corporate network from the outside in oder to remotely administer them without the need of a vpn connection, or for some unprivileged users to do stuff on the server without a vpn connection to your office and without the need to remember which server is forwarded to which port.

because sshpiper acts a s a man-in-the-middle, it won't be possible to connect via sshpiper with your private-key for which you have stored the public key to the authorized_keys file of your server. instead, you will have to add your public key to the sshpiper's authorized key for this specific user and then create a  new private-key which needs to be stored on the sshpiper host (opnsense in this case) and then add the public key for this key to the authorized_keys on your target server for the target user. Alternatively you can of course enable password authentication but that's just a bad idea in itself on internet reachable servers..

so now comes the issue with this: if for some reason your opnsense gets compromized, let's say there is a vulnerability in opensense itself or one of the plugins you may have installed, that allows through one way or another to retrieve those private keys from your opnsense firewall, you have of course an issue, because someone now has a bunch of keys for your servers that will let them straight in. worst case, the same vulnerability allows to access your corporate network too, the attacker just got access to all your ssh servers and the linked accounts bascially "for free" when he hacked your firewall. that's bad.. or in another scenario, a user on the inside of your network (say a student at a school, or a frustrated co-worker) may use those keys to access your servers from the inside.
in boths cases, your servers are compromised, even if you have taken the time and effort to configure a zero-trust corporate network..

so personally if i where to use sshpiper for an application like this, I would run it in a dedicated VM, container or even appliance (think raspberry pi or similar) if you have a docker envrionment anyway, where you can make sure that the VM or container exposes only the sshpiperd port to the outside world. This will lower the chance of a "side-channel" attack on your private keys via some other potentially vulnerable software tremendously.

with this in mind, you can then start to leverage the security advantages this setup may give you.. for exmaple if the admins of those target servers or the users behave insecurely (let's say they create test users with really weak passwords for example) you know at least, that those weak user's accounts won't be accessible from the internet and are only a risk to your internal network security..
or you coud use the sshpiper's log for a fail2ban rule that will lock out any IP addresses that have too many failed authentication attempts within a short period of time. sshpiper will log an entry like "2020/11/06 11:22:27 connection from x.x.x.x:yyyyy establishing failed reason: ssh: disconnect, reason 2: Too many authentication failures" so just make your fail2ban look for this and help secure your servers at least from the outside.

hope this is at least some food for thought before someone spends all the time to create a plugin for opnsense.

i've posted a patch (just a few lines) for this today to the closed issue https://github.com/opnsense/core/issues/3673. the issue was automatically closed due to inactivity and i would like to rais attention to my patch so that it might be included in one of the next releases. at the same time i don't have time right now to figure out how to use github and allt hat, so i was hoping that someone of the developers could just take my patch and include that after review into opnsense.

so if anyone around here has the power to re-open that issue that would be great :)

cheers
Pascal

.. one more thing i have found out:
The floating rule only works if I enable the Quick setting, so if it is matched before the interface rules are matched OR if i disable the Quick setting AND disable the WAN rule which allows all incomming traffic to anywhere.

my suspicion is, that the WAN rule actually matches my traffic but it seems to route it to some strange place where it can't continue, while the floating rule routs it to the correct network.

i still don't understand why that is.. In both rules i have set the Gateway (under advanced features) to default..

Time for a little self-reply :) I researched some more and found the Transparent Bridge Howto here: https://wiki.opnsense.org/manual/how-tos/transparent_bridge.html

however, that's not what I want.. i want to be able to serve ip's via DHCP on my LAN network and in the future have more networks on the LAN Side as well.. but anyway, at least i got some inspiration to try a Floating Rule for once..

And indeed, when I add a floating rule that allows "in" traffic on the WAN interface with destination "LAN net" to pass, i can Ping my "internal" ubuntu machine. However, i can't ssh to the machine. I see the tcp packets coming in on the machine, but i can't establish a ssh connection.

When i then change my floating rule to allow instead of "in" traffic, the traffic in both directions on the WAN interface, i can ssh to my machine.

So doing this I've achieved what i wanted so far, but I don't understand it! Why is that floating rule needed? Why can I Ping (and get a Pong back) but not SSH with the first floating rule but not ssh?

If anyone can shed some light into that i'd greatly appreciate that.. i like to understand what I'm doing ;)

cheers
Pascal

hi
i'm trying to gat an opnsense router to route traffic between two networks without NAT. to test this i have set up a opnsense VM with one interface connected to our network (172.16.16.0/24) and the LAN interface (192.168.1.1/24) connected to an internal network between this VM and a second vm which is running ubuntu.

then whent to Firwall:NAT:Outbound and changed the mode to Manual and made sure there are no rules..

i then set up a route on my real PC to route traffic to 192.168.1.0 via 172.16.16.92 (the ip of my opnsense WAN interface).

last but not least i've added a any-to-any firewall roule for my WAN interface (the lan interface already has the standard LanNet-to-any rule)

i could then ping my PC from the ubuntu VM just fine, but i can't ping the other way around. so when i try to ping 192.168.1.100 (the ubuntu vm) from my real pc, i get no reply. a tracert shows that it really routes via the opnsense vm but doesn't get further from there.

now when i go to Firewall:Settings:Advacned:Mischellaneous and tick the "Disable all packet filtering", pings work both ways. However, i would like to be able to filter traffic in the future, so i don't want to disable packet filtering.

what am I missing?