From owner-freebsd-questions Thu Nov 29 21:33:29 2001 Delivered-To: freebsd-questions@freebsd.org Received: from LKLDDC01.GARGANTUAN.COM (145bus8.tampabay.rr.com [24.94.145.8]) by hub.freebsd.org (Postfix) with ESMTP id 9D22237B416 for ; Thu, 29 Nov 2001 21:33:23 -0800 (PST) Received: by LKLDDC01.GARGANTUAN.COM with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 00:33:14 -0500 Message-ID: <1DA741CA6767A144BAA4F10012536C27A916@LKLDDC01.GARGANTUAN.COM> From: "Oliver, Michael W." To: 'Scott Nolde' , "H. Wade Minter" Cc: questions@FreeBSD.ORG Subject: RE: Allowing IPSec through FreeBSD/ipfw gateway Date: Fri, 30 Nov 2001 00:33:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You can't use AH behind a NAT firewall. When the packet is passed through NAT, the source IP address is altered to match your global IP address, but the AH is not altered, and therefore the destination (VPN Server) will dump the packet since there is a mis-match between the source IP of the packet, and the source IP specified in the AH. I have verified this action on several different VPN Servers (CheckPoint and Nortel Contivity, to name two). Sniff the LAN (and the outside NIC of your firewall, if possible) and you will see the source IP in the AH. To sum it up.... AH and NAT are like oil and water... In case you are interested, here are the rules that I use... They work like a champ... # Allow IPSec clients to run behind firewall # --- ISAKMP - allow key exchange over UDP 500 ${fwcmd} add pass udp from ${inet}:${imask} to any 500 in recv ${iif} ${fwcmd} add pass udp from ${oip} to any 500 out xmit ${oif} ${fwcmd} add pass udp from any 500 to ${inet}:${imask} in recv ${oif} ${fwcmd} add pass udp from any 500 to ${inet}:${imask} out xmit ${iif} # --- ESP - allow protocol 50 (ESP) for everyone ;-) ${fwcmd} add pass esp from any to any If at all possible, try NOT using AH... HTH..... =========== Michael Oliver > -----Original Message----- > From: Scott Nolde [mailto:scott@smnolde.com] > Sent: Thursday, November 29, 2001 9:35 AM > To: H. Wade Minter > Cc: questions@FreeBSD.ORG > Subject: Re: Allowing IPSec through FreeBSD/ipfw gateway > > > Make your rules simpler without degrading the effectiveness of your > firewall. I run natd on my firewall, but have these rules in > place before > the divert statement: > > ipfw allow ip from any to ${VPN} > ipfw allow ip from ${VPN} to any > > where ${VPN} is the other enpoint of the VPN server. > > Try that and then get a little tighter once you sniff the > traffic more. > > - Scott > > smacked into the keyboard previously by > owner-freebsd-questions@FreeBSD.ORG: > > >Date: Thu, 29 Nov 2001 08:49:07 -0500 (EST) > >From: H. Wade Minter > >To: questions@FreeBSD.ORG > >Subject: Allowing IPSec through FreeBSD/ipfw gateway > > > >Hello, > > > >I'm trying to connect two Linux FreeS/WAN IPSec machines > together. One > >lives out on the internet "at large", the other one is at > my home on my > >private subnet, behind a RELENG_4 firewall using ipfw. > > > >My attempt at IPSec rules is: > > # Attempt to allow IPSec > > $fwcmd add allow udp from any to any in > > $fwcmd add allow udp from any to any out > > $fwcmd add allow tcp from any to any 500 in recv $extdev > > $fwcmd add allow tcp from any to any 500 out recv $intdev > > $fwcmd add allow log esp from any to xxx.xxx.xxx.xxx out > > $fwcmd add allow log esp from xxx.xxx.xxx.xxx to any in > > $fwcmd add allow ah from any to xxx.xxx.xxx.xxx > > $fwcmd add allow ah from xxx.xxx.xxx.xxx to any > > > >Where xxx.xxx.xxx.xxx is the remote IPSec machine. These > rules ALMOST > >work. When I start the Linux IPSec, I see: > > > >[root@greenbay root]# ipsec auto --up ncwise-minter > >104 "ncwise-minter" #1: STATE_MAIN_I1: initiate > >106 "ncwise-minter" #1: STATE_MAIN_I2: from STATE_MAIN_I1; sent MI2, > >expecting MR2 > >108 "ncwise-minter" #1: STATE_MAIN_I3: from STATE_MAIN_I2; sent MI3, > >expecting MR3 > >004 "ncwise-minter" #1: STATE_MAIN_I4: ISAKMP SA established > >112 "ncwise-minter" #2: STATE_QUICK_I1: initiate > > > >And it hangs there. There's obviously one bit of traffic > I'm not allowing > >back through. Here's a tcpdump on the local end: > > > >08:41:46.810515 xxx.xxx.xxx.xxx.isakmp > > greenbay.lunenburg.org.isakmp: > >isakmp: phase 1 R ident: [|sa] (DF) > >08:41:46.822671 greenbay.lunenburg.org.isakmp > > xxx.xxx.xxx.xxx.isakmp: > >isakmp: phase 1 I ident: [|ke] (DF) > >08:41:46.835754 courthouse.lunenburg.org.domain > > >greenbay.lunenburg.org.32770: 55960 NXDomain* 0/1/0 (116) > >08:41:47.056608 xxx.xxx.xxx.xxx.isakmp > > greenbay.lunenburg.org.isakmp: > >isakmp: phase 1 R ident: [|ke] (DF) > >08:41:47.147461 greenbay.lunenburg.org.isakmp > > xxx.xxx.xxx.xxx.isakmp: > >isakmp: phase 1 I ident[E]: [|id] (DF) > >08:41:47.562387 xxx.xxx.xxx.xxx.isakmp > > greenbay.lunenburg.org.isakmp: > >isakmp: phase 1 R ident[E]: [|id] (DF) > >08:41:47.578860 greenbay.lunenburg.org.isakmp > > xxx.xxx.xxx.xxx.isakmp: > >isakmp: phase 2/others I oakley-quick[E]: [|hash] (DF) > >08:41:57.572463 greenbay.lunenburg.org.isakmp > > xxx.xxx.xxx.xxx.isakmp: > >isakmp: phase 2/others I oakley-quick[E]: [|hash] (DF) > > > >If anyone can point out the last little bit I need, I'd > appreciate it! > > > >--Wade > > > >-- > >Do your part in the fight against injustice. > >Free Dmitry Sklyarov! http://www.freesklyarov.org/ > >Fight the DMCA! http://www.anti-dmca.org/ > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-questions" in the body of the message > > > > Scott Nolde > GPG Key 0xD869AB48 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message