Firewall ignoring allow rule

[maverickws]

Hi there,

I have an issue I'll try to describe here. We have a Port forwarding configured in the following fashion:
source address: alias provider_1
destination ports: alias ports_1
internal server address: lan_1

Port forward rule:
Interface WAN
Protocol TCP/UDP
Source Address: provider_1
Source Ports: *
Dest. Address: WAN address
Dest. Ports: ports_1
NAT IP: lan_1
NAT Ports: ports_1

This automatically added a rule on the WAN interface:
Protocol: IPv4 TCP/UDP
Source: provider_1
Port: *
Destination: lan_1
Port: ports_1

however this isn't working. We see the IP's from the provider (and that are listed at provider_1, we confirmed) being denied:

Action: block/1000000103
Time: May 26 15:42:48
Interface: WAN
Rule: Default deny rule IPv4 (1000000103)
Source: provider_ip:5060
Destination: wan_ip:5060
Protocol: UDP

(port 5060 is listed on ports_1)

We have flushed the firewall states, but had no effect. Any suggestions? thanks

[KOM]

@maverickws Flushing states is useful to clear an open state when you want it blocked but your case is different so that would not do anything.

It sounds like you're doing everything correctly but it's always better to post screens instead of text explanations. Maybe you have a rule out of place or something you overlooked. Post your NAT rule, WAN rule and firewall log with any public details obscured.

[maverickws]

@kom
Hi there thanks a lot for your reply.

So here's a screenshot of the Port Forward. The rule is automatically created based on this.

On the firewall I have most of the rules as floating rules. I don't have rules that stop evaluating after match. These are the rules:
Floating:

WAN:

States detail for this specific rule:

Firewall log:

On the firewall log, the destination IP is the WAN IP
And the sources are all listed on the provider_1 alias.
Port 5060 is also listed on the ports_1 alias. (I re-checked just to be sure)

[mcury]

Redirect ports you set an alias with IP address ?
Shouldn't it be ports_1 instead of lan_1 ?

[KOM]

@mcury ^ That exactly.

[maverickws]

@mcury you're correct on your observation. That was on me who was changing the alias names from the actual alias names and mistakenly wrote lan_1 instead of ports_1 there.
The ports_1 is now called SIP and I leave an up-to-date screenshot of the rule, specifically the part you mention

Edit: but to say, it was correct from before. the issue persists, that was not the cause.

[mcury]

hm, now it seems to be correct, are you using version 2.5.0?

There is a bug in version 2.5.0 that is triggered when you change the alias name, try putting the IP address instead of servers_pbx to test

[maverickws]

@mcury it was correct from the start, as I mentioned, I manually changed those fields for the screenshot, and made a mistake (I'm not particularly keen on disclosing the alias names in the wild, but heck with it...).
The redirect target port had the correct alias with the ports (actually iirc it only allows port alias on that field, couldn't be an IP alias it wouldn't be accepted).

I am using version 2.5.1
As per your suggestion I changed servers_pbx to the machine IP address, and tested, the issue persists.

[maverickws]

Well... please excuse dumb me.

The issue was the rule shouldn't have WAN address ... but instead ... CARP WAN VIP ... its fixed now.

Thank you for your time and for attempts to help! Have a nice day ahead!

[KOM]

@maverickws lol we never would have gotten that. No idea you were running CARP. That detail would be significant to mention for a problem involving inbound NAT.

[maverickws]

@kom yeah I completely overlooked that. I actually felt really dumb when it crossed my mind that the WAN address is that particular router address and not the outgoing address. I'm sorry for taking your time really, kudus for trying to help!!!