Project

General

Profile

Bug #16169

Updated by Jim Pingle 6 days ago

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: 
 <pre> 
 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 
 </pre> 

 The GUI states output has the post-NAT source and destination swapped:: 
 <pre> 
 140.82.114.4:8 (2001:db8:1:eea1:aaea:2bfd:d3ba:dca7[27558]) -> 198.51.100.126:27558 (64:ff9b::8c52:7204[27558]) 
 </pre> 

 The data returned by @pfSense_get_pf_states()@ also shows the @src@ and @dst@ swapped: 
 <pre> 
   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" 
   } 
 </pre> 

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

Back