Project

General

Profile

Actions

Bug #3999

closed

SRC, GW wrong in pftop on 2.2

Added by Chris Buechler almost 10 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
Start date:
11/10/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:

Description

In 2.1x and previous versions, the GW field in pftop showed the IP:port of the NAT applied to the connection, the src as the original internal source and the destination as the original destination.

For instance, where internal host 10.0.4.4 has a HTTPS connection up to Apple @ 17.172.239.115, NATed to public IP 18.2.3.4, in 2.1x you'd get:

PR           DIR SRC                        DEST                        GW                             
tcp       Out 10.0.4.4:52018          17.172.239.115:443       18.2.3.4:23961     

In 2.2, that ends up being:

PR           DIR SRC                        DEST                        GW                             
tcp       Out 18.2.3.4:23961            17.172.239.115:443       10.0.4.4:52018

Actions #1

Updated by Renato Botelho almost 10 years ago

I took a quick look at it, and looks like it is also broken on stock FreeBSD (not tested to confirm). Looks like the issue is in the following block of pftop.c, but I don't know enough pf internals to be sure about how to fix:

   1126 #ifdef HAVE_PFSYNC_KEY
   1127         if (s->direction == PF_OUT) {
   1128                 print_fld_host2(FLD_SRC, &s->key[PF_SK_WIRE],
   1129                     &s->key[PF_SK_STACK], 1, s->af);
   1130                 print_fld_host2(FLD_DEST, &s->key[PF_SK_WIRE],
   1131                     &s->key[PF_SK_STACK], 0, s->af);
   1132         } else {
   1133                 print_fld_host2(FLD_SRC, &s->key[PF_SK_STACK],
   1134                     &s->key[PF_SK_WIRE], 0, s->af);
   1135                 print_fld_host2(FLD_DEST, &s->key[PF_SK_STACK],
   1136                     &s->key[PF_SK_WIRE], 1, s->af);
   1137         }
   1138 #else
Actions #2

Updated by Ermal Luçi almost 10 years ago

  • Status changed from New to Closed

This is not a bug or problem.

Interal structures in pf make this be displayed this way.

Actions

Also available in: Atom PDF