Hi, OK, working my way through - with a bit of "fun" ... 😊. When I add route to the OpenVPN configuration file (without the other settings I believe), I lose my local LAN completely. Is that expected?
So then, OpenVPN off, trying to set up iptables .. but I get the following. Thoughts? iptables v1.6.0: unknown option "--state" I'm guessing this is replaced in more recent versions, but not having any luck finding the new flag. Thanks! ... Russell -----Original Message----- From: Morris, Russell Sent: Sunday, July 9, 2017 9:55 PM To: 'openvpn-users@lists.sourceforge.net' <openvpn-users@lists.sourceforge.net> Subject: RE: [Openvpn-users] Intermittent Connectivity First of all, thanks for taking the time to provide the detailed information below - it's very much appreciated! I will try to set it up this way, let you know what I find. But I do agree, I think this is a better way to go. BTW, do you want me to try to take some logs, or not really that big of a curiosity / issue? Just let me know, I can if it helps at all. And also, thanks for the book recommendation - buying it tonight ... 😊. Thanks again, ... Russell -----Original Message----- From: David Sommerseth [mailto:open...@sf.lists.topphemmelig.net] Sent: Friday, July 7, 2017 4:41 PM To: Morris, Russell <rmor...@rkmorris.us> Subject: Re: [Openvpn-users] Intermittent Connectivity On 07/07/17 16:36, Morris, Russell wrote: [...snip...] >> Thoughts? Things to try? > This looks like a typical wacky connection between client and server. > And using --proto tcp with wacky connections, things tends to get ugly > quickly. And especially when sending TCP packets inside the tunnel. > That results in a lot of "resend this packet" requests both on the > inside and outside of the tunnel. So try switching to --proto udp. > > [R. Morris] Actually, is it really TCP? Asking because the other > connection I tested is TCP also, just TUN instead of TAP ... and it's > rock solid. I don't really have the option to use UDP, a bit > handcuffed there ... :-(. Okay, that is a more tricky issue. It is really hard to say without seeing some logs (--verb 4). There might be packet replays, it might be packet loss, it might be packet latency, really hard to guess without logs. > [R. Morris] Intrigued ... :-). TUN would be fine, if I could get to > the machines on the subnet ... but can I really? I need to run RDP, > VNC, SSH, etc. How is routing handled with TUN? Again, I'm interested > to try this, but I thought to be "on" the subnet, and access all the > machines (by name) I needed to use TAP. What you basically need to do is: - Allocate the VPN on a separate subnet (our examples often use 10.8.0.0/24) - VPN server need to push (or add directly route in client config) route $LAN_SUBNET_IP $LAN_SUBNET_MASK If your LAN is 192.168.1.0/24 (255.255.255.0), you need: route 192.168.1.0 255.255.255.0 - Enable IP forwarding on the VPN server. On Linux this is typically done with: sysctl net.ipv4.ip_forward=1 - Allow traffic passing between the LAN and the TUN adapter in the firewall. For Linux servers, that's easily handled by: # iptables -I FORWARD -i tun+ -o eth+ \ -m conntrack --state NEW -j ACCEPT # iptables -I FORWARD -m conntrack --state ESTALISHED,RELATED \ -j ACCEPT This allows traffic initiated from the VPN (any adapters named tun-something) to access network resources on any Ethernet interfaces named eth-something. (+ is a wildcard) - The default gateway in the LAN needs to route the 10.8.0.0/24 via the VPN server. If the VPN server is running on your default gateway this is already correctly set up. a) LAN GW + VPN server on same box: {internet}-[FW]---[LAN GW/VPN]---{LAN} b) VPN server is on the LAN {internet}-[FW]----[LAN GW]----{LAN} \-{VPN-SERVER} If the VPN server IP is 192.168.1.10, the LAN GW needs this route: ip route add 10.8.0.0/24 via 192.168.1.10 c) VPN server is in a DMZ {internet}-[FW]----[LAN GW]----{LAN} | \-{VPN-SERVER in DMZ} If the VPN server IP is 172.16.2.20, the FW(!) needs this route: ip route add 10.8.0.0/24 via 172.16.2.20 - To use DNS hostnames for the hosts on LAN, you need to add this to your server config: push "dhcp-option DNS $IP_OF_INTERNAL_DNS" For VPN connections started by the Windows GUI, Tunnelblick (macOS) and NetworkManager (on Linux), iOS and Android, the DNS stuff on the client side happens automatically. If starting OpenVPN from the command line, it needs some local tweaks. For Linux, /etc/resolv.conf needs to get updated. Now I know that sounds like a lot of details compared to bridging. But this is actually the path of least resistance when things go bad. And for further details, I recommend looking into the "OpenVPN 2 Cookbook" by Jan Just Keijser, and probably also the "Mastering OpenVPN 2" by Eric Crist and Jan Just Keijser (have only skimmed through that book myself so far). -- kind regards, David Sommerseth OpenVPN Technologies, Inc ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
