Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Aug 2007 10:15:22 +0200
From:      Eric Masson <emss@free.fr>
To:        Mailing List FreeBSD Network <freebsd-net@FreeBSD.org>
Subject:   pf rdr statement & ipsec processing interaction
Message-ID:  <867inzn945.fsf@srvbsdnanssv.interne.kisoft-services.com>

next in thread | raw e-mail | index | archive | help
Hello,

I'm trying to setup a FreeBSD 6.2 box as l2tp/ipsec server for MS
workstations (FAST_IPSEC + Yvan's NAT-T patch)

Thanks to mpd4, the l2tp part works fine, as the box could in fine have
only a dynamic ip address, I've made mpd listen on a loopback interface
on the box and then redirected incoming l2tp traffic to this loopback
interface :

$ ifconfig lo1
lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 10.127.0.1 netmask 0xff000000

$ cat /usr/local/etc/mpd4/mpd.links
l2tp1:
        set link type l2tp
        set l2tp self 10.127.0.1
        set l2tp enable incoming
        set l2tp disable originate

$ cat /etc/pf.conf
ext_if="vxn0"
rdr on $ext_if proto udp from any to ($ext_if) port 1701 -> 10.127.0.1 port 1701

If ipsec isn't enabled (no spd & no racoon running on the freebsd side,
ipsec disabled on the xp box), this setup works fine.

If ipsec is enabled on the box and on the xp box, phase I & phase II
succeed but mpd4 doesn't get any l2tp packet.

If I setup mpd4 to listen on the external interface address and disable
pf rdr rule, everything works fine (ipsec enabled or disabled)

>From this, it seems that pf rdr rule isn't applied to the incoming l2tp
packets once they've been ipsec processed.

Is this an expected behaviour or a bug ?

TIA

Regards

Éric Masson

-- 
 tenir à bout de bras un câble ethernet qui traverse une salle de restau
 pour pas qu'il tombe dans les tiramisu, pendant que d'autres parlent en
 infrarouge, c'est bien la vraie vie, n'est-ce pas ?
 -+- DA in Guide du Macounet Pervers : http://www.le-visconti.net/ -+-



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?867inzn945.fsf>