[Solved] DNS leaks with PBR over OpenVPN from outside

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Author Message
ig007
DD-WRT Novice


Joined: 28 Jul 2021
Posts: 16

PostPosted: Wed Aug 04, 2021 16:03    Post subject: [Solved] DNS leaks with PBR over OpenVPN from outside Reply with quote
My setup is almost there and just few things left to make working as I want it to.

One of the last things left is DNS leak issue. The situation: WRT3200 with build 47117 has VPN server and client running with PBR table 42 enabled as per guide. Have firewall getwanface setup for postrouting as per guide too. When I am within network I have no DNS leaks on any LAN client. When I connect from outside over VPN tunnel and do leak test, my IP shown is as VPN server IP, but DNS displayed is from my LTE provider (AT&T), that means I have leak.

I have tried to follow guide in Troubleshooting of this forum, enabled Ignore WAN DNS, added routing to client config, tried to force DNS redirection as well. All to no luck. I still see ISP in DNS upon connection from outside.

See attached files for setup I have. Below is VPN log copy:

Serverlog:
20210804 10:57:37 W --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
20210804 10:57:37 W WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
20210804 10:57:37 I OpenVPN 2.5.3 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 1 2021
20210804 10:57:37 I library versions: OpenSSL 1.1.1k 25 Mar 2021 LZO 2.09
20210804 10:57:37 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:14
20210804 10:57:37 net_route_v4_best_gw query: dst 0.0.0.0
20210804 10:57:37 net_route_v4_best_gw result: via 192.168.1.1 dev eth0
20210804 10:57:37 W NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
20210804 10:57:37 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20210804 10:57:37 Diffie-Hellman initialized with 2048 bit key
20210804 10:57:37 W WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1300)
20210804 10:57:37 I TUN/TAP device tun2 opened
20210804 10:57:37 TUN/TAP TX queue length set to 1000
20210804 10:57:37 I net_iface_mtu_set: mtu 1300 for tun2
20210804 10:57:37 I net_iface_up: set tun2 up
20210804 10:57:37 I net_addr_v4_add: 16.17.0.1/24 dev tun2
20210804 10:57:37 Socket Buffers: R=[180224->180224] S=[180224->180224]
20210804 10:57:37 I UDPv4 link local (bound): [AF_INET][undef]:1194
20210804 10:57:37 I UDPv4 link remote: [AF_UNSPEC]
20210804 10:57:37 MULTI: multi_init called r=256 v=256
20210804 10:57:37 IFCONFIG POOL IPv4: base=16.17.0.2 size=252
20210804 10:57:37 I ifconfig_pool_read() in='device-client 16.17.0.2 '
20210804 10:57:37 I succeeded -> ifconfig_pool_set(hand=0)
20210804 10:57:37 IFCONFIG POOL LIST
20210804 10:57:37 device-client 16.17.0.2
20210804 10:57:37 I Initialization Sequence Completed
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 10:57:39 D MANAGEMENT: CMD 'state'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 10:57:39 D MANAGEMENT: CMD 'state'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 10:57:39 D MANAGEMENT: CMD 'state'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 NOTE: --mute triggered...
20210804 10:57:39 1 variation(s) on previous 3 message(s) suppressed by --mute
20210804 10:57:39 D MANAGEMENT: CMD 'status 2'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 10:57:39 D MANAGEMENT: CMD 'status 2'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 10:57:39 D MANAGEMENT: CMD 'log 500'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:51:17 D MANAGEMENT: CMD 'state'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:51:17 D MANAGEMENT: CMD 'state'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:51:17 D MANAGEMENT: CMD 'state'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 NOTE: --mute triggered...
20210804 11:51:17 1 variation(s) on previous 3 message(s) suppressed by --mute
20210804 11:51:17 D MANAGEMENT: CMD 'status 2'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:51:17 D MANAGEMENT: CMD 'status 2'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:51:17 D MANAGEMENT: CMD 'log 500'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:58:29 D MANAGEMENT: CMD 'state'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:58:29 D MANAGEMENT: CMD 'state'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:58:29 D MANAGEMENT: CMD 'state'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 NOTE: --mute triggered...
20210804 11:58:29 1 variation(s) on previous 3 message(s) suppressed by --mute
20210804 11:58:29 D MANAGEMENT: CMD 'status 2'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:58:29 D MANAGEMENT: CMD 'status 2'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20210804 11:58:29 D MANAGEMENT: CMD 'log 500'
19691231 19:00:00




Clientlog:
20210804 10:57:38 W WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
20210804 10:57:38 W WARNING: file '/tmp/openvpncl/credentials' is group or others accessible
20210804 10:57:38 I OpenVPN 2.5.3 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 1 2021
20210804 10:57:38 I library versions: OpenSSL 1.1.1k 25 Mar 2021 LZO 2.09
20210804 10:57:38 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
20210804 10:57:38 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20210804 10:57:38 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
20210804 10:57:38 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
20210804 10:57:38 I TCP/UDP: Preserving recently used remote address: [AF_INET]45.43.19.68:1194
20210804 10:57:38 Socket Buffers: R=[180224->180224] S=[180224->180224]
20210804 10:57:38 I UDPv4 link local: (not bound)
20210804 10:57:38 I UDPv4 link remote: [AF_INET]45.43.19.68:1194
20210804 10:57:38 TLS: Initial packet from [AF_INET]45.43.19.68:1194 sid=fa7dc400 ba8cfc14
20210804 10:57:38 VERIFY OK: depth=2 C=VG O=Surfshark CN=Surfshark Root CA
20210804 10:57:38 VERIFY OK: depth=1 C=VG O=Surfshark CN=Surfshark Intermediate CA
20210804 10:57:38 NOTE: --mute triggered...
20210804 10:57:38 6 variation(s) on previous 3 message(s) suppressed by --mute
20210804 10:57:38 I [us-ltm-v011.prod.surfshark.com] Peer Connection Initiated with [AF_INET]45.43.19.68:1194
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 10:57:39 SENT CONTROL [us-ltm-v011.prod.surfshark.com]: 'PUSH_REQUEST' (status=1)
20210804 10:57:39 D MANAGEMENT: CMD 'state'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 10:57:39 D MANAGEMENT: CMD 'state'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 10:57:39 D MANAGEMENT: CMD 'state'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 PUSH: Received control message: 'PUSH_REPLY dhcp-option DNS 162.252.172.57 dhcp-option DNS 149.154.159.92 redirect-gateway def1 sndbuf 524288 rcvbuf 524288 explicit-exit-notify block-outside-dns route-gateway 10.8.8.1 topology subnet ping 60 ping-restart 180 ifconfig 10.8.8.11 255.255.255.0 peer-id 9 cipher AES-256-GCM'
20210804 10:57:39 Pushed option removed by filter: 'dhcp-option DNS 162.252.172.57'
20210804 10:57:39 Pushed option removed by filter: 'dhcp-option DNS 149.154.159.92'
20210804 10:57:39 N Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:7: block-outside-dns (2.5.3)
20210804 10:57:39 OPTIONS IMPORT: timers and/or timeouts modified
20210804 10:57:39 OPTIONS IMPORT: explicit notify parm(s) modified
20210804 10:57:39 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
20210804 10:57:39 Socket Buffers: R=[180224->360448] S=[180224->360448]
20210804 10:57:39 OPTIONS IMPORT: --ifconfig/up options modified
20210804 10:57:39 OPTIONS IMPORT: route options modified
20210804 10:57:39 OPTIONS IMPORT: route-related options modified
20210804 10:57:39 NOTE: --mute triggered...
20210804 10:57:39 3 variation(s) on previous 3 message(s) suppressed by --mute
20210804 10:57:39 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20210804 10:57:39 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20210804 10:57:39 net_route_v4_best_gw query: dst 0.0.0.0
20210804 10:57:39 net_route_v4_best_gw result: via 192.168.1.1 dev eth0
20210804 10:57:39 I TUN/TAP device tun1 opened
20210804 10:57:39 I net_iface_mtu_set: mtu 1500 for tun1
20210804 10:57:39 I net_iface_up: set tun1 up
20210804 10:57:39 I net_addr_v4_add: 10.8.8.11/24 dev tun1
20210804 10:57:39 net_route_v4_add: 45.43.19.68/32 via 192.168.1.1 dev [NULL] table 0 metric -1
20210804 10:57:39 net_route_v4_add: 0.0.0.0/1 via 10.8.8.1 dev [NULL] table 0 metric -1
20210804 10:57:39 net_route_v4_add: 128.0.0.0/1 via 10.8.8.1 dev [NULL] table 0 metric -1
20210804 10:57:39 net_route_v4_add: 162.252.172.57/32 via 10.8.8.1 dev [NULL] table 0 metric -1
20210804 10:57:39 net_route_v4_add: 149.154.159.92/32 via 10.8.8.1 dev [NULL] table 0 metric -1
20210804 10:57:39 I Initialization Sequence Completed
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 10:57:39 D MANAGEMENT: CMD 'status 2'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 10:57:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 10:57:39 D MANAGEMENT: CMD 'log 500'
20210804 10:57:39 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:51:17 D MANAGEMENT: CMD 'state'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:51:17 D MANAGEMENT: CMD 'state'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:51:17 D MANAGEMENT: CMD 'state'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:51:17 D MANAGEMENT: CMD 'status 2'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:51:17 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:51:17 D MANAGEMENT: CMD 'log 500'
20210804 11:51:17 MANAGEMENT: Client disconnected
20210804 11:52:48 VERIFY OK: depth=2 C=VG O=Surfshark CN=Surfshark Root CA
20210804 11:52:48 VERIFY OK: depth=1 C=VG O=Surfshark CN=Surfshark Intermediate CA
20210804 11:52:48 VERIFY KU OK
20210804 11:52:48 NOTE: --mute triggered...
20210804 11:58:29 7 variation(s) on previous 3 message(s) suppressed by --mute
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:58:29 D MANAGEMENT: CMD 'state'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:58:29 D MANAGEMENT: CMD 'state'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:58:29 D MANAGEMENT: CMD 'state'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:58:29 D MANAGEMENT: CMD 'status 2'
20210804 11:58:29 MANAGEMENT: Client disconnected
20210804 11:58:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20210804 11:58:29 D MANAGEMENT: CMD 'log 500'
19691231 19:00:00


Last edited by ig007 on Sat Aug 07, 2021 17:00; edited 1 time in total
Sponsor
ig007
DD-WRT Novice


Joined: 28 Jul 2021
Posts: 16

PostPosted: Wed Aug 04, 2021 16:05    Post subject: Reply with quote
Additional setup files added
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12839
Location: Netherlands

PostPosted: Wed Aug 04, 2021 17:04    Post subject: Reply with quote
I applaud your perseverance and it is amazing you got this far without expert knowledge (must be the quality of the guides LoL)

Some remarks:
The routers IP address is 10.197.128.141, a bit unusual as we mostly use the first .1 or the last address .254 but OK.
the only problem your DHCP range is from .100 -.150 so the routers IP address is inside the DHCP scope Shocked

Your DNS servers seem to be your VPN providers.
That is not recommended, usually those are private DNS servers and will only work after the tunnel is up, you were lucky as these are also publicly available but if not you cannot use an URL as server address.
So if you want to use the providers DNS server add those and the routing in the VPN clients Additional config, in this case they are already pushed by the provider and if pushed they are automatically routed via the client.
So what you are doing is unnecessary.
(You can make a case for it if you know the DNS servers are publicly available and you have to be absolutely sure no outside DNS server is used but in that case you should use no-resolv in DNSMasq).

For your VPN server you are using a subnet starting with 16. as far as I know those are not private addresses, this can/shall be in use by someone else.

Research Private IP addresses.

Your own VPN client will not leak as you are not using PBR so everything is routed via the VPN client.
(you are using PBR but only to route the server port on to the WAN, kudos for doing it this way)

You describe a DNS leak of your LTE device connecting to your own server.
That DNS leak comes from the client on that LTE device (If I would guess it is a device running Windows?)
So has nothing to do with DDWRT or your router.

Windows VPN clients have a habit of leaking DNS.

If your LTE client is Windows then see the Server setup guide page 22 to solve this (your own VPN provider is also doing this as can be seen in the logs)

If it is not running Windows than search for the setup of that VPN client on that platform how to deal with this.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
ig007
DD-WRT Novice


Joined: 28 Jul 2021
Posts: 16

PostPosted: Wed Aug 04, 2021 18:01    Post subject: Reply with quote
egc wrote:
I applaud your perseverance and it is amazing you got this far without expert knowledge (must be the quality of the guides LoL)

Some remarks:
The routers IP address is 10.197.128.141, a bit unusual as we mostly use the first .1 or the last address .254 but OK.
the only problem your DHCP range is from .100 -.150 so the routers IP address is inside the DHCP scope Shocked

Your DNS servers seem to be your VPN providers.
That is not recommended, usually those are private DNS servers and will only work after the tunnel is up, you were lucky as these are also publicly available but if not you cannot use an URL as server address.
So if you want to use the providers DNS server add those and the routing in the VPN clients Additional config, in this case they are already pushed by the provider and if pushed they are automatically routed via the client.
So what you are doing is unnecessary.
(You can make a case for it if you know the DNS servers are publicly available and you have to be absolutely sure no outside DNS server is used but in that case you should use no-resolv in DNSMasq).

For your VPN server you are using a subnet starting with 16. as far as I know those are not private addresses, this can/shall be in use by someone else.

Research Private IP addresses.

Your own VPN client will not leak as you are not using PBR so everything is routed via the VPN client.
(you are using PBR but only to route the server port on to the WAN, kudos for doing it this way)

You describe a DNS leak of your LTE device connecting to your own server.
That DNS leak comes from the client on that LTE device (If I would guess it is a device running Windows?)
So has nothing to do with DDWRT or your router.

Windows VPN clients have a habit of leaking DNS.

If your LTE client is Windows then see the Server setup guide page 22 to solve this (your own VPN provider is also doing this as can be seen in the logs)

If it is not running Windows than search for the setup of that VPN client on that platform how to deal with this.


Thanks for useful tips! I changed IP of VPN server to private range AND both routers to .1 and .2, so that they are now outside of DHCP as you pointed out. That didn't solve my issue (although I didn't hope for that).

I am keeping VPN provider DNS as without them VPN client doesn't connect and direction to add those is on their website.
https://support.surfshark.com/hc/en-us/articles/360003086114-How-to-set-up-Surfshark-VPN-on-DD-WRT-router-

My LTE device is Android phone. I will take a look into Android client setup further.
ig007
DD-WRT Novice


Joined: 28 Jul 2021
Posts: 16

PostPosted: Wed Aug 04, 2021 19:25    Post subject: Reply with quote
OMG! I did it Smile LOL

After some searching about Android OpenVPN client DNS leaks I found forum thread, but it didn't work as is.

https://forums.openvpn.net/viewtopic.php?t=18085

Then I just took pieces of the code to make it simply to push both VPN DNS and added to server config.

push "dhcp-option DNS 162.252.172.57"
push "dhcp-option DNS 149.154.159.92"

And when I am on OpenVPN on Android and LTE connected to my server, no more DNS leaks as I see my VPN provider IP and DNS are the same and no more LTE IP visible.
Can you confirm this is the right setup and there is no hidden issue here with me pushing DNS onto client?
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum