From owner-freebsd-pf@freebsd.org Wed Nov 13 16:03:35 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 E8F2B1B48ED for ; Wed, 13 Nov 2019 16:03:35 +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 47CqCp5XzYz4CDm for ; Wed, 13 Nov 2019 16:03:33 +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 xADG3UX4011161 for ; Wed, 13 Nov 2019 17:03:31 +0100 (CET) (envelope-from freebsd-database@pp.dyndns.biz) Subject: Re: NAT for use with OpenVPN References: <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 17:03:30 +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: 47CqCp5XzYz4CDm 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.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.37)[-0.368,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.04)[asn: 198203(-0.22), 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.61)[0.614,0]; DMARC_NA(0.00)[pp.dyndns.biz]; R_SPF_NA(0.00)[]; HFILTER_HELO_IP_A(1.00)[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)[]; 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: Wed, 13 Nov 2019 16:03:36 -0000 > # tcpdump -nvvi eth0 icmp > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size > 65535 bytes > 15:22:29.614953 IP (tos 0x0, ttl 62, id 5638, offset 0, flags [DF], > proto ICMP (1), length 84) >     10.8.0.8 > 8.8.8.8 : ICMP echo request, id 13, seq > 1, length 64 > Are you thinking that the ping should be coming from 192.168.1.200 (my > OpenVPN server machine)? If not, how else would you know whether the > address is being NATed? The packet is NATed when your Netgear router exchange the source ip address 10.8.0.8 with its own public external ip address 67.175.144.37. I you ping from any machine on your 192.168.1.0/24 subnet you will see those packets as "67.175.144.37 > 8.8.8.8" on your external interface regardless of what ip is the source on the LAN. This is what should've been the case also from 10.8.0.0/24 if the router was doing its job properly. If you listen with tcpdump on the internal interface, before NAT takes place, you will still see the original private ip addresses as source addresses. Private ip addresses (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) can't be routed on the Internet (RFC1918). NAT means that when your router receives a packet on its internal interface, destined for the Internet, with one of those private ip addresses in the source field, it exchanges it with its own external ip before forwarding it to your ISP. It then keeps a table of what internal ip communicates with what ip on the Internet. When a reply returns it's matched against this table and if the router finds that this packet is meant for a computer on your LAN it will now reverse the NAT procedure and exchange its external ip (which is now the destination address) with the correct internal ip and put the packet on your LAN. The reason you can't see pings from your internal ips to your external ip on the external interface is simply because those packets are never actually put on that interface physically. When those pings reach the internal interface, the ip stack in the router realizes that the ping is meant for itself and immediately responds on the internal interface. tcpdump listens to what's actually put on the physical interface and won't see those packets while listening on eth0. Everything you have shown me so far is consistent with our suspicion that the Netgear router only provides NAT for 192.168.1.0/24. I have only rudimentary knowledge of iptables but I'm convinced your problem will be solved if you can find a way to add a NAT rule for 10.8.0.0/24 or better yet, for any subnet existing on your LAN. /Morgan