Alias use on Outbound NAT - not possible, nat not working

[katamadone]

Alias use on Outbound NAT seems currently broken:
Forum Report of osn1803 https://forum.opnsense.org/index.php?topic=12006.0
mine:
https://forum.opnsense.org/index.php?topic=12002.0

When we used NAT with an "Alias - predifined network" it would not be translated as expected. But if we changed the NAT to an explicit NET/CIDR it worked instantly.

Should i add / duplicate the whole forum entry? (pictures etc.. )

[AdSchellevis]

please use the issue template, which should walk you through the things needed to evaluate if it's a bug and how to reproduce it on our end.

[katamadone]

Describe the bug
We'd like to NAT an address. NAT should be applied from a subnet attached to opnsense to second subnet attached to opensense and should use the interface address of the second for nat.
IF machine X from subnet/interface c100 would like to access Machine X in subnet/interface c101 it should be translated with the address of the opnsense interface address of c100.
Hopefully I didn't mix up anything - otherwise I have to document it further tomorrow with more precise IPs.
Were having it on 19.1.1 (looks like someone - described above - has the same problem)

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Firewall/NAT/Outbound'
2. Click on 'add
3. Enter the Outbound NAT Rule

• Interface source interface c100
• TCP/IP IPv4
• TCP/UDP
• Source any
• Source port any
• Destination address "predefined entry of c101"
• Destination port any
• Translation Target "opnsense address in c101"

4. See the error (screenshot not working)

if you do the same on point 3 with
. Destination address "c101" cidr notation
--> its working

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
not working nat entry (tcpdump on destination system)

working nat entry

Relevant log files
not working - relevant timestamp timestamp 13:46:31.840143:

working - relevant timestamp 13:51:13:082851:

Environment
(2x) VMWARE Virtual Guest in HA
OPNsense 19.1.1-amd64
FreeBSD 11.2-Release-p8-HBSD
OpenSSL 1.0.2q

[AdSchellevis]

we're at 19.1.4 at the moment, can you try an upgrade first?

[katamadone]

tested with 19.1.4 - same problem
BUT be more precise

• Interface Settings (IP) of t_tools_sgmgmt_int 10.40.200.18/28
• so if i choose Destination t_tools_sgmgmt_int net it should be the same
  --> doesn't work
• for a test I just created an alias which has the exact network 10.40.200.16/28
  --> that works
  -- same for entering directly the subnet... works

conclusion:
predefined alias / object of the interface doesn't work

[fichtner]

what kind of interface config does t_tools_sgmgmt_int have? are you revering to "interface setting" as the current one or as in Static IPv4 configuration? Because if it was DHCP it would likely not work.

[katamadone]

t_tools_sgmgmt_int is a vlan interface with a static address

[AdSchellevis]

can you make sure the rule has a descriptive name and dump the rule generated for it?

grep '<<descriptive name>>' /tmp/rules.debug

[katamadone]

working with alias
nat on vmx2_vlan704 inet proto {tcp udp} from any to $aliastest_net_sgmgmt_int -> 10.40.200.18 port 1024:65535 # INT: sgmgmt NOT routed

not working

#debug:Unable to convert address, see to for details
# nat on vmx2_vlan704 inet proto {tcp udp} from any to {"address":"opt28"} -> 10.40.200.18 port 1024:65535 # INT: sgmgmt NOT routed
nat on vmx2_vlan703 inet proto {tcp udp} from any to 10.40.200.0/28 -> 10.40.200.2 port 1024:65535 # PROD: sgmgmt NOT routed

didn't deliver you the grep itself, it's an excerpt of the rules.debug so you see the debug line above

[AdSchellevis]

ok, this is your defective rule then, right?

# nat on vmx2_vlan704 inet proto {tcp udp} from any to {"address":"opt28"} -> 10.40.200.18 port 1024:65535 # INT: sgmgmt NOT routed

it has address of opt28 selected as to address (not it's network), just to be sure. I'll try this at my end as well.

[katamadone]

yes.. I verified it right now again. Selected the t_tools_sgmgmt_int net not the t_tools_sgmgmt_int address
and rule entry is {"address":"opt28"}

[AdSchellevis]

ok, let me prepare a fix for this.

[katamadone]

thx in advance

[AdSchellevis]

@katamadone found it, you do have to save your settings again, the issue seems to be in the page 64c4d89

opnsense-patch 64c4d89

should to the trick

[katamadone]

doing that on the slave
opnsense-patch 64c4d89

Fetched 64c4d89 via https://github.com/opnsense/core
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 64c4d89b9dd99b9041f0984bec39ed76ed9dc978 Mon Sep 17 00:00:00 2001
|From: Ad Schellevis <ad@opnsense.org>
|Date: Thu, 14 Mar 2019 09:29:14 +0100
|Subject: [PATCH] firewall, source nat, typo in destination address, closes
| https://github.com/opnsense/core/issues/3321
|
|---
| src/www/firewall_nat_out_edit.php | 2 +-
| 1 file changed, 1 insertion(+), 1 deletion(-)
|
|diff --git a/src/www/firewall_nat_out_edit.php b/src/www/firewall_nat_out_edit.                                                          php
|index 754bc8961d..19a066337c 100644
|--- a/src/www/firewall_nat_out_edit.php
|+++ b/src/www/firewall_nat_out_edit.php
--------------------------
Patching file www/firewall_nat_out_edit.php using Plan A...
Hunk #1 succeeded at 286.
done
All patches have been applied successfully.  Have a nice day.

grep out
nat on vmx2_vlan704 inet proto {tcp udp} from any to (vmx2_vlan704:network) -> 10.40.200.18 port 1024:65535 # INT: sgmgmt NOT routed
looks correct & works

Thanks again.

[AdSchellevis]

thanks for confirming

[katamadone]

hm.. wait short.. have to confirm something had a glitch in the outbound nat overview that "Destination" was empty.

• Re-edited the rule, Destination address is there in rule edit mode, saved it

• same behaviour (empty field)
  

• applied patch again to remove, edit, save, Overview is correct

[AdSchellevis]

ok, so the overview has a similar issue too.

[katamadone]

yes.. see the more precise above "same" rules but the above one is working related to nat, but not displayed correctly
the one below is not working and not re-edited.

[katamadone]

as described - in the rule edit all seems to be correct

[AdSchellevis]

same procedure, add ff4de67 to fix the presentation.

[katamadone]

opnsense-patch ff4de67
Rule correct, nat working but view displays interface not the combination of "name and net":

is there any chance to list which patches are installed?

[fichtner]

This is not how opnsense-patch works. Please don't panic and read:

# man opnsense-revert
# man opnsense-patch

[katamadone]

no panic here was only a bit confused by Patches can also be reversed by reapplying them and but multiple patches must be given in reverse order to succeed.
and because opnsense-patch -l delivers the patch stored in the cache regardless of the install state im not sure if the patches/patches are now applied and in the correct order...

[katamadone]

finally confirm.. don't know what it was 7 hours ago.
verified it at home on pcengines (nat & display)
and retried the third time at the company on vmware - now good, too. (restarted the browser maybe did the trick).

Thx again for your effort.