Date: Wed, 13 Nov 2019 22:13:23 +0100 From: =?UTF-8?Q?Morgan_Wesstr=c3=b6m?= <freebsd-database@pp.dyndns.biz> To: freebsd-pf@freebsd.org Subject: Re: NAT for use with OpenVPN Message-ID: <5fce41df-37fb-fc8c-be80-f47dfd0d04ad@pp.dyndns.biz> In-Reply-To: <CAMnCm8i46JOW-bGOutRyxUtJspeSkz4ZjfAQ=XGe_KtbeF387w@mail.gmail.com> References: <mailman.6.1573387200.62111.freebsd-pf@freebsd.org> <CAMnCm8gn3y7ai95%2BtkwdZs2qYndzQaNdpHev4ZdNLyd-bOY4iQ@mail.gmail.com> <0b13ae53-b211-ad2c-1447-225860f73d3a@pp.dyndns.biz> <CAMnCm8jZQi-UKm_-hF8WS0cofq0OWWP_d5No1AbOP8_KgQE5ZA@mail.gmail.com> <baa548e5-7dc3-05cf-0275-902d0193fc21@pp.dyndns.biz> <CAMnCm8iZ4iLJYOUFFpoTpF_=9xpG2=MN77xi%2BtGaSqumHeeqkQ@mail.gmail.com> <8ba7182d-8c4e-e10e-467b-6cf447490151@pp.dyndns.biz> <CAMnCm8gA_V1trdZtpidms54cmf4TL=R2BZ2MP52fJKrjndxtzA@mail.gmail.com> <fa9054ac-b22f-b873-0749-742b73100dba@pp.dyndns.biz> <CAMnCm8gN9aYgsJQYCuppGQ1M-YPwe1y7kaQCeEcDChrogsXj0w@mail.gmail.com> <b574e8e2-a921-99b8-2d2f-b3dc70341ce3@pp.dyndns.biz> <CAMnCm8gS40S27uOHYiKPp5E2hZhg=FknxTKxSsuH6vgOBD5Z9g@mail.gmail.com> <ef17181f-61b3-c2eb-9ebb-49e437ceea76@pp.dyndns.biz> <CAMnCm8hpTmww-pV%2BFbOcMJwk%2Bz1_bSs%2BcVJg5eu5zm84K8RPSA@mail.gmail.com> <cf52cc1b-c979-155c-604b-8918ac5fc2d6@pp.dyndns.biz> <CAMnCm8i46JOW-bGOutRyxUtJspeSkz4ZjfAQ=XGe_KtbeF387w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> |iptables --table nat --append POSTROUTING --out-interface eth0 -j > MASQUERADE As I understand iptables, this is the normal/only way to provide NAT for any subnet. > ||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 I wonder what their reference was. When you're using iptables you only have MASQUERADE to chose from. Even my 20 year old Netgear RT-314 did NAT without problems... > ||Comments? Well, I am concerned we couldn't identify what mechanism was responsible for the already working NAT for 192.168.1.0/24. We wouldn't want to end up with two competing mechanisms activated at the same time and the rule you added will provide NAT for 10.8.0.0/24 as well as 192.168.1.0/24 - the latter which was already working. There should be init scripts on that router to start all services. Maybe they can give a clue on what's going on and how Netgear choses to activate their services. Whatever you do, just verify that the router's admin interface is not accessible from the Internet after you've added your rules! /Morgan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5fce41df-37fb-fc8c-be80-f47dfd0d04ad>