From owner-freebsd-stable Thu Jun 20 16:34:15 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.codeangels.com (monkey.codeangels.com [62.2.169.19]) by hub.freebsd.org (Postfix) with SMTP id BAFD037B40C for ; Thu, 20 Jun 2002 16:34:09 -0700 (PDT) Received: (qmail 14447 invoked from network); 20 Jun 2002 23:33:51 -0000 Received: from dclient80-218-0-19.hispeed.ch (HELO martinique) (80.218.0.19) by 192.168.5.19 with SMTP; 20 Jun 2002 23:33:51 -0000 Date: Fri, 21 Jun 2002 01:33:16 +0200 From: Kirill Alder-Ponazdyr To: freebsd-stable@FreeBSD.ORG Subject: IPFilter, NAT and IPSEC == possibly buggy combo ?? (4.6 Release) X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20020620233409.BAFD037B40C@hub.freebsd.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greetings, I just have discovered a problem in an environment with IPSEC, IPF and NAT. We have a following Intranet Setup: Network1 +-----+ Gateway +--- VPN ---+ Firewall +---+ Internet There is also another intranet network segment connected directly to firewall (It has 4 NICs), the Gateway and Firewall machines are FreeBSD 4.6 Release. The firewall is setup to NAT all requests to internet to its external interface IP. The VPN ESP Setup by itself functions perfectly (IPCOMP is broken, I had a bug submitted, but thats another story ) we can communicate between all machines in the intranet without problems. The NAT also works flawlessly for the machines in the segment connected directly to firewall. However, it does not work well for the machines which are on the network1. What happens is: ICMP requests are being mapped correctly to external address and come back (ping) so do UDP requests work (nslookup) but as soon as we try to establish a TCP communication (ftp or http) the following happens: Just few packets, at the beginning of the conversation get NATed, and from one certain point the NAT stops doing the translation thus sending the packets with the original client´s ip to the server (Which of course has no chance to send the answer). This is defenately a issue with the IPSEC, because we tried to disable the IPSEC alltogether and the problems went away. Here is a TCPDUMP of one such "broken" ftp session. The "client" is a client machine on the network1, the "server" is a server on the internet, the "fw_outside" is a external interface of the firewall. 00:44:46.389083 fw_outside.1036 > server.ftp: S 2363807445:2363807445(0) win 57344 (DF) 00:44:46.389664 server.ftp > fw_outside.1036: S 2838793422:2838793422(0) ack 2363807446 win 32240 (DF) 00:44:46.393088 fw_outside.1036 > server.ftp: . ack 1 win 57716 (DF) 00:44:46.468281 server.1581 > fw_outside.auth: S 2849027513:2849027513(0) win 32120 (DF) 00:44:46.468307 fw_outside.auth > server.1581: R 0:0(0) ack 2849027514 win 0 00:44:51.721576 server.1582 > fw_outside.auth: S 2846120631:2846120631(0) win 32120 (DF) 00:44:51.721635 fw_outside.auth > server.1582: R 0:0(0) ack 2846120632 win 0 00:44:51.723839 server.ftp > fw_outside.1036: P 1:74(73) ack 1 win 32240 (DF) 00:44:51.723858 client.1036 > server.ftp: R 2363807446:2363807446(0) win 0 00:44:54.721748 client.1036 > server.ftp: R 2363807446:2363807446(0) win 0 00:45:00.720570 client.1036 > server.ftp: R 2363807446:2363807446(0) win 0 00:45:12.718230 client.1036 > server.ftp: R 2363807446:2363807446(0) win 0 00:45:36.713540 client.1036 > server.ftp: R 2363807446:2363807446(0) win 0 The NAT statement is very simple: map dc0 from 192.168.0.0/16 to any -> 0/32 where dc0 is an external interface on the firewall. So, what is that ? A Bug ? A wrong config or a Feature ? Regards Kirill ----------------- Kirill Alder-Ponazdyr SGI / SUN UNIX Consultant Codeangels Solutions Phone : +41 43 844 90 10 Fax : +41 43 844 90 12 Mobile: +41 79 370 89 30 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message