Routing issue with OpenVPN and internal DNS

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Routing issue with OpenVPN and internal DNS

Andrew Udvare
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



Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with OpenVPN and internal DNS

Michael Orlitzky
On 12/3/18 5:55 AM, Andrew Udvare wrote:
>
> iptables on server:
> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate NEW -j ACCEPT
>

Is that only forwarding packets for new (i.e. not existing) connections?

Ours looks like,

iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s $INSIDE_NET    -j ACCEPT
iptables -A FORWARD -i $VPN_INTERFACE -j ACCEPT

(and you need to enable the net.ipv4.ip_forward sysctl)

Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with OpenVPN and internal DNS

Andrew Udvare
On 03/12/2018 09:49, Michael Orlitzky wrote:
> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>
>> iptables on server:
>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>> NEW -j ACCEPT
>>
>
> Is that only forwarding packets for new (i.e. not existing) connections?

Not sure but I do have a rule with using --ctstate ESTABLISHED,RELATED
like yours. I even got rid of the interface argument in case that's a
problem. The box is a router and has 2 NICs going, one for WAN and one
for LAN. enp1s0f0 being the internet, and enp1s0f1 is for 192.168.1.0/24

When I'm connected to the VPN and I'm definitely not on my network, I
can do things like `ssh 192.168.1.xxx` and it works. And HTTP works too.
It's only port 53 that I am having trouble with.

dnsmasq (listening only on enp1s0f1, 192 address) gets the request from
the tun0 interface, which seems to route correctly to the 192 address.
The response that dnsmasq creates (presumably) does not route back to
the originating IP.

Happy to provide any other configuration details and packet dumps if it
helps.

Full iptables (I use a script to reset to sane state, suggestions welcome):

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-N SCANS
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state
--state NEW -j DROP
-A INPUT -f -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
--name BLACKLIST --mask 255.255.255.255 --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent
--update --seconds 10 --hitcount 10 --rttl --name BLACKLIST --mask
255.255.255.255 --rsource -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9222 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 67 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p udp -m udp --dport 68 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m conntrack --ctstate NEW,ESTABLISHED
-j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p udp -m udp --dport 33434:33523 -j REJECT --reject-with
icmp-port-unreachable
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 3306 -m conntrack
--ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m conntrack --ctstate NEW,ESTABLISHED
-m udp --dport 137 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m conntrack --ctstate NEW,ESTABLISHED
-m udp --dport 138 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m conntrack --ctstate NEW,ESTABLISHED
-m tcp --dport 139 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m conntrack --ctstate NEW,ESTABLISHED
-m tcp --dport 445 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4242 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i enp1s0f1 -p udp -m udp --dport 5353 -m
conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 12112 -m conntrack --ctstate
NEW,ESTABLISHED -j ACCEPT
-A INPUT -s 205.171.2.64/32 -p ipv6 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -i enp1s0f1 -j ACCEPT
-A FORWARD -i enp2s0 -j ACCEPT
-A FORWARD -i enp1s0f0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.100.0.0/24 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j
DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
-A SCANS -p tcp -m tcp --tcp-flags FIN,PSH,URG FIN,PSH,URG -j DROP
-A SCANS -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG
FIN,SYN,RST,PSH,ACK,URG -j DROP
-A SCANS -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A SCANS -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

iptables -nat --list-rules:

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N DOCKER
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 10.100.0.0/24 -j MASQUERADE
-A POSTROUTING -j MASQUERADE
-A DOCKER -i docker0 -j RETURN

--
Andrew


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Routing issue with OpenVPN and internal DNS

William Kenworthy
On 4/12/18 10:26 am, Andrew Udvare wrote:
> On 03/12/2018 09:49, Michael Orlitzky wrote:
>> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>> iptables on server:
>>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>>> NEW -j ACCEPT
>>>
>> Is that only forwarding packets for new (i.e. not existing) connections?
> ...


As its a router, have you correctly configured openvpn's
client-to-client setup?


BillK




Reply | Threaded
Open this post in threaded view
|

Routing issue with OpenVPN and internal DNS

William Kenworthy
In reply to this post by Andrew Udvare
On 4/12/18 10:26 am, Andrew Udvare wrote:
> On 03/12/2018 09:49, Michael Orlitzky wrote:
>> On 12/3/18 5:55 AM, Andrew Udvare wrote:
>>> iptables on server:
>>> -A FORWARD -s 10.100.0.0/24 -i tun0 -o enp1s0f0 -m conntrack --ctstate
>>> NEW -j ACCEPT
>>>
>> Is that only forwarding packets for new (i.e. not existing) connections?
> ...


sent too soon, missed some ...


As its a router, have you correctly configured openvpn's
client-to-client, CCD and iroute setup?


Google "openvpn networks behind server"


BillK