2.11.1bug,client internet traffic bug.

Business solution to host your own OpenVPN server with web management interface and bundled clients.
Post Reply
doit2010
OpenVPN User
Posts: 31
Joined: Sat Feb 05, 2022 8:37 am

2.11.1bug,client internet traffic bug.

Post by doit2010 » Wed Nov 09, 2022 2:31 pm

I choose not to use vpn for the internet traffic of the client.
Result: Unable to access the Internet.

client: openvpn-connect-2.7.1.111,win10
Operating environment: as2.11.1,rhel8.6
GATEWAY=192.168.239.2

Image

Image



Client Config
# Automatically generated OpenVPN client config file
# Generated on Wed Nov 9 22:07:21 2022 by localhost.localdomain
# Note: this config file contains inline private keys
# and therefore should be kept confidential!
# Certificate serial: 3, certificate common name: shilh
# Expires 2032-11-06 22:07:21
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=shilh
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=shilh@192.168.239.131

# Default Cipher
cipher AES-256-CBC
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=192.168.239.131:443
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
client
server-poll-timeout 4
nobind
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 443 tcp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
dev tun
dev-type tun
remote-cert-tls server
tls-version-min 1.2
reneg-sec 604800
auth-user-pass
verb 3
push-peer-info

<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
stripped inline key
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----
stripped inline key
-----END OpenVPN Static key V1-----
</tls-crypt>

# Extra user-defined configuration
route 192.168.239.0 255.255.255.0 vpn_gateway
route 172.27.224.0 255.255.255.0 vpn_gateway
route 172.27.240.0 255.255.255.0 vpn_gateway
## -----BEGIN RSA SIGNATURE-----
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----
Last edited by Pippin on Fri Nov 11, 2022 2:42 pm, edited 1 time in total.
Reason: Removed certs and keys

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: 2.11.1bug,client internet traffic bug.

Post by openvpn_inc » Wed Nov 09, 2022 3:46 pm

Hello doit2010,

I would suggest that you follow this procedure;

Under Configuration > Advanced VPN, remove these lines from "Additional OpenVPN Config Directives (advanced)":
route 192.168.239.0 255.255.255.0 vpn_gateway
route 172.27.224.0 255.255.255.0 vpn_gateway
route 172.27.240.0 255.255.255.0 vpn_gateway

and click Save settings.

Go to Configuration > VPN Settings, and under Routing set "Should VPN clients have access to private subnets" to YES, USING NAT.
Put these subnets in the field that appears:
192.168.239.0/24
172.27.224.0/24
172.27.240.0/24

Then set "Should client Internet traffic be routed through the VPN" to "NO.
And then under DNS Settings, set it to "Do not alter client's DNS server settings".

and click Save Settings.

Now click "update running servers".


And now the explanation as to why you should do this;
- If you enable redirecting VPN client Internet traffic through the VPN server, it allows all subnets to pass through and NATs it all. Basically the built-in firewall of Access Server will allow all subnets to come through, not only private subnets. But since you're turning this off, nothing is allowed through and no NATting is performed.
- You are adding client side configuration to specify subnets that need to be sent through, without Access Server being made aware of having to allow these subnets through. Therefore if you turn off client Internet traffic, traffic that Access Server is not aware of should be allowed through, gets dropped by the built-in firewall.
- By doing client side configuration file route rules, you can never update these dynamically from the server side. The only way is to replace the client configuration file with new route rules. This makes little sense because Access Server has a way of pushing routes dynamically when the client connects.
- Using the proper method of pushing routes to VPN clients also means that Access Server is aware of these subnets and expects to allow this traffic through. Therefore the built-in firewall will allow these subnets through. And by specifying NAT, NAT is applied, which is what you were using before.

I am showing you how to configure your Access Server so that it instructs connecting OpenVPN clients to send through the three subnets that you need, and to NAT it so there is no additional routing work that needs to be done in your network to allow this to work. With my method of doing things it's now also possible to add new subnets and the clients will update immediately with this new information, without having to replace client profiles on the client side to get them to receive updated instructions.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: 2.11.1bug,client internet traffic bug.

Post by openvpn_inc » Wed Nov 09, 2022 4:05 pm

Hello again,

Also, looking at your client profile, it says it wants to connect to IP 192.168.239.131. You should go to Configuration > Network Settings and set the Host name or IP address field to an address where your server can always be reached even from the Internet, something like vpn.yourserver.com, which resolves to a public IP where your server is reachable. Otherwise your client connection profiles will be instructed to connect to the private IP 192.168.239.131 which is only reachable from within your private network. Not very useful if you want these VPN clients to be able to connect from anywhere on the Internet.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

doit2010
OpenVPN User
Posts: 31
Joined: Sat Feb 05, 2022 8:37 am

Re: 2.11.1bug,client internet traffic bug.

Post by doit2010 » Sat Nov 12, 2022 2:47 am

openvpn_inc wrote:
Wed Nov 09, 2022 4:05 pm
Hello again,

Also, looking at your client profile, it says it wants to connect to IP 192.168.239.131. You should go to Configuration > Network Settings and set the Host name or IP address field to an address where your server can always be reached even from the Internet, something like vpn.yourserver.com, which resolves to a public IP where your server is reachable. Otherwise your client connection profiles will be instructed to connect to the private IP 192.168.239.131 which is only reachable from within your private network. Not very useful if you want these VPN clients to be able to connect from anywhere on the Internet.

Kind regards,
Johan
thanks,I have solved this problem, but the community client has new problems(Note that it is a community client!)

viewtopic.php?t=34999

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: 2.11.1bug,client internet traffic bug.

Post by openvpn_inc » Sat Nov 12, 2022 12:43 pm

Hello doit2020,

It's nice that you tell us that the community client has new problems, but I don't see it. You're linking to a forum post that links back here and there is no information about a community client problem either here or there.

Community client should be able to connect to Access Server just fine. But most likely there are problems because of the way you're configuring things outside of the recommended ways. If you have any information that shows what the problem is, likely we can tell you how to do it right.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

doit2010
OpenVPN User
Posts: 31
Joined: Sat Feb 05, 2022 8:37 am

Re: 2.11.1bug,client internet traffic bug.

Post by doit2010 » Sun Nov 13, 2022 3:17 am

openvpn_inc wrote:
Sat Nov 12, 2022 12:43 pm
Hello doit2020,

It's nice that you tell us that the community client has new problems, but I don't see it. You're linking to a forum post that links back here and there is no information about a community client problem either here or there.

Community client should be able to connect to Access Server just fine. But most likely there are problems because of the way you're configuring things outside of the recommended ways. If you have any information that shows what the problem is, likely we can tell you how to do it right.

Kind regards,
Johan
that topic is locked,Because custodian think it's the same as this post.

that post is : community client,error


I choose not to use vpn for the internet traffic of the client.it could Access the Internet,but can't access Intranet.log is normal.
client: OpenVPN-2.5.8-I601-amd64, (but client 2.7.1.111 is normal)
Operating environment: as2.11.1,rhel8.6
GATEWAY=192.168.239.2

Image

client
# Automatically generated OpenVPN client config file
# Generated on Fri Nov 11 16:49:19 2022 by localhost.localdomain
# Note: this config file contains inline private keys
# and therefore should be kept confidential!
# Certificate serial: 6, certificate common name: shilh
# Expires 2032-11-08 16:49:19
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=shilh
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=shilh@192.168.239.131

# Default Cipher
cipher AES-256-CBC
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=192.168.239.131:443
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
client
server-poll-timeout 4
nobind
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 443 tcp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
dev tun
dev-type tun
remote-cert-tls server
tls-version-min 1.2
reneg-sec 604800
auth-user-pass
verb 3
push-peer-info

<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-crypt>
## -----BEGIN RSA SIGNATURE-----
## DIGEST:sha256
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## -----END CERTIFICATE-----

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: 2.11.1bug,client internet traffic bug.

Post by openvpn_inc » Sun Nov 13, 2022 2:13 pm

Hello doit2020,

I have edited your post to remove the certificates and private keys from the client configuration file you posted. In the future please post configuration files without their certificates and private key for security reasons.

In your screenshot you show that you use subnet 10.10.10.0/24 to dynamically assign IP addresses to VPN users. That seems fine. But underneath it, it shows that 172.27.240.0/20 is to be used in Access Server to assign static IP addresses. However, 2 of the 3 subnets you're pushing fall within that range:
172.27.224.0/24
172.27.240.0/24

Do you really have these subnets in use outside of your Access Server? If so, then make sure the static IP address subnet is changed to something suitable that you're not already using, like 10.10.20.0/24 or something. If you're not using those subnets, but you added those subnets thinking that that would give access to private subnets on the Access Server, then please remove those 2 subnets. If you configure things correctly in Access Server, then routes for those subnets in Access Server that VPN users will be on that need to be reached will be pushed anyhow.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

doit2010
OpenVPN User
Posts: 31
Joined: Sat Feb 05, 2022 8:37 am

Re: 2.11.1bug,client internet traffic bug.

Post by doit2010 » Mon Nov 14, 2022 3:20 am

openvpn_inc wrote:
Sun Nov 13, 2022 2:13 pm
Hello doit2020,

I have edited your post to remove the certificates and private keys from the client configuration file you posted. In the future please post configuration files without their certificates and private key for security reasons.

In your screenshot you show that you use subnet 10.10.10.0/24 to dynamically assign IP addresses to VPN users. That seems fine. But underneath it, it shows that 172.27.240.0/20 is to be used in Access Server to assign static IP addresses. However, 2 of the 3 subnets you're pushing fall within that range:
172.27.224.0/24
172.27.240.0/24

Do you really have these subnets in use outside of your Access Server? If so, then make sure the static IP address subnet is changed to something suitable that you're not already using, like 10.10.20.0/24 or something. If you're not using those subnets, but you added those subnets thinking that that would give access to private subnets on the Access Server, then please remove those 2 subnets. If you configure things correctly in Access Server, then routes for those subnets in Access Server that VPN users will be on that need to be reached will be pushed anyhow.

Kind regards,
Johan

sorry,i test Many times,The point is not 10.10.10.0/24,I reinstall the software,use community-client-2.5.8 Still inaccessible
https://192.168.239.131:943/admin and https://192.168.239.131:943
[client-2.7.1111 is ok]

Image

clietn
# Automatically generated OpenVPN client config file
# Generated on Mon Nov 14 11:12:35 2022 by localhost.localdomain
# Note: this config file contains inline private keys
# and therefore should be kept confidential!
# Certificate serial: 4, certificate common name: shilh
# Expires 2032-11-11 11:12:35
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=shilh
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=shilh@192.168.239.131

# Default Cipher
cipher AES-256-CBC
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=192.168.239.131:443
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
#
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
client
server-poll-timeout 4
nobind
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 443 tcp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
remote 192.168.239.131 1194 udp
dev tun
dev-type tun
remote-cert-tls server
tls-version-min 1.2
reneg-sec 604800
auth-user-pass
verb 3
push-peer-info

<ca>
-----BEGIN CERTIFICATE-----
MII****
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MII***
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MII***
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----
d4f****
-----END OpenVPN Static key V1-----
</tls-crypt>
## -----BEGIN RSA SIGNATURE-----
## DIGEST:sha256
## n5****
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## MII***
## NNk=
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## MII***

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: 2.11.1bug,client internet traffic bug.

Post by openvpn_inc » Tue Nov 15, 2022 10:35 am

Hi,

It would help if you provide logs from the working and non-working situation. Also would be nice if you could answer if you really use those two subnets that collide with the VPN server subnet. Subnet collission are usually a problem anyhow.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

doit2010
OpenVPN User
Posts: 31
Joined: Sat Feb 05, 2022 8:37 am

Re: 2.11.1bug,client internet traffic bug.

Post by doit2010 » Tue Nov 15, 2022 1:43 pm

openvpn_inc wrote:
Tue Nov 15, 2022 10:35 am
Hi,

It would help if you provide logs from the working and non-working situation. Also would be nice if you could answer if you really use those two subnets that collide with the VPN server subnet. Subnet collission are usually a problem anyhow.

Kind regards,
Johan
I suggest you test according to my configuration (community client - 2.5.8). Some errors occur only during the first connection and disappear the second time. I only copy the second error log.



log(community client - 2.5.8):

2022-11-15 21:37:32 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2022-11-15 21:37:32 OpenVPN 2.5.7 [git:release/2.5/3d792ae9557b959e] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2022
2022-11-15 21:37:32 Windows version 10.0 (Windows 10 or greater) 64bit
2022-11-15 21:37:32 library versions: OpenSSL 1.1.1o 3 May 2022, LZO 2.10
2022-11-15 21:37:32 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
2022-11-15 21:37:32 Need hold release from management interface, waiting...
2022-11-15 21:37:33 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
2022-11-15 21:37:33 MANAGEMENT: CMD 'state on'
2022-11-15 21:37:33 MANAGEMENT: CMD 'log on all'
2022-11-15 21:37:33 MANAGEMENT: CMD 'echo on all'
2022-11-15 21:37:33 MANAGEMENT: CMD 'bytecount 5'
2022-11-15 21:37:33 MANAGEMENT: CMD 'state'
2022-11-15 21:37:33 MANAGEMENT: CMD 'hold off'
2022-11-15 21:37:33 MANAGEMENT: CMD 'hold release'
2022-11-15 21:37:37 MANAGEMENT: CMD 'username "Auth" "shilh"'
2022-11-15 21:37:37 MANAGEMENT: CMD 'password [...]'
2022-11-15 21:37:37 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-11-15 21:37:37 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-11-15 21:37:37 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-11-15 21:37:37 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-11-15 21:37:37 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.239.133:1194
2022-11-15 21:37:37 Socket Buffers: R=[65536->65536] S=[65536->65536]
2022-11-15 21:37:37 UDP link local: (not bound)
2022-11-15 21:37:37 UDP link remote: [AF_INET]192.168.239.133:1194
2022-11-15 21:37:37 MANAGEMENT: >STATE:1668519457,WAIT,,,,,,
2022-11-15 21:37:37 MANAGEMENT: >STATE:1668519457,AUTH,,,,,,
2022-11-15 21:37:37 TLS: Initial packet from [AF_INET]192.168.239.133:1194, sid=0a84d94c fa6799a6
2022-11-15 21:37:37 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2022-11-15 21:37:37 VERIFY OK: depth=1, CN=OpenVPN CA
2022-11-15 21:37:37 VERIFY KU OK
2022-11-15 21:37:37 Validating certificate extended key usage
2022-11-15 21:37:37 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2022-11-15 21:37:37 VERIFY EKU OK
2022-11-15 21:37:37 VERIFY OK: depth=0, CN=OpenVPN Server
2022-11-15 21:37:37 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-11-15 21:37:37 [OpenVPN Server] Peer Connection Initiated with [AF_INET]192.168.239.133:1194
2022-11-15 21:37:38 MANAGEMENT: >STATE:1668519458,GET_CONFIG,,,,,,
2022-11-15 21:37:38 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
2022-11-15 21:37:38 PUSH: Received control message: 'PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 12,ping-restart 50,redirect-private def1,redirect-private bypass-dhcp,redirect-private autolocal,redirect-private bypass-dns,route-gateway 172.27.232.1,route 172.27.240.0 255.255.255.0,route 192.168.239.0 255.255.255.0,route 172.27.224.0 255.255.240.0,block-ipv6,ifconfig 172.27.232.5 255.255.248.0,peer-id 1,auth-tokenSESS_ID,cipher AES-256-GCM'
2022-11-15 21:37:38 Obsolete option --dhcp-release detected. This is now on by default
2022-11-15 21:37:38 WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
2022-11-15 21:37:38 WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
2022-11-15 21:37:38 WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
2022-11-15 21:37:38 OPTIONS IMPORT: timers and/or timeouts modified
2022-11-15 21:37:38 OPTIONS IMPORT: explicit notify parm(s) modified
2022-11-15 21:37:38 OPTIONS IMPORT: --ifconfig/up options modified
2022-11-15 21:37:38 OPTIONS IMPORT: route options modified
2022-11-15 21:37:38 OPTIONS IMPORT: route-related options modified
2022-11-15 21:37:38 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2022-11-15 21:37:38 OPTIONS IMPORT: peer-id set
2022-11-15 21:37:38 OPTIONS IMPORT: adjusting link_mtu to 1624
2022-11-15 21:37:38 OPTIONS IMPORT: data channel crypto options modified
2022-11-15 21:37:38 Data Channel: using negotiated cipher 'AES-256-GCM'
2022-11-15 21:37:38 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-11-15 21:37:38 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-11-15 21:37:38 interactive service msg_channel=628
2022-11-15 21:37:38 open_tun
2022-11-15 21:37:38 tap-windows6 device [OpenVPN TAP-Windows6] opened
2022-11-15 21:37:38 TAP-Windows Driver Version 9.24
2022-11-15 21:37:38 Set TAP-Windows TUN subnet mode network/local/netmask = 172.27.232.0/172.27.232.5/255.255.248.0 [SUCCEEDED]
2022-11-15 21:37:38 Notified TAP-Windows driver to set a DHCP IP/netmask of 172.27.232.5/255.255.248.0 on interface {22DD3C0C-75F0-4E7A-A383-975C46B5743A} [DHCP-serv: 172.27.232.0, lease-time: 31536000]
2022-11-15 21:37:38 Successful ARP Flush on interface [5] {22DD3C0C-75F0-4E7A-A383-975C46B5743A}
2022-11-15 21:37:38 TAP: DHCP address released
2022-11-15 21:37:38 TAP: DHCP address renewal succeeded
2022-11-15 21:37:38 MANAGEMENT: >STATE:1668519458,ASSIGN_IP,,172.27.232.5,,,,
2022-11-15 21:37:38 IPv4 MTU set to 1500 on interface 5 using service
2022-11-15 21:37:43 TEST ROUTES: 4/4 succeeded len=3 ret=1 a=0 u/d=up
2022-11-15 21:37:43 C:\Windows\system32\route.exe ADD 114.x.x.x MASK 255.255.255.255 192.168.1.1
2022-11-15 21:37:43 Route addition via service succeeded
2022-11-15 21:37:43 MANAGEMENT: >STATE:1668519463,ADD_ROUTES,,,,,,
2022-11-15 21:37:43 C:\Windows\system32\route.exe ADD 172.27.240.0 MASK 255.255.255.0 172.27.232.1 METRIC 101
2022-11-15 21:37:43 Route addition via service succeeded
2022-11-15 21:37:43 C:\Windows\system32\route.exe ADD 192.168.239.0 MASK 255.255.255.0 172.27.232.1 METRIC 101
2022-11-15 21:37:43 Route addition via service succeeded
2022-11-15 21:37:43 C:\Windows\system32\route.exe ADD 172.27.224.0 MASK 255.255.240.0 172.27.232.1 METRIC 101
2022-11-15 21:37:43 Route addition via service succeeded
2022-11-15 21:37:43 Initialization Sequence Completed
2022-11-15 21:37:43 MANAGEMENT: >STATE:1668519463,CONNECTED,SUCCESS,172.27.232.5,192.168.239.133,1194,,
Last edited by Pippin on Tue Nov 15, 2022 6:16 pm, edited 1 time in total.
Reason: Removed the 114.x.x.x/32 IP

User avatar
openvpn_inc
OpenVPN Inc.
Posts: 1333
Joined: Tue Feb 16, 2021 10:41 am

Re: 2.11.1bug,client internet traffic bug.

Post by openvpn_inc » Tue Nov 15, 2022 1:54 pm

Hello doit2020,

We already test OpenVPN open source client against Access Server, and it works. I can't test your configuration because I only get bits and pieces of your configuration. And I'm asking questions to get to the bottom of the problem that simply don't get answered.

Last attempt from my side to get this answered. These 2 subnets:
172.27.224.0/24
172.27.240.0/24

Are you actually using those in your network? Because they are conflicting with your internal VPN subnet. That's a subnet collission that should be resolved. You should either stop pushing those routes or change your VPN subnet.

Let's get that out of the way before going further.

Kind regards,
Johan
Image OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support

doit2010
OpenVPN User
Posts: 31
Joined: Sat Feb 05, 2022 8:37 am

Re: 2.11.1bug,client internet traffic bug.

Post by doit2010 » Wed Nov 16, 2022 9:20 am

openvpn_inc wrote:
Tue Nov 15, 2022 1:54 pm
Hello doit2020,

We already test OpenVPN open source client against Access Server, and it works. I can't test your configuration because I only get bits and pieces of your configuration. And I'm asking questions to get to the bottom of the problem that simply don't get answered.

Last attempt from my side to get this answered. These 2 subnets:
172.27.224.0/24
172.27.240.0/24

Are you actually using those in your network? Because they are conflicting with your internal VPN subnet. That's a subnet collission that should be resolved. You should either stop pushing those routes or change your VPN subnet.

Let's get that out of the way before going further.

Kind regards,
Johan

This time, I passed the VMware Workstation test of the local machine(vmware workstation GATEWAY=192.168.239.2).
The client-2.7.1.111 is OK. the community-client-2.5.8 inaccessible https://192.168.239.131:943/admin and https://192.168.239.131:943

if no having vpn,I did not use 172.27.224.0/24 172.27.240.0/24, Otherwise, why is the The client-2.7.1.111 normal

Since your test is normal, I will replace the server (rhel8.6) next time.

doit2010
OpenVPN User
Posts: 31
Joined: Sat Feb 05, 2022 8:37 am

Re: 2.11.1bug,client internet traffic bug.

Post by doit2010 » Mon Dec 05, 2022 4:46 am

openvpn_inc wrote:
Tue Nov 15, 2022 1:54 pm
Hello doit2020,

We already test OpenVPN open source client against Access Server, and it works. I can't test your configuration because I only get bits and pieces of your configuration. And I'm asking questions to get to the bottom of the problem that simply don't get answered.

Last attempt from my side to get this answered. These 2 subnets:
172.27.224.0/24
172.27.240.0/24

Are you actually using those in your network? Because they are conflicting with your internal VPN subnet. That's a subnet collission that should be resolved. You should either stop pushing those routes or change your VPN subnet.

Let's get that out of the way before going further.

Kind regards,
Johan
the client :OpenVPN-2.6_beta1-I001-amd64 seems normal. I hope the tester can test it as completely as possible

but client(OpenVPN-2.6_beta1-I001-amd64) Although the use seems normal, there is an error log:


2022-12-05 12:39:09 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

2022-12-05 12:39:10 Obsolete option --dhcp-release detected. This is now on by default
2022-12-05 12:39:10 WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
2022-12-05 12:39:10 WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
2022-12-05 12:39:10 WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results


OpenVPN-2.6_beta1-I001


# Automatically generated OpenVPN client config file
# Generated on Mon Dec 5 12:38:02 2022 by debian
# Note: this config file contains inline private keys
# and therefore should be kept confidential!
# Certificate serial: 6, certificate common name: shilh
# Expires 2032-12-02 12:38:01
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=shilh
# Define the profile name of this particular configuration file
# OVPN_ACCESS_SERVER_PROFILE=shilh@192.168.239.140

# Default Cipher
cipher AES-256-CBC
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=192.168.239.140:443
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
# MII***************
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
client
server-poll-timeout 4
nobind
remote 192.168.239.140 1194 udp
remote 192.168.239.140 1194 udp
remote 192.168.239.140 443 tcp
remote 192.168.239.140 1194 udp
remote 192.168.239.140 1194 udp
remote 192.168.239.140 1194 udp
remote 192.168.239.140 1194 udp
remote 192.168.239.140 1194 udp
dev tun
dev-type tun
remote-cert-tls server
tls-version-min 1.2
reneg-sec 604800
auth-user-pass
verb 3
push-peer-info

<ca>
-----BEGIN CERTIFICATE-----
MII**********************
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MII******************
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MII*****************8
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key (Server Agent)
#
-----BEGIN OpenVPN Static key V1-----
e**************
-----END OpenVPN Static key V1-----
</tls-crypt>
## -----BEGIN RSA SIGNATURE-----
## DIGEST:sha256
## P726SDIljrN9RIgB8u2pNjPkCXrk9ZyppQCvjnVhJKbkPVuJTn
## 0f7+k996w2Iv+prKT9NJ8/the+y5usb31lXnIiP+MwrqNowqZ8
## 6W6GORTmGm+36Yz5BnSDH2f3kZbd8GzKJmiGZZNHmJNJmf84hN
## dNXUu0UGpScNBYJS1xJDEHZwKDiuZnAqMjf8zEDqGPOMaQvAzF
## /cWi1kKKKSWTYgP8Am1nnIZTq0lFXoNxa4LdxuMHU2yaCggC5j
## cEoLeJzEfXpi7VUuDOD/EJPk4Far/d7O7Zh0ynFS0FkAclHBXY
## KN1YcyF7DEWFiG0JuI0Ul/eDb0Ud13X+YaaA6LlJtw==
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
## MII***************
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
## MII***********
## -----END CERTIFICATE-----

Post Reply