Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Aug 2017 17:42:30 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Fongaboo <freebsd@fongaboo.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: STUMPED: Setting up OpenVPN server on FreeBSD (self.freebsd)
Message-ID:  <20170827164229.W23641@sola.nimnet.asn.au>
In-Reply-To: <mailman.1203.1503788746.74519.freebsd-questions@freebsd.org>
References:  <mailman.1203.1503788746.74519.freebsd-questions@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 690, Issue 7, Message: 2
On Sat, 26 Aug 2017 09:03:07 -0400 (EDT) Fongaboo <freebsd@fongaboo.com> wrote:

 > I'm following this tutorial:
 > 
 > https://www.digitalocean.com/community/tutorials/how-to-configure-and-connect-to-a-private-openvpn-server-on-freebsd-10-1
 > 
 > Trying this on an AWS instance first and then planning to try on a bare metal colo server.
 > 
 > OpenVPN client and daemon seem to be working, in terms of handshaking and 
 > connecting with each other. Problem is, no matter what I do, connected 
 > clients can't get out to the Internet through the server's gateway 
 > interface.
 > 
 > I've tried setting up NATD, like the tutorial instructs. I've tried 
 > enabling ipfw_nat as described in this comment:
 > 
 > https://www.digitalocean.com/community/tutorials/how-to-configure-and-connect-to-a-private-openvpn-server-on-freebsd-10-1?comment=40498
 > 
 > rc.conf (for NATD):
 > 
 > #enable firewall
 > firewall_enable="YES"
 > firewall_script="/usr/local/etc/ipfw.rules"
 > firewall_type="open"

I know next to nothing about OpenVPN - though the digitalocean tutorial 
looks pretty thorough on the surface - and absolutely nothing about AWS, 
but do know a bit about ipfw and friends.

Your changing of the default firewall_script from /etc/rc.firewall to 
"/usr/local/etc/ipfw.rules" suggests that you've been unfortunately 
illadvised by the still-dreadful IPFW section in the handbook, written 
by someone who uses ipfilter.  Rely on /etc/rc.firewall and ipfw(8) for 
accurate information on using ipfw.

I note that the digitalocean tute did not make that mistake, though it 
would be more up-to-date to use firewall_nat_enable rather than natd(8), 
however natd works as well as ever, if a bit more slowly (extra process)

So .. firewall_type="open" is a parameter to whatever firewall_script. 
/etc/rc.firewall uses that to generate an open firewall, i.e. inserting
'pass all from any to any', overriding the default 'deny all from any 
to any'.  You didn't show your ipfw.rules, but I doubt it parses 'open' 
as a parameter - so it would not be surprising if you were locked out.

 > gateway_enable="YES"
 > natd_enable="YES"
 > natd_interface="xn0"
 > natd_flags="-dynamic -m"
 > 
 > rc.conf (revised for ipfw_nat):
 > 
 > #enable firewall
 > firewall_enable="YES"
 > firewall_script="/usr/local/etc/ipfw.rules"
 > firewall_type="open"

Same problem here.  Comment out that firewall_script line to get the 
default, as shown in /etc/defaults/rc.conf

 > firewall_nat_enable="YES"
 > firewall_nat_interface="xn0"
 > 
 > gateway_enable="YES"

You'll likely need some firewall_nat_flags as well.  See rc.firewall for 
NAT setup (natd or firewall_nat) with 'open' or 'client' rulesets.

 > #natd_enable="YES"
 > #natd_interface="xn0"
 > #natd_flags="-dynamic -m"
 > 
 > *xn0 = external interface of the server
 > 
 > Neither config allows Internet access.

Try it with the default firewall_script, for a proper open firewall, 
that you can condition to suit once your VPN stuff is all working.  

pf is fine too of course, properly configured, but I hate seeing people 
quit using ipfw because of some truly bad advice from >10 years ago :(

As for this thread in general, it'd be really nice if people would not 
re-re-quote long messages including tcpdumps to add one-line comments, 
whether top- or bottom-posted - this digest was five times normal size.

cheers, Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170827164229.W23641>