NAT reflection issue using multiple ports in aliases - 1.2.3-RELEASE (FULL)



  • It seems that NAT reflection rules aren't generated correctly when using multiple ports in an alias. There are problems both with multiple separate ports and with port ranges (using a colon). In my scenario, the LAN host is running a web server on port 50000 that shows an ActiveX control, and the ActiveX control then makes socket connections to the same host on ports 41794 and 41795.

    At first, my alias consisted of a single port, and then a port range (50000, 41794:41795).  In this case, connections from outside, through the WAN worked perfectly, but connections from inside showed the ActiveX control in the web page, but the socket connections failed.

    Then I changed the alias so that it started with the port range, and ended with the single port. In this case when the web server was accessed from inside the LAN, this was displayed in the web browser:

    nc: port number invalid: 41794:41795

    It still worked fine from outside.

    I changed the alias to use three separate ports (the order was 41794, 50000, 41795). In this case it worked fine from outside. From inside, the web page loaded but the socket connections failed. This is what I saw in /tmp/rules.debug (real IPs replaced):

    rdr on vr1 proto tcp from any to 1.1.1.1 port { 41794 50000 41795 } -> 10.0.0.114

    Reflection redirects

    rdr on $lan proto tcp from any to 1.1.1.1 port { 41794 50000 41795 } -> 127.0.0.1 port 19004
    rdr on $lan proto tcp from any to 1.1.1.1 port { 41794 50000 41796 } -> 127.0.0.1 port 19005
    rdr on $lan proto tcp from any to 1.1.1.1 port { 41794 50000 41797 } -> 127.0.0.1 port 19006

    For some reason it seems to increment the last port no matter what it is. I saw that same behavior in my other tests, I just didn't copy it as that point, so I don't have it to paste.

    Finally, I stopped using the alias, and created two NAT port forwards; one for the 50000, and one for the port range of 41794 to 41795. This worked fine all around, and here are the rules generated in /tmp/rules.debug

    rdr on vr1 proto tcp from any to 1.1.1.1 port { 50000 } -> 10.0.0.114

    Reflection redirects

    rdr on $lan proto tcp from any to 1.1.1.1 port { 50000 } -> 127.0.0.1 port 19004

    rdr on vr1 proto tcp from any to 1.1.1.1 port 41794:41795 -> 10.0.0.114 port 41794:*

    Reflection redirects

    rdr on $lan proto tcp from any to 1.1.1.1 port { 41794 } -> 127.0.0.1 port 19005
    rdr on $lan proto tcp from any to 1.1.1.1 port { 41795 } -> 127.0.0.1 port 19006

    For now I'll just have to create the rules manually, but I would really prefer to be able to use aliases and have it work properly in the LAN. Any help is appreciated.



  • I hate to bump my own thread like this, but I think this might be a bug. Since I'm not knowledgeable enough to determine this for sure, I'd like to get the opinion of someone who knows better before trying to raise it as a real issue for the developers (I actually don't even know how to do that yet  :-[ ) Anyone?



  • I wouldn't bother opening a bug unless you verify this is also present in 2.0, since 1.2 is now effectively frozen.



  • Well that's fine, though I'd still like some input on the issue. Maybe there's a small modification I can make directly to the firewalls I manage to workaround this issue and allow me to use aliases as intended? I don't know enough about the underlying to components to start messing around with it myself.



  • I noticed that there's a thread about a similar topic/bug/feature in the version 2.0beta forum, in which one of the devs is trying to sort it out in the 2.0 development tree, though progress on this bug may be stalled due to a hardware failure on the build server recently - at least, I seem to recall.

    What prompted my memory on this is the  nc    output  line that you mention.



  • Would like to add, I've just upgraded from 1.2-RC3 to 1.2.3 and it's a nightmare. Without getting into details, NAT reflection appears broken and there are other stuff not working too well as well.



  • Your port alias wouldn't work with NAT reflection on current 2.0 snapshots either.  They may not even work with NAT reflection for anything but aliases for a single port.



  • Well it does seem that there is a definite issue here; what isn't clear to me is whether NAT reflection is supposed to work correctly with aliases (I think it is supposed to) and isn't, or whether it is not supported but doesn't properly report the incorrect input from the user (this doesn't seem likely given the problem).



  • NAT reflection doesn't seem to work here either, my NAT rules are also using aliases, have tried with IP addresses too but that didn't work either.


Log in to reply