On Fri, May 25, 2007 at 07:20:13PM -0400, Andreas Wrede wrote:
> I am seeing packets bypassing a IPsec transport setup and getting  
> onto the wire as regular TCP packets, rather than ESP if they are  
> passed through either a pf or ipf NAT. The setup:
> 
> IPsec transport between two firewalls and GRE tunnel between the same  
> two firewalls. PF or IPF nat for local clients behind the fw.
> 
> setkey:
> add yy.yy.178.223 xx.xx.14.216 esp 1002 -E des-cbc "12345678";
> add xx.xx.14.216 yy.yy..178.223 esp 2001 -E des-cbc "12345678";
> spdadd yy.yy.178.223 xx.xx.14.216 any -P out ipsec esp/transport// 
> require;
> 
> if:
> gre91: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
>         tunnel inet xx.xx.178.223 --> yy.yy.14.216
>         inet 10.99.1.1 -> 192.168.6.10 netmask 0xffffffff
>         inet6 fe80::211:2fff:fe87:ff1%gre91 ->  prefixlen 64 scopeid  
> 0x6
> 
> pf.conf:
> ext_if="tlp0"
> nat on $ext_if from !($ext_if) -> ($ext_if:0)
> 
> from the xx.xx.178.223 machine, TCP connection to any port on the  
> yy.yy.14.216 are IPsec transported in ESP packets:
> 
> 18:38:45.690572 IP yy.yy.14.216 > xx.xx.178.223: ESP 
> (spi=0x000007d1,seq=0x1283)
> 18:38:45.904351 IP xx.xx.178.223 > yy.yy.14.216: ESP 
> (spi=0x000003ea,seq=0x139f)
> 18:38:45.904374 IP yy.yy.14.216 > xx.xx.178.223: ESP 
> (spi=0x000007d1,seq=0x1284)
> 
> If a machine on the 10.99.x.x network (ie. the private LAN behind the  
> xx.xx.178.223 fw) tries to connect any port on yy.yy.14.216, then the  
> traffic is not encapsulated with ESP:
> 
> 18:38:47.174469 IP xx.xx.178.223.52594 > yy.yy.14.216.9194: S  
> 334610734:334610734(0) win 65535 <mss 1460,nop,wscale  
> 0,nop,nop,timestamp 734343791 0,sackOK,eol>

Andreas,

I suspect that NAT happens after IPSec processing.  Your IPSec rules do
not match the packets w/ source in 10.99/16 when they enter your router.
After PF translates the packets, it is too late for IPSec processing.

Perhaps you can avoid NAT altogether by both adding a route on .178.223
to 10.99/16 with nexthop .14.216 and addressing .14.216 by its address
on the tunnel, 192.168.6.10.  In that way, the traffic from 10.99/16 to
.14.216 will go through the tunnel, and the encapsulated packets will
be transported in ESP packets as you expect.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24