From owner-freebsd-pf@freebsd.org Tue Nov 12 15:02:46 2019 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 045C61B02A9 for ; Tue, 12 Nov 2019 15:02:46 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from keymaster.local (ns1.xn--wesstrm-f1a.se [IPv6:2a00:d880:5:1b9::8526]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "keymaster.pp.dyndns.biz", Issuer "keymaster.pp.dyndns.biz" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47C9w44z9Rz4dvq for ; Tue, 12 Nov 2019 15:02:43 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from [192.168.69.69] ([192.168.69.69]) by keymaster.local (8.15.2/8.15.2) with ESMTP id xACF2eSC006016 for ; Tue, 12 Nov 2019 16:02:41 +0100 (CET) (envelope-from freebsd-database@pp.dyndns.biz) Subject: Re: NAT for use with OpenVPN References: <1cebcd5e-d9ed-53db-2d01-c8794933d1c4@pp.dyndns.biz> <80ec074d-7a5d-7016-57e4-f607384d0e20@pp.dyndns.biz> <6bc9b8ce-3ab3-2b57-510d-67ace0a90259@pp.dyndns.biz> <30f8da8a-de96-f737-fef8-820c6ae2ed16@pp.dyndns.biz> <7f1fcc2d-4833-7fda-c181-a3d15b16f9ee@pp.dyndns.biz> To: freebsd-pf@freebsd.org From: =?UTF-8?Q?Morgan_Wesstr=c3=b6m?= Message-ID: <0b13ae53-b211-ad2c-1447-225860f73d3a@pp.dyndns.biz> Date: Tue, 12 Nov 2019 16:02:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47C9w44z9Rz4dvq X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-database@pp.dyndns.biz has no SPF policy when checking 2a00:d880:5:1b9::8526) smtp.mailfrom=freebsd-database@pp.dyndns.biz X-Spamd-Result: default: False [1.67 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.838,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.05)[asn: 198203(-0.26), country: NL(0.02)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.36)[0.356,0]; HFILTER_HELO_IP_A(1.00)[keymaster.local]; R_SPF_NA(0.00)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[keymaster.local]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:198203, ipnet:2a00:d880::/32, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[pp.dyndns.biz]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 15:02:46 -0000 > I understand what you're saying here. I had hoped this wouldn't be a > problem, since I didn't have a problem with the VPN in my old router, > though I agree that this is NOT the same configuration. NAT is usually only applied to packets arriving/departing on the physical external interface. When you access your external router ip from your LAN, no packets actually touch the physical interface but is only handled internally in the ip stack. I know there has been some SOHO routers on the market that had a setting to work around this but it violated a bunch of RFCs ofc. > The problem I have with this explanation is that when I connect to the > VPN from my phone with the WiFi turned off, it connects via an outside > IP that is NOT my local router. In this case, the ping of 8.8.8.8 still > fails. Ok, this is interesting. If I understood your previous post, from your vpn client you can ping everything on your local LAN up to and including the external ip of your router? This tells me that everything is correctly configured on your LAN, including the routing tables in your Netgear router. If the route was missing there you wouldn't get a reply from the router since it would have no idea where to send packets with a 10.8.0.0/24 destination. Right now my best guess is that your router only do NAT for the subnet directly attached to its LAN port (192.168.1.0/24) and just lets packets from 10.8.0.0/24 through without modification. Your ISP will promptly drop such packets. The only way to tell is if your router allows monitoring of the packets on its interfaces so we can check what source/destination ip addresses are present in the packets passing through it. You can verify on the FreeBSD machine that at least those ping packets leave it correctly with a source address of 10.8.0.5 (vpn client ip) and a destination address of 8.8.8.8. # tcpdump -ni em0 icmp > I certainly appreciate all your help on this! have definitely filled in > a lot of blanks in my knowledge. You're welcome, Phil. I've been using FreeBSD as my router/firewall for the past 15+ years but my knowledge is limited to things I experience in my own environment so it's not always that easy to help others. A general suggestion, if you have the time and interest to install and configure FreeBSD, you'd be better off to replace your Netgear router with a FreeBSD machine. The major benefit is that there will always be security updates available whereas Netgear and other SOHO manufacturers will abandon their products after a couple of years. You will also have all the tools available to monitor and analyse your traffic which will help you with troubleshooting. You also have the flexibility to install any software available for the platform and configure it to your own needs. If the command prompt is scary, there are a few graphical distributions that are based on FreeBSD, like pfSense for example. /Morgan