Project

General

Profile

Actions
Copy link

Bug #16169

closed

NAT64 states have ``src`` and ``dst`` swapped in data returned by pfSense PHP Module

Added by Jim Pingle 6 days ago. Updated 1 day ago.

Status:
Resolved
Priority:
Normal
Assignee:
Kristof Provost
Category:
Rules / NAT
Target version:
2.8.0
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
25.03
Release Notes:
Force Exclusion
Affected Version:
Affected Architecture:

Description

There appears to be a bug in NAT64 state data retrieval via the pfSense PHP module. It has the post-NAT source and destination swapped.

For example, sending a ping with the following parameters:

  • Client IPv6 address: 2001:db8:1:eea1:aaea:2bfd:d3ba:dca7
  • Original Destination: 64:ff9b::8c52:7204
  • Firewall WAN IPv4 address: 198.51.100.126
  • IPv4 translated destination: 140.82.114.4

The pfctl output is correct:

vtnet0 ipv6-icmp 198.51.100.126:27558 (2001:db8:1:eea1:aaea:2bfd:d3ba:dca7[27558]) -> 140.82.114.4:8 (64:ff9b::8c52:7204[27558])       NO_TRAFFIC:NO_TRAFFIC
   age 00:05:30, expires in 00:00:09, 660:660 pkts, 62040:62040 bytes, rule 111
   id: 1642116800000000 creatorid: 93290321
   origif: vtnet2

The GUI states output has the post-NAT source and destination swapped::

140.82.114.4:8 (2001:db8:1:eea1:aaea:2bfd:d3ba:dca7[27558]) -> 198.51.100.126:27558 (64:ff9b::8c52:7204[27558])

The data returned by pfSense_get_pf_states() also shows the src and dst swapped:

  array(21) {
    ["if"]=>
    string(6) "vtnet0" 
    ["origif"]=>
    string(6) "vtnet2" 
    ["rt_ifname"]=>
    string(0) "" 
    ["proto"]=>
    string(9) "ipv6-icmp" 
    ["direction"]=>
    string(2) "in" 
    ["dst"]=>
    string(20) "198.51.100.126:27558" 
    ["dst-orig"]=>
    string(25) "64:ff9b::8c52:7204[27558]" 
    ["src"]=>
    string(14) "140.82.114.4:8" 
    ["src-orig"]=>
    string(42) "2001:db8:1:eea1:aaea:2bfd:d3ba:dca7[27558]" 
    ["state"]=>
    string(21) "NO_TRAFFIC:NO_TRAFFIC" 
    ["age"]=>
    string(8) "00:05:18" 
    ["expires in"]=>
    string(8) "00:00:09" 
    ["packets total"]=>
    float(1272)
    ["packets in"]=>
    float(636)
    ["packets out"]=>
    float(636)
    ["bytes total"]=>
    float(119568)
    ["bytes in"]=>
    float(59784)
    ["bytes out"]=>
    float(59784)
    ["rule"]=>
    int(111)
    ["id"]=>
    string(16) "1642116800000000" 
    ["creatorid"]=>
    string(8) "93290321" 
  }

The data appears to be correct for non-NAT64 states, so the problem appears to be isolated to only NAT64 states.

Actions
Copy link
 #1

Updated by Jim Pingle 6 days ago

  • Description updated (diff)
Actions
Copy link
 #2

Updated by Kristof Provost 5 days ago

  • Status changed from Confirmed to Ready To Test
  • Assignee set to Kristof Provost

It turns out that for nat64 we need to swap the wire information. That's a little odd, but it's what pfctl does (both for us and for OpenBSD), so we'll just do the same in the module.
I've pushed that to both devel and plus-devel branches.

We should validate it there and then decide if it's something we want to cherry-pick to 2.8.0 and 25.03. It's a relatively small and safe change, but it's also fairly late in the release process.

Actions
Copy link
 #3

Updated by Jim Pingle 4 days ago

  • Status changed from Ready To Test to In Progress
  • % Done changed from 0 to 50

It's closer but now the entire src+src-orig and dst+dst-orig are swapped in the module, but each pair is consistent at least.

The pfctl output is still correct:

vtnet0 ipv6-icmp 198.51.100.126:49223 (2001:db8:1:eea1:ae5e:65a:f030:fa99[49223]) -> 203.0.113.5:8 (64:ff9b::cb00:7105[49223])       NO_TRAFFIC:NO_TRAFFIC
   age 00:02:35, expires in 00:00:10, 310:310 pkts, 29140:29140 bytes, rule 111
   id: e9bf146800000000 creatorid: 93290321
   origif: vtnet2

GUI:

WAN 203.0.113.5:8 (64:ff9b::cb00:7105[49223]) -> 198.51.100.126:49223 (2001:db8:1:eea1:ae5e:65a:f030:fa99[49223])

Data from module:

  array(21) {
    ["if"]=>
    string(6) "vtnet0" 
    ["origif"]=>
    string(6) "vtnet2" 
    ["rt_ifname"]=>
    string(0) "" 
    ["proto"]=>
    string(9) "ipv6-icmp" 
    ["direction"]=>
    string(2) "in" 
    ["dst"]=>
    string(20) "198.51.100.126:49223" 
    ["dst-orig"]=>
    string(41) "2001:db8:1:eea1:ae5e:65a:f030:fa99[49223]" 
    ["src"]=>
    string(13) "203.0.113.5:8" 
    ["src-orig"]=>
    string(25) "64:ff9b::cb00:7105[49223]" 
    ["state"]=>
    string(21) "NO_TRAFFIC:NO_TRAFFIC" 
    ["age"]=>
    string(8) "00:01:19" 
    ["expires in"]=>
    string(8) "00:00:10" 
    ["packets total"]=>
    float(320)
    ["packets in"]=>
    float(160)
    ["packets out"]=>
    float(160)
    ["bytes total"]=>
    float(30080)
    ["bytes in"]=>
    float(15040)
    ["bytes out"]=>
    float(15040)
    ["rule"]=>
    int(111)
    ["id"]=>
    string(16) "e9bf146800000000" 
    ["creatorid"]=>
    string(8) "93290321" 
  }

The source should be the 198 and 2001 addresses. The destination should be the 203 and 64:ff9b addresses.

Actions
Copy link
 #4

Updated by Jim Pingle 4 days ago

  • Status changed from In Progress to Feedback
  • % Done changed from 50 to 100

Kristof gave me a test module to try and it worked, so the latest commit should solve it. Will re-test once that's in a snapshot.

Actions
Copy link
 #5

Updated by Jim Pingle 1 day ago

  • Status changed from Feedback to Resolved

Latest snapshot it working as expected. The fix has been picked back to 25.03/2.8.0 branches as well but isn't in a build yet, should be soon.

Actions
Copy link

Also available in: Atom PDF