PF rdr bitmask BUG

[Max Laier]

On Tuesday 02 August 2005 12:57, Boris Polevoy wrote:
> Hello All!
>
> I have some problem with rdr rule in pf.
>
> Test configuration:
>
> +---------+                  +---------+                   +---------+
>
> |client   |192.168.3.10/24   |firewall |10.0.0.1/24        |server   |
> |     fxp0+----------------->+fxp0 fxp1+------------------>+fxp0     |
> |
> |         |    192.168.3.2/24|         |        10.0.0.2/24|         |
>
> +---------+    192.168.3.3/24+---------+        10.0.0.3/32+---------+
>
> client and firewall boxes under FreeBSD 5.4-RELEASE, server under FreeBSD
> 4.7-RELEASE. On firewall interface fxp0 have two aliases: 192.168.3.2/24
> 192.168.3.3/24, on server box fxp0 have aliases 10.0.0.2/24, 10.0.0.3/32
> for test redirection.
>
> Rules in pf on firewall:
>   rdr on fxp0 inet from any to 192.168.3.0/24 -> 10.0.0.0/24 bitmask
>   pass all
>
> Test command on client:
>   ping -c4 192.168.3.2
>
> Ping do not work, packets from firewall go to wrong addresses.
>
> I have add log print in pf code in function pf.c/pf_map_addr():
>
>   case PF_POOL_BITMASK:
>     #define QUAD_ADDR(_addr)                                \
>       ((uint8_t *) &(_addr))[0], ((uint8_t *) &(_addr))[1], \
>       ((uint8_t *) &(_addr))[2], ((uint8_t *) &(_addr))[3]
>
>     printf("raddr:<%u.%u.%u.%u> rmask:<%u.%u.%u.%u> saddr:<%u.%u.%u.%u>\n",
>            QUAD_ADDR(raddr->v4), QUAD_ADDR(rmask->v4),
> QUAD_ADDR(saddr->v4)); PF_POOLMASK(naddr, raddr, rmask, saddr, af);
>     printf("naddr:<%u.%u.%u.%u> \n", QUAD_ADDR(naddr->v4));
>     break;
>
> Log output show that _naddr_ after translation is 10.0.0.10, but I think it
> must be 10.0.0.2.
>
> It seems wrong call of pf_map_addr() in pf_get_translation(),
> instead destinations address used source address:
> case PF_RDR:
>         if (pf_map_addr(pd->af, r, saddr, naddr, NULL, sn))
>                 return (NULL);
>
> It must be                         vvvvv
>         if (pf_map_addr(pd->af, r, daddr, naddr, NULL, sn))
>                 return (NULL);
>
> It bug or not?

From a quick first look your analysis seems to be correct - according to 
pf.conf(5) bitmask should use the destination address for rdr.  However, the 
proposed fix will not work as it breaks (at least) the sticky address option.

Maybe it's easiest to fix the host part in pf_get_translation after the 
pf_map_addr call?  This would require some amount of code duplication, 
though.

I will be looking for a better fix during/after the weekend.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20050802/fe65b475/attachment.bin