From owner-freebsd-net@freebsd.org Wed Aug 24 14:02:02 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C53FFBC4C97 for ; Wed, 24 Aug 2016 14:02:02 +0000 (UTC) (envelope-from carl.hattingh@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91CB51950 for ; Wed, 24 Aug 2016 14:02:02 +0000 (UTC) (envelope-from carl.hattingh@gmail.com) Received: by mail-it0-x230.google.com with SMTP id x131so210671100ite.0 for ; Wed, 24 Aug 2016 07:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=7f8SqhGTaOGvlrAk/XO4yl0tQUnUJGSRlWjMIiEoeRY=; b=xCJernjCjYjOELH46p1UhZEe5WdQFt8xn+H5KQwI2mBpcO4KfFOSkw9tN3pO2LMZef r7WTsohNBFwnF8yXaCvDkUyD6ubhkk7telW/cAyqBHWVZ17ihug41LIEf02h7caQmVL0 DX2VBNGWpo3ms6V4BdAed06M0AwLlMbyzFpHSNGxmQa8j1SDNFCaG4ueaR75LoABMFj7 Ua2QGW34MFHbZ6AqZGdhcWZ2moGegy86UtiJh6lO7B9LzT5i5e6WSyE71CRO5PebIOjA wx7FSGEMZrsGlTKr9RxwkMYv7EdsmJfplci92ofdY/fTNqHTgA3EjqTC/LsAaipVwAlC snWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7f8SqhGTaOGvlrAk/XO4yl0tQUnUJGSRlWjMIiEoeRY=; b=YhH8uYWJIRDwh2loJ7TaQJp7SdpFjrddUgn/WEkoJaRgh6h0CriC2ZjqDyTsYtGSgp 9pqRn/pe8b4Fb/MBcN6L/WytiuBpXBBvRyj+2Hbxa+NHPYeS7hTzqPlHG1dXpNgWeGbh xeKHTuADeUxI6kFkCM/cVNhWGFId8VvRaCGOGj0T19Epopr9AuSKpxAlGQOirYl2sO3I p4PYfrnQzcQaYFgAN4i7ZKnrQC0DO3X1HRZ1xVJazZHz76+OE/euXqC2uGSqkTFodrbi NJyWKt0yVyCOoNeA9EDHQoXtb/OiWw7Joa86J7Z6PkzCGGM/YLRKfPYYyLxNCDaUbikC RFaw== X-Gm-Message-State: AEkoouvVJgfHB2HYYAq6Z5v6P5VDC5JJEyz8B0m5IIMfOiqQZJ/LSojQ2clsDhelzE/QvDAVy7R4PsKJHlyVrw== X-Received: by 10.107.188.69 with SMTP id m66mr4497665iof.1.1472047321752; Wed, 24 Aug 2016 07:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.123.23 with HTTP; Wed, 24 Aug 2016 07:02:01 -0700 (PDT) From: Carl Hattingh Date: Thu, 25 Aug 2016 00:02:01 +1000 Message-ID: Subject: Cannot access a couple websites To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 14:02:02 -0000 Hi We are experiencing a issue which has me rather stumped. We are using Freebsd 10.3-RELEASE-p7 under Hyper-V 2012 R2 as a firewall (pf), and are unable to browse to www.amazon.com and outlook.office365.com under certain circumstances. The FreeBSD firewall has three interfaces: hn0: public /30 with default route pointing to telco NTU device hn1: public /28 allocated from telco hn2: private /24 NAT is configured on hn0 to nat any outbound traffic to the interface address: nat on hn0 inet from hn2:network to any -> (hn0) In this circumstance, all browsing is fine. However, if we nat outbound traffic to an address in the /28 public range, we are unable to browse to www.amazon.com and outlook.office365.com as two examples. All other sites are fine. Further, if we add another seperate test VM into the /28 public subnet, the same issue occurs. In this situation, no nat is taking place, the firewall is simply routing traffic between the test vm (with a public IP) and the telco link. We are not seeing any traffic being blocked by the pf firewall; we log all dropped packets with "block return log (all)" Packet captures show the connection get up to negotiating the SSL/TLS parameters (server hello, certificate, certificate status) but then various TCP retransmissions and keep alive packets are sent from the webserver IP, and thats where it just sits until the browser times out. We are using a kernel with ALTQ enabled, and the issue occurs both when pf queues are configured and unconfigured. We host a few other services behind this firewall; no issues that we are aware of. Services are natted to addresses in the /28 range. Toggling scrub on/off also makes no difference. The telco is not interested; they claim the traceroutes are fine. (we do see return traffic) I also tried dropping the MTU on the test VM to 1460 with no luck. Has anyone got any ideas on what this could be? We'd be grateful for any assistance.