Posted: Fri Aug 12, 2022 17:22 Post subject: [SOLVED]Can connect to VPN but can't see LAN or WAN
I am running r49532 on a Netgear r6700v3.
I am able to get an openvpn connection from my Android phone using the "OpenVPN Connect" client app to my router running openvpn in server mode. Note I have WiFi off on my phone.
I see the connection in my dd-wrt openvpn logs without any errors
Code:
20220812 12:52:53 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
But I am unable to ping anything on my LAN (even my router at 192.168.1.1) and I am not able to access anything on the Internet.
Note when I disconnect from "OpenVPN Connect" and turn WiFI back on to connect directly to the LAN, I can ping my router normally and access the Interet so it's not ar firewall issue
I have followed "DDWRT OpenVPN Server Setup guide v24" and "DDWRT VPN troubleshooting guide v44"
I have attached a screenshot of the dd-wrt openvpn config.
Note I have no 'Additional Configurations'
Also, I am using tls-crypt (but I had the same problem with tls-crypt turned off)
My client config is:
Code:
client
dev tun
proto tcp4
remote mydomain.com 1194
nobind
persist-key
persist-tun
remote-cert-tls server
auth-nocache
verb4
float
tun-mtu 1400
auth none
data-ciphers CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM:AES-256-CBC
comp-lzo no
resolv-retry infinite
remote-random
<ca>
....
</ca>
<cert>
...
</cert>
<key>
...
</key>
<tls-crypt>
...
</tls-crypt>
I ran the following commands per the troubleshooting guide:
# ip route show
default via 146.115.144.1 dev vlan2
10.10.10.0/24 dev tun2 scope link src 10.10.10.1
127.0.0.0/8 dev lo scope link
146.115.144.0/22 dev vlan2 scope link src 146.115.145.129
192.168.1.0/24 dev br0 scope link src 192.168.1.1
192.168.2.0/24 dev br1 scope link src 192.168.2.1
The only difference from the troubleshooting guide is that I am missing the FORWARD chain rule:
Code:
0 0 ACCEPT all -- * tun2 0.0.0.0/0 0.0.0.0/0
But adding that line back didn't make any difference
Code:
# iptables -A FORWARD -o tun2 -j ACCEPT
So, I am stumped at what I am missing here...
Any suggestions?
FYI. The following does NOT mean you're connected.
Code:
20220812 12:52:53 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
That's simply the management UI being access by the router (notice its a loopback address and local port) as it asks the OpenVPN server for statistics information in order to update the GUI display.
When done correctly, there no need to add any firewall rules either.
It would help if you provided syslogs from both the server and client so we can actually see the conversation between the two devices (if any). Sometimes the server isn't even reachable because your home network does NOT have a public IP, but perhaps CGNAT, which is NOT remotely accessible. IOW, it might be the config for both the client and server are just fine, but it's a more general lack of remote access capability.
Attaching a screenshot that seems to confirm connectivity.
As does, the OpenVPN Connect app on my Android.
Here is the server log (I first disconnected then reconnected):
Code:
20220812 14:12:02 jeff3/172.58.221.231:27253 SENT CONTROL [jeff3]: 'PUSH_REPLY redirect-gateway def1 route-gateway 10.10.10.1 topology subnet ping 10 ping-restart 120 socket-flags TCP_NODELAY ifconfig 10.10.10.2 255.255.255.0 peer-id 0 cipher CHACHA20-POLY1305' (status=1)
20220812 14:12:02 jeff3/172.58.221.231:27253 PUSH: Received control message: 'PUSH_REQUEST'
20220812 14:12:02 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:02 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:02 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:02 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:02 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:03 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:04 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:05 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:06 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:06 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:07 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:08 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:09 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:10 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:11 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:12 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:13 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:13 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:14 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:15 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:16 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:17 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:18 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:19 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:20 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:21 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:22 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:23 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:24 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:25 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:26 W jeff3/172.58.221.231:27253 IP packet with unknown IP version=15 seen
20220812 14:12:27 N jeff3/172.58.221.231:27253 Connection reset restarting [0]
20220812 14:12:27 jeff3/172.58.221.231:27253 SIGUSR1[soft connection-reset] received client-instance restarting
20220812 14:12:28 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
20220812 14:12:28 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
20220812 14:12:28 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
20220812 14:12:28 NOTE: --mute triggered...
20220812 14:12:28 1 variation(s) on previous 3 message(s) suppressed by --mute
20220812 14:12:28 W WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1400)
20220812 14:12:28 I TCP connection established with [AF_INET]172.58.221.231:38556
20220812 14:12:28 172.58.221.231:38556 TLS: Initial packet from [AF_INET]172.58.221.231:38556 sid=6d5c7f1d 10982b73
20220812 14:12:28 172.58.221.231:38556 VERIFY OK: depth=1 C=US ST=MA L=Newton O=MyOrg OU=Business CN=MyName name=EasyRSA emailAddress=myname@mydomain.org
20220812 14:12:28 172.58.221.231:38556 VERIFY OK: depth=0 C=US ST=MA L=Boston O=MyOrg OU=Business CN=jeff3 name=EasyRSA emailAddress=myname@mydomain.org
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_VER=3.git::d3f8b18b:Release
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_PLAT=android
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_NCP=2
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_TCPNL=1
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_PROTO=30
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_LZO_STUB=1
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_COMP_STUB=1
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_COMP_STUBv2=1
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_AUTO_SESS=1
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_GUI_VER=net.openvpn.connect.android_3.3.0-8367
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_SSO=webauth openurl
20220812 14:12:28 I 172.58.221.231:38556 peer info: IV_BS64DL=1
20220812 14:12:28 W 172.58.221.231:38556 WARNING: 'link-mtu' is used inconsistently local='link-mtu 1443' remote='link-mtu 1424'
20220812 14:12:28 W 172.58.221.231:38556 WARNING: 'auth' is used inconsistently local='auth SHA1' remote='auth [null-digest]'
20220812 14:12:28 W 172.58.221.231:38556 WARNING: 'comp-lzo' is present in remote config but missing in local config remote='comp-lzo'
20220812 14:12:28 172.58.221.231:38556 Control Channel: TLSv1.3 cipher TLSv1.3 TLS_AES_256_GCM_SHA384 peer certificate: 2048 bit RSA signature: RSA-SHA256
20220812 14:12:28 I 172.58.221.231:38556 [jeff3] Peer Connection Initiated with [AF_INET]172.58.221.231:38556
20220812 14:12:28 I jeff3/172.58.221.231:38556 MULTI_sva: pool returned IPv4=10.10.10.2 IPv6=(Not enabled)
20220812 14:12:28 jeff3/172.58.221.231:38556 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_09369e2e1b8a7eef.tmp
20220812 14:12:28 jeff3/172.58.221.231:38556 MULTI: Learn: 10.10.10.2 -> jeff3/172.58.221.231:38556
20220812 14:12:28 jeff3/172.58.221.231:38556 MULTI: primary virtual IP for jeff3/172.58.221.231:38556: 10.10.10.2
20220812 14:12:28 jeff3/172.58.221.231:38556 Data Channel: using negotiated cipher 'CHACHA20-POLY1305'
20220812 14:12:28 jeff3/172.58.221.231:38556 Outgoing Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
20220812 14:12:28 jeff3/172.58.221.231:38556 Incoming Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
20220812 14:12:28 jeff3/172.58.221.231:38556 SENT CONTROL [jeff3]: 'PUSH_REPLY redirect-gateway def1 route-gateway 10.10.10.1 topology subnet ping 10 ping-restart 120 socket-flags TCP_NODELAY ifconfig 10.10.10.2 255.255.255.0 peer-id 0 cipher CHACHA20-POLY1305' (status=1)
20220812 14:12:28 jeff3/172.58.221.231:38556 PUSH: Received control message: 'PUSH_REQUEST'
20220812 14:12:28 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:28 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:28 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:29 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:29 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:29 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:29 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:30 W jeff3/172.58.221.231:38556 IP packet with unknown IP version=15 seen
20220812 14:12:31 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220812 14:12:31 D MANAGEMENT: CMD 'state'
20220812 14:12:31 MANAGEMENT: Client disconnected
20220812 14:12:31 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220812 14:12:31 D MANAGEMENT: CMD 'state'
20220812 14:12:31 MANAGEMENT: Client disconnected
20220812 14:12:31 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220812 14:12:31 D MANAGEMENT: CMD 'state'
20220812 14:12:31 MANAGEMENT: Client disconnected
20220812 14:12:31 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220812 14:12:31 MANAGEMENT: Client disconnected
20220812 14:12:31 NOTE: --mute triggered...
20220812 14:12:31 1 variation(s) on previous 3 message(s) suppressed by --mute
20220812 14:12:31 D MANAGEMENT: CMD 'status 2'
20220812 14:12:31 MANAGEMENT: Client disconnected
20220812 14:12:31 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220812 14:12:31 D MANAGEMENT: CMD 'status 2'
20220812 14:12:31 MANAGEMENT: Client disconnected
20220812 14:12:31 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220812 14:12:31 D MANAGEMENT: CMD 'log 500'
19691231 19:00:00
0220812 14:12:28 W 172.58.221.231:38556 WARNING: 'auth' is used inconsistently local='auth SHA1' remote='auth [null-digest]'
20220812 14:12:28 W 172.58.221.231:38556 WARNING: 'comp-lzo' is present in remote config but missing in local config remote='comp-lzo'
When you set Hash Algorithm in the server to Not Set, that does NOT mean there is no auth directive provided by the server. It just means it will use the default, which is SHA1. But your client config has specified auth none (which disables it). IOW, they are inconsistent, as the syslog mentions.
Also, in the server config you have compression set to Disabled, but the client is set to No. Again, those are NOT the same thing. You should keep compression set to Disabled in the server, and remove the reference to comp-lzo from the client config.
And while you're at it, there should be a space between verb and 4 (it's not supposed to be verb4). Minor issue, but might as well fix it (I'm surprised it didn't complain, OpenVPN tends to nit pick everything).
Joined: 18 Mar 2014 Posts: 12882 Location: Netherlands
Posted: Fri Aug 12, 2022 19:40 Post subject:
I just saw this.
no matter what you do users keep making errors, the OpenVPN setup guide is clear (see attachment, and yes None is different from Not set), There is also a copy paste for the client config:
Of course without comp-lzo no.
I think that this particular error/problem is due to the wrong compression, Auth is overruled by the encryption.
Quote:
client
dev tun
#windows-driver wintun # only for Windows 10 OpenVPN 2.5.x
proto udp4
remote your.domain.ddns.net 1194
nobind
persist-key
persist-tun
remote-cert-tls server
auth-nocache
verb 4
float
tun-mtu 1400 # lowered default can be commented to let OpenVPN decide
auth none # for non GCM or non Chacha ciphers use SHA256
#cipher AES-256-CBC #use AES-256-CBC for older (android) clients
data-ciphers CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM:AES-256-CBC
ca ca.crt
cert client1.crt
key client1.key
0220812 14:12:28 W 172.58.221.231:38556 WARNING: 'auth' is used inconsistently local='auth SHA1' remote='auth [null-digest]'
20220812 14:12:28 W 172.58.221.231:38556 WARNING: 'comp-lzo' is present in remote config but missing in local config remote='comp-lzo'
When you set Hash Algorithm in the server to Not Set, that does NOT mean there is no auth directive provided by the server. It just means it will use the default, which is SHA1. But your client config has specified auth none (which disables it). IOW, they are inconsistent, as the syslog mentions.
But this is *exactly* the setup that the DDWRT OpenVPN Server Setup guide v24 has under "Step 9" with "auth none" that I copied over. This should be corrected in the guide then
Quote:
Also, in the server config you have compression set to Disabled, but the client is set to No. Again, those are NOT the same thing. You should keep compression set to Disabled in the server, and remove the reference to comp-lzo from the client config.
This was *not* obvious - I actually thought I was being consistent:)
Perhaps I missed the highlighting of this distinction in the setup guide...
Quote:
And while you're at it, there should be a space between verb and 4 (it's not supposed to be verb4). Minor issue, but might as well fix it (I'm surprised it didn't complain, OpenVPN tends to nit pick everything).
Thanks @eibgrad and @egc!!!!
suggestions you both made fixed it so that I can see both LAN and WAN IPs.
But I don't have any DNS.
I took a quick look so far at the "DDWRT VPN and DNS 1.2" guide but there is a lot to absorb there covering different cases.
I tried just adding the following to "Additional Configuration" on the ddwrt openvpn server:
Code:
push "dhcp-option DNS 192.168.1.1"
But that didn't work
Is there anything simple that just gives my openvpn clients the exact same DNS as my LAN clients -- no more, no less?
i.e. it can look up anything my LAN clients can and it blocks the non-VPN ISP network DNS.
By default, DNSMasq (the router's DNS server) only listens for queries on the private network (br0).
In order to have DNSMasq respond to the OpenVPN clients, you need to add the tunnel's network interface in the Additional DNSMasq Options field of the Services page.
By default, DNSMasq (the router's DNS server) only listens for queries on the private network (br0).
In order to have DNSMasq respond to the OpenVPN clients, you need to add the tunnel's network interface in the Additional DNSMasq Options field of the Services page.
Code:
interface=tun2
Thanks so much!!! That works.
So it seems that to get DNS I need to do the above plus add
Code:
push "dhcp-option DNS 192.168.1.1"
to "Additional Configuration" under Openvpn.
Do I need to additionally add:
Code:
push "block-outside-dns"
in order to block other DNS coming from the client's underlying Internet connection?
The block-outside-dns directive is only applicable to the client, and only applicable to Windows.
From the OpenVPN documentation:
Quote:
--block-outside-dns
Block DNS servers on other network adapters to prevent DNS leaks. This option prevents any application from accessing TCP or UDP port 53 except one inside the tunnel. It uses Windows Filtering Platform (WFP) and works on Windows Vista or later.
This option is considered unknown on non-Windows platforms and unsupported on Windows XP, resulting in fatal error. You may want to use --setenv opt or --ignore-unknown-option (not suitable for Windows XP) to ignore said error. Note that pushing unknown options from server does not trigger fatal errors.
In fact, I strongly advise anyone using OpenVPN to get familiar w/ the documentation, as it is *very* helpful.
Noted and thanks.
Is there any way to block local client DNS more generally to prevent "DNS leaks"?
Or is this a windows-only possibility as quoted in the manpage.
Noted and thanks.
Is there any way to block local client DNS more generally to prevent "DNS leaks"?
Or is this a windows-only possibility as quoted in the manpage.
Being the client, there really isn't anything the server itself can do to fully control the other side. Even the block-outside-dns directive, if pushed, could simply be ignored w/ the following directive on the OpenVPN client's config.
Code:
pull-filter ignore block-outside-dns
That's why I say, trying to control what the client can and can't do on its side of the tunnel is beyond the control of the server. All the server can do is control what the client can and can't do on *its* side of the tunnel. And using firewall rules is the most common means to limit access by the client.
Now if we're talking about the OpenVPN client side and how YOU might properly configure your own, the following would be a good start.
