Very confused here, but I feel like I'm missing a route on either the client side or the server side. Or it is a firewall rule but that doesn't seem likely.
My OpenVPN server/client config is almost identical to that on the wiki page: https://wiki.gentoo.org/wiki/OpenVPN#Configuration After connecting from another ISP and then connecting to the VPN, I use dig to query the internal server: dig @192.168.1.254 pi.hole The server can see the DNS request from the client: # tcpdump -i tun0 'port 53' dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 02:21:07.996606 IP 10.100.0.6.50312 > 192.168.1.254.domain: 13933+ [1au] A? pi.hole. (36) Even the dnsmasq log is showing the request: Dec 3 10:21:45 dnsmasq[1026]: 4744 71.214.144.51/49349 query[A] pi.hole from 71.214.144.51 ^ shows the external IP. Is this normal? On the client side, dig times out. So if it can come through client-to-server but won't go back server-to-client, where could the issue be? I even changed the iptables policies for INPUT and FORWARD to allow to see if anything would change but the result was the same. I have HTTP running on the server and accessing via the IP works fine: $ curl https://192.168.1.254 -k ... < Server: nginx < Date: Mon, 03 Dec 2018 10:22:45 GMT < Content-Type: text/html < Content-Length: 574 < Connection: keep-alive < Keep-Alive: timeout=20 OpenVPN server configuration relevant lines: # OpenVPN 'virtual' network infomation, network and mask server 10.100.0.0 255.255.255.0 push "redirect-gateway def1" push "route 192.168.1.0 255.255.255.0" push "dhcp-option DNS 192.168.1.254" Routing table on server: $ route -4 Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default xx-xx-xx-xx. 0.0.0.0 UG 1024 0 0 enp1s0f0 10.100.0.0 10.100.0.2 255.255.255.0 UG 0 0 0 tun0 10.100.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 xx.xxx.144.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f0 xx-xxx-144-254. 0.0.0.0 255.255.255.255 UH 1024 0 0 enp1s0f0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f1 iptables on server: -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate NEW -j ACCEPT -t nat: -A POSTROUTING -s 10.100.0.0/24 -j MASQUERADE On the client (en0 is the wifi, utun4 is created by OpenVPN): $ netstat -nrtf inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 0/1 10.100.0.5 UGSc 84 0 utun4 default 172.20.10.1 UGSc 3 0 en0 10.100.0.1/32 10.100.0.5 UGSc 0 0 utun4 10.100.0.5 10.100.0.6 UHr 14 0 utun4 71.214.144.51/32 172.20.10.1 UGSc 1 0 en0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 5 140998 lo0 128.0/1 10.100.0.5 UGSc 4 0 utun4 169.254 link#9 UCS 0 0 en0 ! 172.20.10/28 link#9 UCS 1 0 en0 ! 172.20.10.1/32 link#9 UCS 2 0 en0 ! 172.20.10.1 b2:70:2d:2:18:64 UHLWIir 8 23 en0 1184 172.20.10.3/32 link#9 UCS 0 0 en0 ! 172.20.10.15 ff:ff:ff:ff:ff:ff UHLWbI 0 18 en0 ! 192.168.1 10.100.0.5 UGSc 0 0 utun4 224.0.0/4 link#9 UmCS 2 0 en0 ! 224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 4 en0 255.255.255.255/32 link#9 UCS 0 0 en0 ! -- Andrew Udvare
