Sure, fixed it.

Fixed it.

I'm not sure if this would work, but here it is.

Line 187 and 188 have exactly the same match, so only 187 is invoked. 188 will never be used. Furthermore they are only outgoing (for aliasing), they do not match incoming packets (for dealiasing)

I'd prefer a function witch return the valid port number or 0 in the case of failure. Writable pointers in arguments open a special class of worms in debugging.

Did you try "12345six" as a port number?

Did try "7654321" as a port number?

Is this case already covered by the validation functions? If yes, remove those check.

Using a other type of function call this would be

(0 < (hp = nat_port_...(av[1])))

which is easier to audit.

So PKT_ALIAS_SAME_PORT is incompatible with port ranges?
Can we prevent setting both flags with an error message in parsing the config?

How about a stuct and a single enty in the record?

struct nat_port_range {
  u_short lower, upper;
};

and

struct nat_port_range portRange;

Here the struct can be reused.

Using a stuct the lines become

ptr->portRange = ucfg->portRange;

The common idiom is to provide a pointer as the second argument ti strtol and inspect the (first unparsable) char it points to afterwards.

port = strtol(ptr, ptr2, 10);
if ( *ptr2 != '\0' || port < 1024 )
  error

u_short comparsion with MAX_USHORT is not recommended.

Given the fact, that the upper limit is one above the usable range, this can't be specified, because the port number to configure is out of range. So it might be advisable to redefine the upper limit to be part of the interval (2000 2999 instead of 2000 3000).

Why not take the (pointer to the) struct as argument?

The pointer end will always be != NULL, so you may even allow port numbers below 1024.

No no. The concern is only valid as long as the documentation about the half open interval was missing. The configuration you need (using half open intervals) is 2000 3000 and 3000 4000 in order to match the port ranges in lines 187-188 below.

It looks like that will still get through, since the cast will convert it to 52145 (the C standard defines this conversion, although it is not what is wanted here).

I suggest storing the result from strtol() in a variable of type long and doing range checks on that.

long is indeed better than any unsigned type, because it would catch negative numbers easily.

Given we're defining port range here, wouldn't the port_range be a bit more relevant name here?

Why do we need to check for both lower and upper in fast path?

That's not true any longer. The interval is closed now, it includes the end points.

Why parsing from again from the very beginning of the string?

In terms of performance, it would be interesting to replace "Upper" with a precomputed "Range" or "Length". This part is used for ever new flow (very often).

For printing the configuration, the "Upper" value an be synthesized on demand.

You also need to have a line break after a sentence stop here.

There's some extraneous whitespace here.

and here.

Line length.

'You need' (missing 'e'), and line length.

Line length, and small inconsistency in that some errors have their first word capitalised and some don't.