From owner-freebsd-questions@freebsd.org Wed Apr 24 07:46:01 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACE451590316 for ; Wed, 24 Apr 2019 07:46:01 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) (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 B672280CF6 for ; Wed, 24 Apr 2019 07:46:00 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-io1-f67.google.com with SMTP id r10so11061939ioc.8 for ; Wed, 24 Apr 2019 00:46:00 -0700 (PDT) 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=lLj2aZaVh6oPipi92/SAIsg0DqXPuP+4epxL6TJIyWk=; b=tGE41AYc6MFYfN1NfoXrrUQkHTEq1gek6Lzy2y3xqh0f6ZgEohD5q1E5uaD/jeUPK8 UT+e8gmEJgegY3rzN2FEn8IjD0rmLps/PgCz23k0LDqlX1Rpa36bxCtF0NLvlP19yDS/ tj9BwHv03YHd/hCeJiGtZqacMpKlER0qgX+9u/UQAi7HAz95jU3AxowDAXZk5mlYvhAp qPme9E3XZCV49f/DWmGPCljELz0xs2OGpmeb5nnDIphQob79quDtLz3WtTeHILMuEx8Y 2yqT6UjANj2ZA1Oq8vkS1PMCBrrFJ3EPVIcMiNxTCX7y+0uYRGDxRU0nCigRi92mr3XW cZcQ== X-Gm-Message-State: APjAAAWW4PDU2VWT/qCgGL6FF0H27L5EdcZoCtS6tdJK4BdVA85QbRBj cT4QQrOHDhEjAFOABFsT8zSYqbl9 X-Google-Smtp-Source: APXvYqzOB/2ctr1uQo9+d8OWOr4xlCmVlvYxvTS7Xkbr79YaMD3o0VL8RcJyharpIOAZqGl1Y0Y0cg== X-Received: by 2002:a6b:7601:: with SMTP id g1mr20932146iom.108.1556091953897; Wed, 24 Apr 2019 00:45:53 -0700 (PDT) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id d138sm8798242itc.15.2019.04.24.00.45.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Apr 2019 00:45:53 -0700 (PDT) Received: by mail-it1-f171.google.com with SMTP id y10so4660464itc.1 for ; Wed, 24 Apr 2019 00:45:53 -0700 (PDT) X-Received: by 2002:a24:5309:: with SMTP id n9mr5852905itb.11.1556091953168; Wed, 24 Apr 2019 00:45:53 -0700 (PDT) MIME-Version: 1.0 References: <0A8436BD-EFB8-4A54-B920-329096B89C5B@mail.sermon-archive.info> <3D10CD79-CAE0-419A-9197-745B1A88FA30@mail.sermon-archive.info> In-Reply-To: <3D10CD79-CAE0-419A-9197-745B1A88FA30@mail.sermon-archive.info> From: Richard Gallamore Date: Wed, 24 Apr 2019 00:45:42 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: openvpn To: Doug Hardie Cc: Karl Denninger , FreeBSD Mailing List X-Rspamd-Queue-Id: B672280CF6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of ultima1252@gmail.com designates 209.85.166.67 as permitted sender) smtp.mailfrom=ultima1252@gmail.com X-Spamd-Result: default: False [-3.22 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; RCVD_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+,1:+]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[67.166.85.209.list.dnswl.org : 127.0.5.0]; HTTP_TO_IP(1.00)[]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[ultima@freebsd.org,ultima1252@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[ultima@freebsd.org,ultima1252@gmail.com]; IP_SCORE(-1.24)[ipnet: 209.85.128.0/17(-3.88), asn: 15169(-2.27), country: US(-0.06)] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 07:46:02 -0000 Hello Doug, I am suspect of the system not being configured as a router, aka sysctl values should be set to net.inet.ip.forwarding: 1 and net.inet6.ip6.forwarding: 1 (for v6 traffic) to allow packets to be forwarded. If you add /etc/rc.conf, file /etc/sysctl.conf, /boot/loader.conf and pf.conf or ipfw configuration it will help greatly in understanding your configuration if this doesn't work. Best regards, Richard Gallamore On Tue, Apr 23, 2019 at 10:43 PM Doug Hardie wrote: > > On 23 April 2019, at 19:16, Karl Denninger wrote: > > > > > > On 4/22/2019 19:53, Doug Hardie wrote: > >> I am trying to setup an openvpn server on my home network. Home > machines are all running FBSD 12.0 Release. openvpn was installed as a > package. The results are quite confusing. Ping from an external device > works correctly to all the home machines. I can use tcpdump to see the > request packets arriving at the openvpn server, being sent to the recipient > machine, the response packets being sent from the recipient machine to the > openvpn server, and then sent to the external device. The external device > shows that the response was received with a reasonable response time given > that it is a cell phone. > >> > >> However, when I try to access a web page on any of the servers, I see > the same set of packets via tcpdump. In addition if I run ktrace on the > openvpn server, I see the encrypted packets from the client being > received. The decrypted packets sent to the home server. The unencrypted > response from the home server, and the encrypted response sent to the > phone. However, the phone says that the server dropped the connection, or > it shows a blank page. > >> > >> My first thought was that there was an encryption issue, but if that > were the case, ping would not work. Checking the ping packets shows that > they are encrypted between the phone and the openvpn server. Likewise a > routing issue in the home network does not seem to be the problem for the > same reason. All the info I have found on the web about vpn indicates that > a ping test should be sufficient. But, in this case it is not. > >> > >> Any ideas on how to track down the problem, or fix it? Thanks, > >> > >> -- Doug > > > > IMHO -- post your configuration file to the list.... > > > > I use OpenVPN with ipfw's internal NAT and it works fine, but the config > > file is a bit wonky and if you get it wrong you'll either have no DNS on > > the client or packets won't get routed. Either way the connection comes > > up but it doesn't work. > > > > mail# more server.conf > ################################################# > # Sample OpenVPN 2.0 config file for # > # multi-client server. # > # # > # This file is for the server side # > # of a many-clients <-> one-server # > # OpenVPN configuration. # > # # > # Comments are preceded with '#' or ';' # > ################################################# > > # Which local IP address should OpenVPN > # listen on? (optional) > ;local a.b.c.d > > # Which TCP/UDP port should OpenVPN listen on? > # If you want to run multiple OpenVPN instances > # on the same machine, use a different port > # number for each one. You will need to > # open up this port on your firewall. > port 1194 > > # TCP or UDP server? > ;proto tcp > proto udp > > # "dev tun" will create a routed IP tunnel, > # "dev tap" will create an ethernet tunnel. > # Use "dev tap0" if you are ethernet bridging > # and have precreated a tap0 virtual interface > # and bridged it with your ethernet interface. > # If you want to control access policies > # over the VPN, you must create firewall > # rules for the the TUN/TAP interface. > # On non-Windows systems, you can give > # an explicit unit number, such as tun0. > # On Windows, use "dev-node" for this. > # On most systems, the VPN will not function > # unless you partially or fully disable > # the firewall for the TUN/TAP interface. > ;dev tap > dev tun > > # SSL/TLS root certificate (ca), certificate > # (cert), and private key (key). Each client > # and the server must have their own cert and > # key file. The server and all clients will > # use the same ca file. > # > # See the "easy-rsa" directory for a series > # of scripts for generating RSA certificates > # and private keys. Remember to use > # a unique Common Name for the server > # and each of the client certificates. > # > # Any X509 key management system can be used. > # OpenVPN can also use a PKCS #12 formatted key file > # (see "pkcs12" directive in man page). > ca ca.pem > cert vpn_server.pem > key vpn_server.key # This file should be kept secret > > # Diffie hellman parameters. > # Generate your own with: > # openssl dhparam -out dh2048.pem 2048 > dh dh2048.pem > > # Network topology > # Should be subnet (addressing via IP) > # unless Windows clients v2.0.9 and lower have to > # be supported (then net30, i.e. a /30 per client) > # Defaults to net30 (not recommended) > ;topology subnet > > # Configure server mode and supply a VPN subnet > # for OpenVPN to draw client addresses from. > # The server will take 10.8.0.1 for itself, > # the rest will be made available to clients. > # Each client will be able to reach the server > # on 10.8.0.1. Comment this line out if you are > # ethernet bridging. See the man page for more info. > server 10.8.0.0 255.255.255.0 > > # Maintain a record of client <-> virtual IP address > # associations in this file. If OpenVPN goes down or > # is restarted, reconnecting clients can be assigned > # the same virtual IP address from the pool that was > # previously assigned. > ifconfig-pool-persist ipp.txt > > # Configure server mode for ethernet bridging. > # You must first use your OS's bridging capability > # to bridge the TAP interface with the ethernet > # NIC interface. Then you must manually set the > # IP/netmask on the bridge interface, here we > # assume 10.8.0.4/255.255.255.0. Finally we > # must set aside an IP range in this subnet > # (start=10.8.0.50 end=10.8.0.100) to allocate > # to connecting clients. Leave this line commented > # out unless you are ethernet bridging. > ;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100 > > # Configure server mode for ethernet bridging > # using a DHCP-proxy, where clients talk > # to the OpenVPN server-side DHCP server > # to receive their IP address allocation > # and DNS server addresses. You must first use > # your OS's bridging capability to bridge the TAP > # interface with the ethernet NIC interface. > # Note: this mode only works on clients (such as > # Windows), where the client-side TAP adapter is > # bound to a DHCP client. > ;server-bridge > > # Push routes to the client to allow it > # to reach other private subnets behind > # the server. Remember that these > # private subnets will also need > # to know to route the OpenVPN client > # address pool (10.8.0.0/255.255.255.0) > # back to the OpenVPN server. > ;push "route 192.168.10.0 255.255.255.0" > ;push "route 192.168.20.0 255.255.255.0" > push "route 10.0.1.0 255.255.255.0" > > # To assign specific IP addresses to specific > # clients or if a connecting client has a private > # subnet behind it that should also have VPN access, > # use the subdirectory "ccd" for client-specific > # configuration files (see man page for more info). > > # EXAMPLE: Suppose the client > # having the certificate common name "Thelonious" > # also has a small subnet behind his connecting > # machine, such as 192.168.40.128/255.255.255.248. > # First, uncomment out these lines: > ;client-config-dir ccd > ;route 192.168.40.128 255.255.255.248 > # Then create a file ccd/Thelonious with this line: > # iroute 192.168.40.128 255.255.255.248 > # This will allow Thelonious' private subnet to > # access the VPN. This example will only work > # if you are routing, not bridging, i.e. you are > # using "dev tun" and "server" directives. > > # EXAMPLE: Suppose you want to give > # Thelonious a fixed VPN IP address of 10.9.0.1. > # First uncomment out these lines: > ;client-config-dir ccd > ;route 10.9.0.0 255.255.255.252 > # Then add this line to ccd/Thelonious: > # ifconfig-push 10.9.0.1 10.9.0.2 > > # Suppose that you want to enable different > # firewall access policies for different groups > # of clients. There are two methods: > # (1) Run multiple OpenVPN daemons, one for each > # group, and firewall the TUN/TAP interface > # for each group/daemon appropriately. > # (2) (Advanced) Create a script to dynamically > # modify the firewall in response to access > # from different clients. See man > # page for more info on learn-address script. > ;learn-address ./script > > # If enabled, this directive will configure > # all clients to redirect their default > # network gateway through the VPN, causing > # all IP traffic such as web browsing and > # and DNS lookups to go through the VPN > # (The OpenVPN server machine may need to NAT > # or bridge the TUN/TAP interface to the internet > # in order for this to work properly). > push "redirect-gateway def1 bypass-dhcp" > > # Certain Windows-specific network settings > # can be pushed to clients, such as DNS > # or WINS server addresses. CAVEAT: > # http://openvpn.net/faq.html#dhcpcaveats > # The addresses below refer to the public > # DNS servers provided by opendns.com. > ;push "dhcp-option DNS 208.67.222.222" > push "dhcp-option DNS 10.0.1.230" > > # Uncomment this directive to allow different > # clients to be able to "see" each other. > # By default, clients will only see the server. > # To force clients to only see the server, you > # will also need to appropriately firewall the > # server's TUN/TAP interface. > ;client-to-client > > # Uncomment this directive if multiple clients > # might connect with the same certificate/key > # files or common names. This is recommended > # only for testing purposes. For production use, > # each client should have its own certificate/key > # pair. > # > # IF YOU HAVE NOT GENERATED INDIVIDUAL > # CERTIFICATE/KEY PAIRS FOR EACH CLIENT, > # EACH HAVING ITS OWN UNIQUE "COMMON NAME", > # UNCOMMENT THIS LINE OUT. > ;duplicate-cn > > # The keepalive directive causes ping-like > # messages to be sent back and forth over > # the link so that each side knows when > # the other side has gone down. > # Ping every 10 seconds, assume that remote > # peer is down if no ping received during > # a 120 second time period. > keepalive 10 120 > > # For extra security beyond that provided > # by SSL/TLS, create an "HMAC firewall" > # to help block DoS attacks and UDP port flooding. > # > # Generate with: > # openvpn --genkey --secret ta.key > # > # The server and each client must have > # a copy of this key. > # The second parameter should be '0' > # on the server and '1' on the clients. > ;tls-auth ta.key 0 # This file is secret > > # Select a cryptographic cipher. > # This config item must be copied to > # the client config file as well. > # Note that 2.4 client/server will automatically > # negotiate AES-256-GCM in TLS mode. > # See also the ncp-cipher option in the manpage > cipher AES-256-CBC > > # Enable compression on the VPN link and push the > # option to the client (2.4+ only, for earlier > # versions see below) > compress lz4-v2 > push "compress lz4-v2" > > # For compression compatible with older clients use comp-lzo > # If you enable it here, you must also > # enable it in the client config file. > ;comp-lzo > > # The maximum number of concurrently connected > # clients we want to allow. > max-clients 5 > > # It's a good idea to reduce the OpenVPN > # daemon's privileges after initialization. > # > # You can uncomment this out on > # non-Windows systems. > user nobody > group nobody > > # The persist options will try to avoid > # accessing certain resources on restart > # that may no longer be accessible because > # of the privilege downgrade. > persist-key > persist-tun > > # Output a short status file showing > # current connections, truncated > # and rewritten every minute. > status openvpn-status.log > > # By default, log messages will go to the syslog (or > # on Windows, if running as a service, they will go to > # the "\Program Files\OpenVPN\log" directory). > # Use log or log-append to override this default. > # "log" will truncate the log file on OpenVPN startup, > # while "log-append" will append to it. Use one > # or the other (but not both). > ;log openvpn.log > ;log-append openvpn.log > > # Set the appropriate level of log > # file verbosity. > # > # 0 is silent, except for fatal errors > # 4 is reasonable for general usage > # 5 and 6 can help to debug connection problems > # 9 is extremely verbose > ;verb 3 > verb 4 > > # Silence repeating messages. At most 20 > # sequential messages of the same message > # category will be output to the log. > ;mute 20 > > # Notify the client that when the server restarts so it > # can automatically reconnect. > explicit-exit-notify 1 > mail# > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" >