# PF: How to display nat source address in pflog?



## aupanner (Jul 26, 2014)

I've been converting from my age-old IPFILTER ruleset to PF.  Aside from FreeBSD's old version (which should be noted in the man page, not just the handbook), PF is rather flexible and nice.

I've been watching the logs to make sure I converted things correctly.  Unfortunately there seems to be a big problem with the tcpdump output of pflog, namely that there seems no way to view the pre-natted IP address of a blocked request.

For example I disallow outgoing packets to the Microsoft Teredo IPv6 proxy.  In IPFILTER the logs show the natted host trying to send a packet outwards:

```
Jul 24 23:13:28 myfirewall ipmon[876]: 23:13:28.010715 sk0 @0:1 b nattedhost[10.12.12.25],52877 -> 94.245.121.251,3544 PR udp len 20 89 OUT
```

But with PF the original IP address is lost:

```
15:19:08.557680 IP myfirewall.domain.com.62199 > 94.245.121.253.3544: UDP, length 61
```

Is there a way to display the address of the natted host as with IPFILTER?  (Other than, of course, writing a whole set of duplicate rules on my internal interface blocking requests prior to the NAT on the external interface.)


----------



## aupanner (Jul 28, 2014)

It looks like a way to a solution may be pfsync which apparently will emit the NAT translations.  Usually pfsync is used to sync up a hot backup firewall.  You can configure it to exist without syncing to a device, but not with /etc/rc.d/pfsync.

Second problem is that tcpdump doesn't know how to look at pfsync devices like it does pflog devices.  

Once upon a time someone had some code to do this (http://lists.freebsd.org/pipermail/freebsd-pf/2011-January/005970.html), but that code is out of date for 9.X.

I'm somewhat perplexed that such a simple use case seems to be missing.


----------



## SirDice (Jul 29, 2014)

I would suggest blocking the traffic _before_ it hits the NAT. There's no point in having PF keep state for connections that are going to be blocked anyway.


----------



## aupanner (Jul 31, 2014)

I bit the bullet, did what SirDice suggests, and created an internal interface set of rules.  PF being able to store huge external tables of spammer ipaddrs is just too good to go back.


----------

