[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pf + enc



Daniel Hartmeier wrote:

>On Wed, Jul 17, 2002 at 04:13:22PM -0300, Cedric Berger wrote:
>
>  
>
>>This is not the best possible design, but if you know what to do, it works.
>>There is also a chicked-or-egg-first problem when handling rules like
>>"nat on enc0" or "rdr on enc0", which could only be solved properly by
>>having the NAT code talking with the IPSec policy layer for deciding
>>if an outgoing packet should or shouldn't be nat'd.
>>    
>>
>
>Thanks for your explanation, which matches all my observations so far.
>
>You can possibly solve the nat/rdr issue by specifying the protocol the
>translation rule should apply to, assuming this singles out the pass
>through the enc interface you want to translate.
>
Ok, let's take an example: I've an encrypted link between 2 companies,
with an IPSec transport mode (not tunnel) between the following IPs:
Company A: 62.1.1.1
Company B: 65.2.2.2

I work on company A, and want to redirect encrypted connection on
port 80 to my intranet webserver. so I write:

  rdr on enc0 from 65.2.2.2 to 62.1.1.1 port 80 -> 192.168.1.1 port 80

Now when packets are decrypted by IPSec, they are processed through
the enc0 interface, and PF can kick in and do its job. no problem.

But when the response from my 192.168.1.1 webserver comes back to my
OpenBSD, here comes the problem.

The IPSec database says that it should encrypt packets from
192.168.1.1 to 65.2.2.2 but the response from the webserver
is a packet from 192.168.1.1 to 65.2.2.2, which does not match
any entry in the IPSec database. So IPSec decide not to process
the packet, so it is not fed into the enc0 interface, and therefore
not processed by the NAT before encryption.

Well, thinking about it, maybee it IS processed by NAT, since PF
does not (yet?) bind state to interfaces. In any case, if Company B
decide to use the tunnel for all it's 192.168.1/24  network and write:

  nat on enc0 from 192.168.1.0/24 to 62.1.1.1 port 80 -> 65.2.2.2

Outgoing packet will not be processed by IPSec. This is where the
chicken-and-egg problem is. NAT and IPSec need to take
the decision of whether processing an outgoing packet through the
enc0 interface together, maybee by trial-and-error.

I've solved this problem by running the following background thread,
in addition to isakmpd. yes, I know, this is very ugly...

Note also that this particular settings could not be achieved by using
"tunnel mode", since both company A and B use the same internal
network.
Cedric



#!/bin/sh
#
# (C) 2001-2001 Wireless Networks, Inc.
#
while true; do
  PEERS=`netstat -nrf encap | awk 
'/\/32[^\/]+\/32[^\/]+\/50\/require\/out/ {print 
substr($3,1,index($3,"/")-1)}' | sort -u`
  for PEER in $PEERS; do
   if (netstat -nrf encap | grep '0/0' | grep "$PEER" | grep 
"50/require/out" >/dev/null); then
        true
    else
        ipsecadm flow -addr 0.0.0.0 0.0.0.0 $PEER 255.255.255.255 -dst 
$PEER -proto esp -out -require
   fi
  done
  PEERS=`netstat -nrf encap | awk 
'/0\/0[^\/]+\/32[^\/]+\/50\/require\/out/ {print 
substr($3,1,index($3,"/")-1)}' | sort -u`
  for PEER in $PEERS; do
   if (netstat -nrf encap | grep -v '0/0' | grep "$PEER" | grep 
"50/require/out" >/dev/null); then
        true
    else
        ipsecadm flow -addr 0.0.0.0 0.0.0.0 $PEER 255.255.255.255 -delete
    fi
   done
   sleep 60
done