On 11/18/25 02:44, Alexandr Nedvedicky wrote:
Hello,

thank you for bug report with all details. I have not
tried to reproduce it yet will try to do it later this
week.

</snip>

Egress:
er8pro$ doas tcpdump -lni cnmac4 port domain
...
15:06:28.255337 2006:420:69:7:254e:c5cd:b280:7e0c.23782 >
64:ff9b::101:101.53: 63837+ [1au] A? google.ca.(38)
15:06:33.254922 55.44.33.161.23782 > 1.1.1.1.53: 63837+ [1au] A?
google.ca.(38) (DF)
15:06:33.267623 1.1.1.1.53 > 55.44.33.161.23782: 63837 1/0/1 A
142.250.73.99(54) (DF)
And here's how it looks from the LAN side:

er8pro$ doas tcpdump -lni cnmac5 port domain
...
15:13:20.331256 2006:420:69:7:254e:c5cd:b280:7e0c.48398 >
64:ff9b::101:101.53: 65486+ [1au] A? google.ca.(38)
15:13:25.327384 2006:420:69:7:254e:c5cd:b280:7e0c.48398 >
64:ff9b::101:101.53: 65486+ [1au] A? google.ca.(38)
15:13:25.341485 64:ff9b::101:101.53 >
2006:420:69:7:254e:c5cd:b280:7e0c.48398: 65486 1/0/1 A 142.250.73.67(54)
     looking at timestamps it looks like the packet dumps
     belong to two different attempts. So I can't tell if
     static-port actually keeps source port number same
     when doing NAT-64. If it is not too much for you
     can you just check if source port number is same
     before and after net? LAn and WAN interface?

the static-port option is handled here in pf_get_sport()
function, starting at line 179:

    179                  } else if (low == 0 && high == 0) {
    180                          key.port[sidx] = pd->nsport;
    181                          key.hash = pf_pkt_hash(key.af, key.proto, 
&key.addr[0],
    182                              &key.addr[1], key.port[0], key.port[1]);
    183                          if (pf_find_state_all(&key, dir, NULL) == 
NULL) {
    184                                  *nport = pd->nsport;
    185                                  return (0);
    186                          }
    187                  } else if (low == high) {
    188                          key.port[sidx] = htons(low);
    189                          key.hash = pf_pkt_hash(key.af, key.proto, 
&key.addr[0],
    190                              &key.addr[1], key.port[0], key.port[1]);
    191                          if (pf_find_state_all(&key, dir, NULL) == 
NULL) {
    192                                  *nport = htons(low);
    193                                  return (0);
    194                          }
    195                  } else {
    196                          u_int32_t tmp;
    197
    198                          if (low > high) {
    199                                  tmp = low;
    200                                  low = high;
    201                                  high = tmp;
    202                          }
    203                          /* low < high */

low and high are port arguments to pf_get_sport() if static-port
option is used, then both are zero. If no matching state exists
(pf_find_state_all() returns NULL). then we just let caller
to use source port number as found in inbound packet.

the code above seems correct at first glance. but I agree there is
something not quite right will try to take a look.

thanks and
regards
sashan

Hi Alexandr,

Thanks for the response! Yes I can confirm that static-port does actually work and keeps the source port number the same, it was an oversight including two different packet dumps, my apologies.

Egress:
$ doas tcpdump -lni cnmac4 port domain
tcpdump: listening on cnmac4, link-type EN10MB
13:10:00.211411 2006:420:69:7:b2b2:8c2a:320b.34187 > 64:ff9b::101:101.53: 30531+ [1au] A? google.ca.(38) 13:10:05.211315 55.44.33.161.34187 > 1.1.1.1.53: 30531+ [1au] A? google.ca.(38) (DF) 13:10:05.227329 1.1.1.1.53 > 55.44.33.161.34187: 30531 1/0/1 A 142.250.73.67(54) (DF)

Lan:
$ doas tcpdump -lni cnmac5 port domain
tcpdump: listening on cnmac5, link-type EN10MB
13:10:00.211261 2006:420:69:7:b2b2:8c2a:320b.34187 > 64:ff9b::101:101.53: 30531+ [1au] A? google.ca.(38) 13:10:05.211259 2006:420:69:7:b2b2:8c2a:320b.34187 > 64:ff9b::101:101.53: 30531+ [1au] A? google.ca.(38) 13:10:05.227385 64:ff9b::101:101.53 > 2006:420:69:7:b2b2:8c2a:320b.34187: 30531 1/0/1 A 142.250.73.67(54)


Jordan

Reply via email to