From owner-freebsd-pf@freebsd.org Wed Nov 13 20:45:59 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 C46B71BB219 for ; Wed, 13 Nov 2019 20:45:59 +0000 (UTC) (envelope-from pestaub@gmail.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47CxTf5TXtz3Dvm for ; Wed, 13 Nov 2019 20:45:58 +0000 (UTC) (envelope-from pestaub@gmail.com) Received: by mail-vk1-xa30.google.com with SMTP id k19so909482vke.10 for ; Wed, 13 Nov 2019 12:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=staub-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pOmHeLzeXv6oE3afXTiQNBEYTFN39bMase8VVq3Cf6c=; b=yyxhcdOwVoe7tuXY/8gRzsNx/QCOPaeQiZSW3WJ5W4VOOi/W6ptyC1s53Q7Xl1woVO P1tJfYyGxHak1NqTAJFf4tFr56lNGPzzU0h7fh9t7rlWoVf6oqE0GVZ4rDhAzWSLAQ+3 9eMkQgFprnzUcIuYEWanCuhz15qlqaG0i/4Q3rmTGxNia0+Cbzrl2c3wbTwBB9BkhSKT I9bsUOaMeIHG52GLSC1WCME1ZPm6HQ2Y1oip7+Fz64y7Ri2daeeL19klBRB4Q/4Gk0IW X9kCm3OC4NZUVxBnvo2bsa4XdK96mkPgAX//sFMUaihB2BLaZWbNxz/29KGPvhE4mcS1 WNAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pOmHeLzeXv6oE3afXTiQNBEYTFN39bMase8VVq3Cf6c=; b=cVh1EKB8k11+MWJZ/ctUvMXKUi+ACMrdyFYQo5ieElm2BaKnJc0saK8ZweYiIufXmN WXJq3jtzwwz6idI4BZ5F6FEXABHCXYOaJV/wsLQK6ZkML2RZI+8/zOYeMiOj5LTIxIaC qJebg9PaVh6dnyMgom8AsDpjSC9wqI0g05QYG3o6bCB2bAd1G7zTBCjl7TgkZ0JDpLJF ugE2obTjLNJFIgxemDQJ4OS8w67Xve2OeeVMj9CT8tWen2wevsQROKh98I/ynSBIetQB FByZuhGIx1nIUknUGrDRNUtvQD+K3s8WvdO/DNr2elc4ClCHn+xap6ZrxSyaloa5P4hP L3mQ== X-Gm-Message-State: APjAAAW3ci49NmXV2LoW0S3RkDzdfQNrmiITfDLcVoISH71FF1NMkZDg cndlTrjuTlSPbeEjKE9qaGZnGSkLQ5L632OTxtzs+Ol0MCI= X-Google-Smtp-Source: APXvYqz6KnyzrPrDKv5Pi3SRdgEdT8O7NxXz2LJ6W1rbGofiwjtlieEGq4qWd0FbVofVQNX7nU02WL5EicIZKycT81o= X-Received: by 2002:ac5:ccdc:: with SMTP id j28mr2943840vkn.69.1573677957174; Wed, 13 Nov 2019 12:45:57 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Phil Staub Date: Wed, 13 Nov 2019 15:45:20 -0500 Message-ID: Subject: Re: NAT for use with OpenVPN To: =?UTF-8?Q?Morgan_Wesstr=C3=B6m?= Cc: freebsd-pf@freebsd.org X-Rspamd-Queue-Id: 47CxTf5TXtz3Dvm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=staub-us.20150623.gappssmtp.com header.s=20150623 header.b=yyxhcdOw; dmarc=none; spf=pass (mx1.freebsd.org: domain of pestaub@gmail.com designates 2607:f8b0:4864:20::a30 as permitted sender) smtp.mailfrom=pestaub@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[staub-us.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; DMARC_NA(0.00)[staub.us]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[staub-us.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[0.3.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; HTTP_TO_IP(1.00)[]; IP_SCORE(-2.79)[ip: (-9.56), ipnet: 2607:f8b0::/32(-2.33), asn: 15169(-1.99), country: US(-0.05)]; FORGED_SENDER(0.30)[phil@staub.us,pestaub@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[phil@staub.us,pestaub@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 20:45:59 -0000 I believe I'm getting close. I found a tutorial at https://www.howtoforge.com/nat_iptables ... that gives identifies a couple rules to enable IP Forwarding and Masquerading: iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERAD= E iptables --append FORWARD --in-interface eth1 -j ACCEPT This results in the following: # 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 MASQUERADE all -- anywhere anywhere # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination GUSTER tcp -- anywhere anywhere tcp dpt:80 GUSTER tcp -- anywhere anywhere tcp dpt:443 ACCEPT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain GUSTER (2 references) target prot opt source destination # I'm not sure about the ACCEPT rule. I think it might be too general, but I'll do some more research on that. I am now able to ping 8.8.8.8 from my phone, and I used 'whatismyip.com' to verify that it sees my router's public IP address. I also have a handle on where to put this so that it survives a router rebo= ot. One of the comments in another tutorial I was reading says that the MASQUERADE rule is resource intensive, but if I understand it correctly, the only alternative would be to put a specific rule in place for each client. I don't think I want to do that Comments? Phil On Wed, Nov 13, 2019 at 11:03 AM Morgan Wesstr=C3=B6m < freebsd-database@pp.dyndns.biz> wrote: > > # 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 > _______________________________________________ > freebsd-pf@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >