From owner-freebsd-net@FreeBSD.ORG Fri Feb 15 00:25:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BE7316A41B for ; Fri, 15 Feb 2008 00:25:35 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from shrew.net (206-223-169-85.beanfield.net [206.223.169.85]) by mx1.freebsd.org (Postfix) with ESMTP id 77C7C13C468 for ; Fri, 15 Feb 2008 00:25:35 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from localhost (wm-ca.hub.org [206.223.169.82]) by shrew.net (Postfix) with ESMTP id 33B0E79E510; Thu, 14 Feb 2008 18:25:35 -0600 (CST) Received: from shrew.net ([206.223.169.85]) by localhost (mx1.hub.org [206.223.169.82]) (amavisd-new, port 10024) with ESMTP id 09243-08; Fri, 15 Feb 2008 00:25:34 +0000 (UTC) Received: from hole.shrew.net (cpe-66-25-136-5.austin.res.rr.com [66.25.136.5]) by shrew.net (Postfix) with ESMTP id B339879E343; Thu, 14 Feb 2008 18:25:34 -0600 (CST) Received: from [10.22.200.30] ([10.22.200.30]) by hole.shrew.net (8.13.8/8.13.8) with ESMTP id m1F0PMqx009989; Thu, 14 Feb 2008 18:25:22 -0600 (CST) (envelope-from mgrooms@shrew.net) Message-ID: <47B4DBFF.6070207@shrew.net> Date: Thu, 14 Feb 2008 18:25:35 -0600 From: Matthew Grooms User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: nlandys@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: RE: PF firewall NAT and Windows IPSEC tunnel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2008 00:25:35 -0000 Nerius, This sounds like a DPD timeout. The Cisco VPN client or Cisco gateway is probably not configured to use NAT-T or you are blocking UDP port 4500. Using the static-port trick will help in some instances where a client doesn't support NAT-T, but it also prevents multiple clients behind the pf firewall from communicating with the same gateway simultaneously. If thats not the case then no big deal. If so, its best to just NAT UDP port 4500 outbound normally for Cisco clients unless the Cisco gateway has NAT-T disabled. In legacy IPsec fashion, the client will establish its IKE session on the standard UDP port 500 and then pass ESP transport packets. With NAT-T enabled, the client will initiate IKE on port 500 and then switch to port 4500 if NAT is detected. ESP packets will be encapsulated in UDP and passed on port 4500 as well which is easier for NAT firewalls to deal with. The client should also issue keep-alive packets to prevent firewall state from being culled. Without this, no traffic would be sent while the client is idle and pf would drop state after 60secs by default. udp.first 60s udp.single 30s udp.multiple 60s other.first 60s other.single 30s other.multiple 60s If you don't see traffic on port 4500 but you do see ESP traffic, the other thing to try would be to increase the state lifetime for UDP port 500 and ESP traffic. Assuming DPD is enabled on the Cisco gateway, this would help avoid state timeout so that the client has more time between sending or receiving notifications. ESP shouldn't be too troublesome as there are no ports to translate ... unless you have multiple clients behind the same firewall trying to talk to the same gateway. But thats what NAT-T is for. Hope this helps, -Matthew