Weird Rules for Port Forwarding NAT

Corgumolax

Hello,

I am facing a problem that I do not understand:

I have a NAT of type Port Forwarding:

Good_IPs_Aliases(*) --> My Public IP(1234) --> PrivateComputer_Alias(4321)

And the associated WAN rule:
Good_IPs_Aliases(*) --> PrivateComputer_Alias(4321)

And it works as expected. Yesterday, though I added a new address to the alias Good_IPs_Aliases, but all packets from this new IP were blocked by the default DROP rule.

After a lot of testing, I managed to get the desired operation by adding the WAN rule:
NEW_IP(*) -----> My Public IP(1234)

I don't understand why because it seems to go against the order of processing of the rules: the WAN rule seems to be applied before the NAT... In addition, I don't understand why this IP requires a special rule while all the other IPs of the alias work normally.

Does anyone have an idea or an explanation?
Thank you for your attention and patience.

PS: Running PFSense 2.7.2

Gertjan

@Corgumolax

Have a look at the /tmp/rules.debug file.
That is the firewall rules list loaded into pf, and contains all the firewall (and NAT) info.

Under

# User Aliases

you'll find all the aliases. No host names, of course, as a firewall can only deal with IP addresses.

Corgumolax

@Gertjan
Hi,

not sure for what I'm looking for in the User Aliases section of /tmp/rules.debug I can find an entry looking like

table <Good_IPs_Aliases> persist
Good_IPs_Aliases = "<Good_IPs_Aliases>"

but no IPs there.

In the GUI > Diagnostics > Tables > Good_IPs_Aliases, shows that the alias contains New_IP

Gertjan

@Corgumolax

Then that's the ?!

As said, pf works with IP addresses.

I see this :

# User Aliases 
table <10_15> {   192.168.1.3  192.168.1.14 } 
10_15 = "<10_15>"
table <APx> {   192.168.2.2  192.168.2.3  192.168.2.4 } 
APx = "<APx>"
table <DiskStation2> {   192.168.1.33  2a01:cb19:dead:beef:::c2 } 
DiskStation2 = "<DiskStation2>"
table <DiskStation2IPv6> {   2a01:cb19:dead:beef:::c2 } 
DiskStation2IPv6 = "<DiskStation2IPv6>"
table <DNS_Root_Servers_v4> {   198.41.0.4  170.247.170.2  192.33.4.12  199.7.91.13  192.203.230.10  192.5.5.241  192.112.36.4  198.97.190.53  192.36.148.17  192.58.128.30  193.0.14.129  199.7.83.42  202.12.27.33 } 
DNS_Root_Servers_v4 = "<DNS_Root_Servers_v4>"
table <DNS_Root_Servers_v6> {   2001:503:ba3e::2:30  2801:1b8:10::b  2001:500:2::c  2001:500:2d::d  2001:500:a8::e  2001:500:2f::f  2001:500:12::d0d  2001:500:1::53  2001:7fe::53  2001:503:c27::2:30  2001:7fd::1  2001:500:9f::42  2001:dc3::35 } 
DNS_Root_Servers_v6 = "<DNS_Root_Servers_v6>"
table <DS2> {   192.168.1.33 } 
DS2 = "<DS2>"
table <DVR> {   192.168.1.8 } 
DVR = "<DVR>"
table <FTP_permitted_list> {   192.168.1.7  2a01:cb19:dead:beef:::c6 } 
....
and many more.

Corgumolax

@Gertjan
First (but not the least) thanks for these ideas

I think I don't see any ip in regard of Good_IPs_Aliases in the rules.debug file because this alias contains IPs and other aliases (all of type hosts). It seems that all nested aliases share this behaviour.

Nevertheless it does not explain why one specific ip does not work like the orthers, nor why I have to set a rule that does not match the documentation.

Gertjan

@Corgumolax said in Weird Rules for Port Forwarding NAT:

this alias contains IPs and other aliases (all of type hosts).

For me, that explains everything, the build in "resolve hostnames / URLs to IP addresses" isn't that smart.

Read Aliases. A and AAAA are resolved, but if CNAME return, then these are not takes in account.
See the big blue note.

Knowing that "google.com" is a typical huge DNS mess, you have no other choice then entering the specific host names that will resolve to A and AAAA, and if doubt, enter IPv4 and IPv4 directly in the alias.

johnpoz

@Gertjan said in Weird Rules for Port Forwarding NAT:

table <DNS_Root_Servers_v4> { 198.41.0.4 170.247.170.2 192.33.4.12 199.7.91.13 192.203.230.10

A bit off topic, but what is the point of such a alias/table? What sort of rules do you have it in? Where are you rules to other dns? You understand the roots are just step 1 in the resolve process.. All they hand out is the NS for the tlds.. if all you allow is access to the roots, your never going to be able to actually resolve anything..

Is it in some log rule or something.. Curious what would be the use of such an alias? Curious to this sort of use case where I would want/need an alias that only contained the roots?

Corgumolax

@Gertjan

No DNS resolution in my rules. Aliases only contains IPs or other aliases that contains only IPs.

Gertjan

@johnpoz said in Weird Rules for Port Forwarding NAT:

A bit off topic, but what is the point of such a alias/table?

Yeah, I saw that. A little alias cleaning might be useful, as "lesser is better" always applies.
On the other hand, the info is just static, and I don't use it anymore.

That alias is a left overt of one of my eternal "how does DNS work" learning process. That table <DNS_Root_Servers_v4> might be part of my pfSense config version 1.x, pretty day one.
I added these IPv4 ( and their IPv6) into a an alias so I could use a firewall PASS rule that counts DNS root server traffic. My way of seeing how much / often the resolver contacts one of the root servers.
The conclusion was deceiving, as it it was actually not a lot, as questions like : "gime a dot com server list", "gime a dot org server list", "gime a dot net server list" (the TLDs) etc are all cached by unbound.

Btw : I had ones the opportunity to visit the k.root.server in "Amsterdam", I missed it, as security had changed a lot at the end of 2001.

johnpoz

@Gertjan thanks - that damn curiosity cat was really meowing at me about this one ;) clawing at back of my brain as well - what would you want use such an alias for?? hahahha