"Destination Address" rule causes traffic to be blocked

[johndball]

When adding "Destination Address" in a firewall rule the traffic to that port is blocked. Once "Destination Address" is removed the traffic is successfully passed to the host.

Ideas for 9.1? I made a clone of the 7.4 hard drive and am putting that on our new hardware but what should I do whenever we upgrade back to 9.1? This current setup is causing issues.

[f1assistance]

Originally Posted by johndball

When adding "Destination Address" in a firewall rule the traffic to that port is blocked. Once "Destination Address" is removed the traffic is successfully passed to the host.

What are you attempting to do...what is the rule and where in the order of other rules does it exist?

[johndball]

I apologize, I mentioned in "Firewall" when it is in networking --> Port Forwards. It has been a long day.

Source interface : Any WAN
Protocol : TCP
Destination Port : 33390
Destination Address : 192.168.2.2

Rule is set to enable.

The rule doesn't work.

Upon removing "destination address" the rule works fine.

I'm also unable to determine what particular build revision I am running. Maybe this can help:
Build: 9.1.0~svn20111209r30408release9.1-1lenny

[dwasserman]

Dont understand, if you remove dest address where go the packets with dest port 33390? somewhere you have a rule 1:1 nat?

[sky-knight]

Port forward rules happen pre-NAT, the destination address flag is supposed to use the public address. The private address goes in the new destination field.

The firewall module happens post-NAT, so the destination address flag there will use the private address.

Also you cannot upgrade from 7.4 to current. Not unless you get under the hood and play with apt.

[dmorris]

Originally Posted by johndball

Destination Address : 192.168.2.2

Upon removing "destination address" the rule works fine.

So if you remove the matcher that specifies that the traffic should only match traffic to 192.168.2.2 then the traffic matches. This suggests to me that the traffic isn't destined to 192.168.2.2.
Where was the traffic destined to?

Also, where are you forwarding it to?

[johndball]

The forwarding rule I created in 9.1 matched exactly the forwarding rule I had in 7.4 before I moved up to 9.1. It worked in 7.4, it didn't work in 9.1.

The exact forwarding rule is as follows:
Source interface : Any WAN
Protocol : TCP
Destination Port : 33390
Destination Address : 192.168.2.2

Using SuperScan I port scanned my firewall. 33390 is closed. Upon removing "destination address" and port scanning 33390 is open AND I can RDP into that port (that is a custom RDP port).

Same thing with our DRAC. I cannot access the Dell Remote Access Card on ANY port unless destination address is removed from the forwarding rule.

These rules were created EXACTLY from 7.4 rules. I even pulled the hard drive that still had 7.4 on it out, plugged it into the old firewall, booted the damn thing, had two monitors side-by-side and compared my work. It is THE SAME in 7.4 and 9.1 but does not work in 9.1.

[sky-knight]

And? 7.4 allowed things that were broken. The rule you just listed as a port forward should have NEVER worked. The matching in the NAT engine must take place before NAT is performed.

The firewall module is different, as is the packet filter.

Please simply change destination address to reflect the public address you want translated, and use the new destination field to specify the correct internal address.

[johndball]

Hard to believe that since version 6 when I started using Untangle that this has been "broken" and it has suddenly caught up to me when I deployed version 9.1. Why does it work in 9.1 if I remove the destination field?

Can you post an example fowarding rule using this data:
I want to foward extenal (WAN) traffic coming in on TCP port 65123 to internal (LAN) host 192.168.1.1.

[sky-knight]

I just did

With port forward rules in advanced mode you want the following flags:

Destination Local or Destination Address (these define a prenat destination to match packets)
Protocol
Destination port

Those are the big three that I use on any forward rule, and always have, and they always work. A fourth is source interface, but that isn't always wanted or needed.

And I can pull out the ages old button too, I started with UT 5.1.

I'll say it once again, port forward rules must happen on pre-nat network sessions. The stuff in the drop downs that you're matching are the network session before the NAT engine changes anything. After all, you're configuring the NAT engine to CHANGE a specific bit of traffic, that traffic isn't bound for the internal address until AFTER that forward rule gets done with it so how can you match on it?

Now the FIREWALL rule that goes with that NAT entry will use destination address: internal IP. Because the rack sees traffic after NAT is done with it, so at that point the network session is actually destined for the internal address.