| 1 |
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. |
| 2 |
|
| 3 |
My OpenVPN server/client config is almost identical to that on the wiki page: https://wiki.gentoo.org/wiki/OpenVPN#Configuration |
| 4 |
|
| 5 |
After connecting from another ISP and then connecting to the VPN, I use dig to query the internal server: |
| 6 |
|
| 7 |
dig @192.168.1.254 pi.hole |
| 8 |
|
| 9 |
The server can see the DNS request from the client: |
| 10 |
|
| 11 |
# tcpdump -i tun0 'port 53' |
| 12 |
dropped privs to tcpdump |
| 13 |
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode |
| 14 |
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes |
| 15 |
02:21:07.996606 IP 10.100.0.6.50312 > 192.168.1.254.domain: 13933+ [1au] A? pi.hole. (36) |
| 16 |
|
| 17 |
Even the dnsmasq log is showing the request: |
| 18 |
|
| 19 |
Dec 3 10:21:45 dnsmasq[1026]: 4744 71.214.144.51/49349 query[A] pi.hole from 71.214.144.51 |
| 20 |
^ shows the external IP. Is this normal? |
| 21 |
|
| 22 |
On the client side, dig times out. |
| 23 |
|
| 24 |
So if it can come through client-to-server but won't go back server-to-client, where could the issue be? |
| 25 |
|
| 26 |
I even changed the iptables policies for INPUT and FORWARD to allow to see if anything would change but the result was the same. |
| 27 |
|
| 28 |
I have HTTP running on the server and accessing via the IP works fine: |
| 29 |
|
| 30 |
$ curl https://192.168.1.254 -k |
| 31 |
... |
| 32 |
< Server: nginx |
| 33 |
< Date: Mon, 03 Dec 2018 10:22:45 GMT |
| 34 |
< Content-Type: text/html |
| 35 |
< Content-Length: 574 |
| 36 |
< Connection: keep-alive |
| 37 |
< Keep-Alive: timeout=20 |
| 38 |
|
| 39 |
OpenVPN server configuration relevant lines: |
| 40 |
|
| 41 |
# OpenVPN 'virtual' network infomation, network and mask |
| 42 |
server 10.100.0.0 255.255.255.0 |
| 43 |
push "redirect-gateway def1" |
| 44 |
push "route 192.168.1.0 255.255.255.0" |
| 45 |
push "dhcp-option DNS 192.168.1.254" |
| 46 |
|
| 47 |
Routing table on server: |
| 48 |
$ route -4 |
| 49 |
Kernel IP routing table |
| 50 |
Destination Gateway Genmask Flags Metric Ref Use Iface |
| 51 |
default xx-xx-xx-xx. 0.0.0.0 UG 1024 0 0 enp1s0f0 |
| 52 |
10.100.0.0 10.100.0.2 255.255.255.0 UG 0 0 0 tun0 |
| 53 |
10.100.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 |
| 54 |
xx.xxx.144.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f0 |
| 55 |
xx-xxx-144-254. 0.0.0.0 255.255.255.255 UH 1024 0 0 enp1s0f0 |
| 56 |
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 |
| 57 |
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f1 |
| 58 |
|
| 59 |
iptables on server: |
| 60 |
-A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate NEW -j ACCEPT |
| 61 |
|
| 62 |
-t nat: |
| 63 |
-A POSTROUTING -s 10.100.0.0/24 -j MASQUERADE |
| 64 |
|
| 65 |
On the client (en0 is the wifi, utun4 is created by OpenVPN): |
| 66 |
$ netstat -nrtf inet |
| 67 |
Routing tables |
| 68 |
|
| 69 |
Internet: |
| 70 |
Destination Gateway Flags Refs Use Netif Expire |
| 71 |
0/1 10.100.0.5 UGSc 84 0 utun4 |
| 72 |
default 172.20.10.1 UGSc 3 0 en0 |
| 73 |
10.100.0.1/32 10.100.0.5 UGSc 0 0 utun4 |
| 74 |
10.100.0.5 10.100.0.6 UHr 14 0 utun4 |
| 75 |
71.214.144.51/32 172.20.10.1 UGSc 1 0 en0 |
| 76 |
127 127.0.0.1 UCS 0 0 lo0 |
| 77 |
127.0.0.1 127.0.0.1 UH 5 140998 lo0 |
| 78 |
128.0/1 10.100.0.5 UGSc 4 0 utun4 |
| 79 |
169.254 link#9 UCS 0 0 en0 ! |
| 80 |
172.20.10/28 link#9 UCS 1 0 en0 ! |
| 81 |
172.20.10.1/32 link#9 UCS 2 0 en0 ! |
| 82 |
172.20.10.1 b2:70:2d:2:18:64 UHLWIir 8 23 en0 1184 |
| 83 |
172.20.10.3/32 link#9 UCS 0 0 en0 ! |
| 84 |
172.20.10.15 ff:ff:ff:ff:ff:ff UHLWbI 0 18 en0 ! |
| 85 |
192.168.1 10.100.0.5 UGSc 0 0 utun4 |
| 86 |
224.0.0/4 link#9 UmCS 2 0 en0 ! |
| 87 |
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0 |
| 88 |
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 4 en0 |
| 89 |
255.255.255.255/32 link#9 UCS 0 0 en0 ! |
| 90 |
|
| 91 |
-- |
| 92 |
Andrew Udvare |
Archives