From owner-freebsd-pf@freebsd.org Tue Nov 12 23:43:06 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 923951BEC9D for ; Tue, 12 Nov 2019 23:43:06 +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 47CPST3jsmz4HDj for ; Tue, 12 Nov 2019 23:43:05 +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 xACNh3IO007681 for ; Wed, 13 Nov 2019 00:43:03 +0100 (CET) (envelope-from freebsd-database@pp.dyndns.biz) Subject: Re: NAT for use with OpenVPN References: <6bc9b8ce-3ab3-2b57-510d-67ace0a90259@pp.dyndns.biz> <30f8da8a-de96-f737-fef8-820c6ae2ed16@pp.dyndns.biz> <7f1fcc2d-4833-7fda-c181-a3d15b16f9ee@pp.dyndns.biz> <0b13ae53-b211-ad2c-1447-225860f73d3a@pp.dyndns.biz> <8ba7182d-8c4e-e10e-467b-6cf447490151@pp.dyndns.biz> To: freebsd-pf@freebsd.org From: =?UTF-8?Q?Morgan_Wesstr=c3=b6m?= Message-ID: Date: Wed, 13 Nov 2019 00:43:03 +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: 8bit X-Rspamd-Queue-Id: 47CPST3jsmz4HDj 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 [2.13 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.789,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.04)[asn: 198203(-0.24), country: NL(0.02)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.76)[0.764,0]; HFILTER_HELO_IP_A(1.00)[keymaster.local]; R_SPF_NA(0.00)[]; DMARC_NA(0.00)[pp.dyndns.biz]; 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)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[keymaster.local]; 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 23:43:06 -0000 > Something else I just realized: You'll note the route from 10.8.0.0/24 > and 192.168.1.200. That's the static route I added > from the web interface.. Is that something you think would be needed? Absolutely. When your VPN clients try to access the Internet, the router will see outgoing packets with a source address of 10.8.0.x (remember the tcpdump?). When the reply comes back it will have a destination address of 10.8.0.x and your router needs to know where to send that packet. Since that subnet isn't connected to any of its interfaces the static route tells the router where to forward the packet, in this case to your FreeBSD machine. Your FreeBSD machine knows where that subnet is and will deliver the packet to the correct client. If the static route is missing in your router, it will try to forward the packet to its default gateway which is your ISPs upstream router. > # iptables -t nat -L > > The result is not exactly what I had expected: > > # iptables -t nat -L > Chain PREROUTING (policy ACCEPT) > target     prot opt source               destination > > Chain INPUT (policy ACCEPT) > target     prot opt source               destination > > Chain OUTPUT (policy ACCEPT) > target     prot opt source               destination > > Chain POSTROUTING (policy ACCEPT) > target     prot opt source               destination > # > > Looks like there *are* no natting rules. I wonder if they are using > something other than iptables? With my limited knowledge of iptables I tend to agree with you on this. Just typical it shouldn't be that easy. However, the iptables command was just picked by me from a google search. It might not be the correct syntax. Just out of curiosity - is tcpdump part of the Linux dist on that router? If it is we can see what happens to your VPN clients' pings and just confirm that the router doesn't do NAT on them. /Morgan