From owner-freebsd-net@FreeBSD.ORG Thu Nov 17 11:59:12 2011 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 3A83F106564A for ; Thu, 17 Nov 2011 11:59:12 +0000 (UTC) (envelope-from dynax60@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AB2998FC08 for ; Thu, 17 Nov 2011 11:59:11 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so2537331bkb.13 for ; Thu, 17 Nov 2011 03:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=RuIq75sCxBo8jJC+m8D8SXa76Bn0fdQCbFa3sF6qsw0=; b=wzwiZBUVF4O299LA8YC9ffp4dIMQVfXmrXEBsA3m3+Y8IcefhqpIeyjdFg0vOGFpxT wHxDxwvpSSBAjeowZ8XAm0NBPYK6QDFmDtOC1j+AtRYbqiEH1aN9ZJMufy5N4VmNqp+U 8g72dmZvV/jTWvviCI44wMoMB3p3NftuSa+EE= Received: by 10.205.139.71 with SMTP id iv7mr27821163bkc.60.1321529558782; Thu, 17 Nov 2011 03:32:38 -0800 (PST) Received: from [192.168.150.201] (r-msk-mar.nexo.ru. [213.152.136.229]) by mx.google.com with ESMTPS id o7sm31070143bkw.16.2011.11.17.03.32.36 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 03:32:37 -0800 (PST) Message-ID: <4EC4F0CE.3050002@gmail.com> Date: Thu, 17 Nov 2011 15:32:30 +0400 From: "Denis S.Davydov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Strange issue with the encapsulation of gre into ipip protocol (FreeBSD 8.2) 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: Thu, 17 Nov 2011 11:59:12 -0000 Good day! I have the IPSec-connection with a some company: X.X.X.X - my IPSec-peer (real ipaddress) A.A.A.A - service for the mobile terminals (real ipaddress) Y.Y.Y.Y - remote IPSec-peer (real ipaddress) Z.Z.Z.Z - remote GRE gateway (real ipaddress) 10.0.0.0/24 - remote the mobile terminal's network beyond the gre on Z.Z.Z.Z. Objective: The mobile terminals from network 10.0.0.0/24 must have an access to A.A.A.A via my router. Remote private network is beyond the GRE-tunnel (without private subnet /30, they do route via gre interface directly), GRE tunnel must be accessed via IPSec on Y.Y.Y.Y. So the scheme: tcp->gre->ipip->esp. I have no idea why there's a double-encapsulation - this is a requirements of the remote side. /etc/rc.conf: gif_interfaces="gif0" static_routes="vpn0" cloned_interfaces="gre0" gifconfig_gif0="X.X.X.X Y.Y.Y.Y" ifconfig_gre0="tunnel X.X.X.X Z.Z.Z.Z" route_vpn0="10.0.0.0/24 -interface gre0" /usr/local/etc/racoon/setkey.conf: flush; spdflush; spdadd X.X.X.X/32[any] Z.Z.Z.Z/32[any] 47 -P out ipsec esp/tunnel/X.X.X.X-Y.Y.Y.Y/unique; spdadd Z.Z.Z.Z/32[any] X.X.X.X/32[any] 47 -P in ipsec esp/tunnel/Y.Y.Y.Y-X.X.X.X/unique; /usr/local/etc/racoon/racoon.conf: remote Y.Y.Y.Y [500] { exchange_mode main; doi ipsec_doi; situation identity_only; nonce_size 16; initial_contact on; support_proxy on; proposal_check obey; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; lifetime time 600 sec; dh_group 2; } } sainfo address X.X.X.X/32 47 address Z.Z.Z.Z/32 47 { pfs_group 2; encryption_algorithm 3des; authentication_algorithm hmac_sha1; compression_algorithm deflate; lifetime time 3600 sec; } # ifconfig gre0 gre0: flags=9051 metric 0 mtu 1476 tunnel inet X.X.X.X --> Y.Y.Y.Y # ifconfig gif0 gif0: flags=8051 metric 0 mtu 1280 tunnel inet X.X.X.X --> Z.Z.Z.Z options=1 # netstat -rn | grep gre 10.0.0.0/24 gre0 US 0 4191 gre0 So, it's like a terminals are trying to work, but I noticed strange traffic on enc0 interface: 10:27:58.028806 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 48: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [S], seq 14633856, win 32120, options [[|tcp] (ipip-proto-4) 10:27:58.029544 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 48: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [S.], seq 1966363414, ack 14633857, win 8192, options [mss 1460], length 0 10:27:58.029552 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Y.Y.Y.Y: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 48: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [S.], seq 1966363414, ack 14633857, win 8192, options [[|tcp] (ipip-proto-4) 10:27:58.628570 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 44: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [.], ack 1, win 32120, length 0 (ipip-proto-4) 10:28:00.829033 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 137: IP 10.0.0.1.7337 > A.A.A.A.9990: Flags [FSRP.W], seq 667402656:667402725, ack 2153916852, win 64615, options [[|tcp] (ipip-proto-4) 10:28:08.622620 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [F.], seq 1, ack 1, win 64240, length 0 10:28:08.622632 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Y.Y.Y.Y: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [F.], seq 1, ack 1, win 64240, length 0 (ipip-proto-4) 10:28:09.808942 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 44: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [.], ack 2, win 32120, length 0 (ipip-proto-4) 10:28:10.449265 (authentic,confidential): SPI 0x0d640bcb: IP Y.Y.Y.Y > X.X.X.X: IP Z.Z.Z.Z > X.X.X.X: GREv0, length 137: IP 10.0.0.1.7337 > A.A.A.A.10008: Flags [P.], ack 1, win 32120, length 93 (ipip-proto-4) 10:28:10.449672 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [R.], seq 2, ack 94, win 0, length 0 10:28:10.449679 (authentic,confidential): SPI 0x9e06a435: IP X.X.X.X > Y.Y.Y.Y: IP X.X.X.X > Z.Z.Z.Z: GREv0, length 44: IP A.A.A.A.10008 > 10.0.0.1.7337: Flags [R.], seq 2, ack 94, win 0, length 0 (ipip-proto-4) It is not clear to me why the first gre packet response from A.A.A.A is not encapsulated into ipip protocol and sent directly to Z.Z.Z.Z (via esp protocol), and the next gre packet with the same ack-id normally encapsulated into IPIP for sending it to the peer Y.Y.Y.Y? Where I'm wrong? FreeBSD 8.2. -- Kind regards, Dennis