NAT Port Forward Alias not working

[itn3rd77]

Hi,

after upgrading to OPNsense 18.1.b_273-amd64 my NAT Port Forward rules stopped working. All traffic suddenly where blocked by the "Default deny rule" on the WAN interface.

After banging my head against the wall and cursing myself I realized the Host(s) Aliases caused the problem. After changing the use of an Alias to fixed IP-address in all NAT Port Forward rules everything worked again.

When changing the IP-address 172.16.100.2 back to the Alias SYNOLOGY_NAS_DMZ, NAT Port Forward no longer works and all traffic is blocked by the "Default deny rule".

Have I missed some fundamental changes regarding NAT Port Forward or is my setup broken after the update?

I can't believe this is a bug ...

[fichtner]

Since you are on -devel, did you reboot after the last update? The alias subsystem has been replaced. Maybe also this #2042 (comment)

[itn3rd77]

After switching on -devel I did a reboot for sure.

As pointed out by @brandonmreeves at #2042 I can confirm that the directory /var/db/aliastables doesn't exist after upgrade and reboot. So something definitely is wrong ...

[fichtner]

it's -devel after all :)

does it work if the directory is created manually as described? I'm assigning @AdSchellevis , he will know what to do.

[itn3rd77]

Creating and populating the directory manually brings Aliases back to life.

[fichtner]

One question, are you using the /var MFS option?

[itn3rd77]

Just realized that the directory is not cleaned up correctly when deleting an Alias. I have created an Alias TEST_LOCALHOST to check if everything is working after manually creating the directory. After deleting the Alias the files md5.txt and self.txt remain in the directory.

Should I open a seperate issue for this?

[itn3rd77]

One question, are you using the /var MFS option?

Never seen this. How can I check this?

[fichtner]

Easiest way is asking the system:

# df -h

and posting the output.

[itn3rd77]

Ok. I could have thought it myself.

root@opnsense:~ # df -h
Filesystem         Size    Used   Avail Capacity  Mounted on
/dev/gpt/rootfs    215G    4.8G    193G     2%    /
devfs              1.0K    1.0K      0B   100%    /dev
devfs              1.0K    1.0K      0B   100%    /var/dhcpd/dev

[fichtner]

Should I open a seperate issue for this?

Let's keep this in here, it's all related.

Ok, no /var MFS, thanks, that helps narrow it down :)

[AdSchellevis]

it's likely still resolving entries from test_localhost, the .self file should contain the lines that are processed already.

[itn3rd77]

@AdSchellevis Don't know what you mean with with till resolving entries. I have never used this Alias. Just created to check if everything is created inside /var/db/aliastables and then deleted the Alias.

Here is the output:

root@opnsense:/var/db/aliastables # cat TEST_LOCALHOST.self.txt
127.0.0.1

[AdSchellevis]

What was the content of the alias before you deleted it? maybe something else went wrong which crashed the script.

Can you try to run the script manually and see if it fails somewhere?
/usr/local/opnsense/scripts/filter/update_tables.py

Thanks

[itn3rd77]

Ok here we go ...

Created a new Alias named SIMPLE_TEST via GUI

root@opnsense:/var/db/aliastables # ls -la SIMPLE_TEST.*
-rw-r-----  1 root  wheel  32 Jan  4 11:27 SIMPLE_TEST.md5.txt
-rw-r-----  1 root  wheel  10 Jan  4 11:27 SIMPLE_TEST.self.txt
-rw-r-----  1 root  wheel   9 Jan  4 11:27 SIMPLE_TEST.txt

Content after creation:

root@opnsense:/var/db/aliastables # cat SIMPLE_TEST.self.txt 
127.0.0.1
root@opnsense:/var/db/aliastables # cat SIMPLE_TEST.txt 
127.0.0.1

Delete Alias named SIMPLE_TEST via GUI

Before clicking "Apply changes" via GUI

root@opnsense:/var/db/aliastables # ls -la SIMPLE_TEST.*
-rw-r-----  1 root  wheel  32 Jan  4 11:27 SIMPLE_TEST.md5.txt
-rw-r-----  1 root  wheel  10 Jan  4 11:27 SIMPLE_TEST.self.txt

The file SIMPLE_TEST.txt ist already removed!

Content before clicking "Apply changes" via GUI

root@opnsense:/var/db/aliastables # cat SIMPLE_TEST.self.txt 
127.0.0.1

After clicking "Apply changes" via GUI

root@opnsense:/var/db/aliastables # ls -la SIMPLE_TEST.*
-rw-r-----  1 root  wheel  32 Jan  4 11:27 SIMPLE_TEST.md5.txt
-rw-r-----  1 root  wheel  10 Jan  4 11:27 SIMPLE_TEST.self.txt

Content after clicking "Apply changes" via GUI

root@opnsense:/var/db/aliastables # cat SIMPLE_TEST.self.txt 
127.0.0.1

Manually running the script /usr/local/opnsense/scripts/filter/update_tables.py

root@opnsense:/var/db/aliastables # /usr/local/opnsense/scripts/filter/update_tables.py
root@opnsense:/var/db/aliastables # echo $?
0

Content after manually running the script /usr/local/opnsense/scripts/filter/update_tables.py

root@opnsense:/var/db/aliastables # cat SIMPLE_TEST.self.txt 
127.0.0.1

[AdSchellevis]

@itheiss I think I'm missing something here, the alias content is deleted before apply, which doesn't have to be a big issue as it's still loaded in the filter, but your issue started with the alias not being set for host type aliases.

Is this issue reproducible? Normally using the new aliases it should load the tables, which are viewable under Firewall->Diagnostics->pfTable in the new situation, then the nat rule should use the table.... question is, are we missing the nat rule or is the table empty. I'm not able to investigate this further today, but if you can check how I can reproduce this that would be very welcome.

[fichtner]

More patches went in.

[hirschferkel]

I still get this problem with 18.1 Production Series! Installed 18.1 nano-image and restored a backup from 17.7. But now, no defined Port range is working anymore, which belongs to an Alias.
When I manually input all ports with IP-adresses it works.

How can I get back my Aliases, now?

[AdSchellevis]

@hirschferkel there's not a lot of context in your question, but this might be related https://forum.opnsense.org/index.php?topic=7078.msg31436#new

[hirschferkel]

The context is the same as mentioned in the ticked in the beginning. We implemented Aliases to define port ranges and these are not working in the 18.1 stable version. That's all. If I ad every port manually not with an Alias but an IP it's working. I try to upload the patch, but it should ne fixed in a stable release, shouldn't it?

[AdSchellevis]

the fix will most likely be in the next release, but in the meantime you can use the patch

[hirschferkel]

The patch did not work. It still works with manually added, single ports and ID.

opened terminal in OSX
logged in with ssh and root user
entered opnsense-patch 57f51d2
reboot

doesn't work with aliases.

[AdSchellevis]

Maybe another issue, we need more input to be able to help out. (preferably the exact definition of the rule and alias and a if possible the generated rules in /tmp/rules.debug for both versions to compare differences)

[hirschferkel]

Rules are just > take all incoming connections on a range of ports to one destination and it's corresponding ports.
Host is defined as an Alias (but that's not the problem).
Port range is defined as another Alias.

But what I found is, that old rules imported can not be edited!
I can edit a new rule but this one will not be available with NAT port forwarding!

Something has gone quite wrong here...

[hirschferkel]

It only works if I choose "pass" as an option, in a manual, single port forwarding. But I can't select new rules which are set to pass. I guess old rules loose their definition, as they can not be edited either. So in the end I cannot set a portrange to be passed... that's wired.

[AdSchellevis]

Associated rules can't be changed from the firewall section, because the nat rule "owns" them. We have changed that a long time ago to prevent issues.

Normally a save should automatically update the associated rule, but if there's something wrong with the import it might be better to copy the rule (then you can create a new filter rule) or manage the firewall rules manually (set to None).

By my knowledge there haven't been changes in this area for 18.1.

[hirschferkel]

you're right, I missed that.

So if I autocreate a port forwarding and get an automatic associated rule, it will not work.
If i use an old automtically generated rule, it will not work.
If I setup a rule manually, it will not be available for a new port forwarding.

So at the moment it won't work, anyway?

[AdSchellevis]

at my end the associated filter rules looks normal (the port alias is mentioned in both the rdr as the pass rule in /tmp/rules.debug).

[hirschferkel]

At my end the filter rules look great, too. Unfortunatelly they don't work. ... and sorry but I'm not so deep into it, so I don't know what "rdr" is and how to acccess or read /tmp/rules.debug.

[hirschferkel]

After Updating to 18.1.1 it runs again. Obviously there were some more issues.