LinuxQuestions.org - OpenVPN client ip

- Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)

- - OpenVPN client ip (https://www.linuxquestions.org/questions/linux-server-73/openvpn-client-ip-4175594916/)

OpenVPN client ip

Hi LQ,
i have openvpn running on my VPS, this is the vpn *.conf file i have:

Code:

port 1194



proto udp



ca /etc/openvpn/ssl/root.crt

cert /etc/openvpn/ssl/cert.pem

key /etc/openvpn/ssl/key.pem 



dh /etc/openvpn/ssl/dh4096.pem



tls-server

tls-auth /etc/openvpn/ssl/ta.key 0

remote-cert-tls client

auth SHA512

cipher AES-256-CBC

tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

server 192.168.0.0 255.255.0.0

#ifconfig-pool 192.168.0.0 255.255.0.0

push "remote-gateway def1 bypass-dhcp"

client-config-dir /etc/openvpn/clients

push "ifconfig 192.168.0.0 255.255.0.0"

push "route 192.168.0.0 255.255.0.0"

push "explicit-exit-notify 2"

push "redirect-gateway"

push "dhcp-option DNS 208.67.220.220"

push "dhcp-option DNS 208.67.222.222"



duplicate-cn

#client-cert-not-required

keepalive 10 120

comp-lzo

max-clients 20

user nobody

group nogroup

persist-key

persist-tun

persist-local-ip

reneg-sec 432000

log        /var/log/openvpn/openvpn.log

verb 6

mute 20

script-security 3

username-as-common-name

auth-user-pass-verify    /etc/openvpn/scripts/login.sh via-env

plugin /etc/openvpn/mysql-auth/libopenvpn-mysql-auth.so -c /etc/openvpn/mysql-auth/mysql-auth.conf

client-connect          /etc/openvpn/scripts/connect.sh

client-disconnect      /etc/openvpn/scripts/disconnect.sh

The issue is about browsing which is always not properly fluent. IMHO is a DNS issue inside the VPN.
Looking at logs everything goes smooth apart from this:

Code:

MULTI: bad source address from client [192.168.1.28], packet dropped

which is the client WLAN0 ip ...

Code:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

          inet addr:192.168.0.2  P-t-P:192.168.0.2  Mask:255.255.0.0

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

          RX packets:411 errors:0 dropped:0 overruns:0 frame:0

          TX packets:588 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100 

          RX bytes:104259 (104.2 KB)  TX bytes:70836 (70.8 KB)



wlp2s0    Link encap:Ethernet  HWaddr d0:53:49:83:e5:ad  

          inet addr:192.168.1.28  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: fe80::d253:49ff:fe83:e5ad/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:6561 errors:0 dropped:0 overruns:0 frame:0

          TX packets:7418 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:3316795 (3.3 MB)  TX bytes:3461206 (3.4 MB)

The dropped packets you see in log above it is a quite common issue and the most advice to add directive

Quote:

client-config-dir

and the inside file has :

Quote:

iroute 192.168.0.0 255.255.0.0

in it. Someone else advice to add an ifconfig and at this stage i can say i'm confused even because the 192.168.1.28 packets keep on being dropped and connection is not stable at all.
I hope my message is clear, any help appreciated, regards !

May I refer you to my recent post: [HOWTO] A Quick Explanation of Routing Setup With OpenVPN Tunnels.

The iroute directive, which must appear in a client-config-dir entry whose name matches the "common name" of the connecting remote, tells OpenVPN about the existence of a remote subnet. The identity of the file in which this directive appears, is what indicates which remote supports that particular subnet.

In order to successfully route any packet, OpenVPN must know about the subnet from whence it came or to whence it is going. If it does not, then it has no choice but to drop the packet. It does not attempt to consult operating-system routing tables nor any other resource.

When you connect with the client whose CN= name matches the filename in the CCD subdirectory, you should see messages in the OpenVPN log which indicate that this file has been found and read.

You probably do not need any directives other than iroute in this CCD-entry. But, note that there must also be a corresponding route directive, so that OpenVPN will issue a route-command to the host operating system to cause the traffic to be delivered to OpenVPN's tunX virtual device in the first place. (I seem to recall reading that this must be in the main file, but don't quote me on that.)

If you have this entry, but you are still getting "bad source address from client - packet dropped," then it means that OpenVPN is not using the content of that file. It isn't recognizing it. The CN= of the remote's certificate did not exactly match the name of a file within the CCD location, and there also was no DEFAULT entry there. You see this only by the fact that the entries which indicate that a CCD entry was read are not found in the log when this remote connects.

Consider all of the directives that you have chosen to place here, particularly redirect-gateway and duplicate-cn. ... P-a-r-t-i-c-u-l-a-r-l-y the latter, since you are using CCD. Remember that it is the "common name" which identifies a remote, and in this case you can't tolerate there being more than one simultaneously-connected remote by this particular name.

Quote:

Originally Posted by sundialsvcs (Post 5639100)

Consider all of the directives that you have chosen to place here, particularly redirect-gateway and duplicate-cn. ... P-a-r-t-i-c-u-l-a-r-l-y the latter, since you are using CCD. Remember that it is the "common name" which identifies a remote, and in this case you can't tolerate there being more than one simultaneously-connected remote by this particular name.

As you will notice in my client's cert, certificate i created by pkitool, i used kthulhu a not fully qualified domain name. I also named the CCD's file with client's hostname connecting as indicated by a guide a found googling. Now i show you the client's cert.pem:

Code:

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 2 (0x2)

    Signature Algorithm: sha256WithRSAEncryption

        Issuer: C=XX, ST=Xxxx, L=Xxxx, O=Xxxxxxxxxxxxxxxx, OU=VPN, CN=vpn.localhost/name=EasyRSA/emailAddress=admin@localhost

        Validity

            Not Before: Dec  4 12:22:24 2016 GMT

            Not After : Dec  2 12:22:24 2026 GMT

        Subject: C=XX, ST=Xxxx, L=Xxxx, O=XXXXXXXXXXXXXXXXXXX, OU=VPN, CN=kthulhu/name=EasyRSA/emailAddress=admin@localhost

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (4096 bit)

                Modulus:

                    00:bb:41:e1:7b:38:a9:f8:f2:f6:97:0c:1d:d0:1b:

                    cb:33:f2.......

                    1b:69:55

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Basic Constraints: 

                CA:FALSE

            Netscape Comment: 

                Easy-RSA Generated Certificate

            X509v3 Subject Key Identifier: 

                02:86:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:B8

            X509v3 Authority Key Identifier: 

                keyid:CF:C8:6C:XXXXXXXXXXXXXXXXXXXXXXXXXXXXX:48

                DirName:/C=XX/ST=XXxx/L=Xxxx/O=XXXXXXxxxxXXXX/OU=VPN/CN=vpn.localhost/name=EasyRSA/emailAddress=admin@localhost

                serial:CE:5E:XXXXXXX:73



            X509v3 Extended Key Usage: 

                TLS Web Client Authentication

            X509v3 Key Usage: 

                Digital Signature

            X509v3 Subject Alternative Name: 

                DNS:client1

    Signature Algorithm: sha256WithRSAEncryption

        34:07:57:1f:4b:3e:cf:39:69:d5:1c:5e:16:3f:51:c2:e0:04:

        82:04:30:35:6d:49:.... 2d:12:b4:d1:b0:56:6d:7c:f6:df:6b:99:

        3d:9f:07:01:64:c5:e4:06

Certificate purposes:

SSL client : Yes

SSL client CA : No

SSL server : No

SSL server CA : No

Netscape SSL server : No

Netscape SSL server CA : No

S/MIME signing : No

S/MIME signing CA : No

S/MIME encryption : No

S/MIME encryption CA : No

CRL signing : No

CRL signing CA : No

Any Purpose : Yes

Any Purpose CA : Yes

OCSP helper : Yes

OCSP helper CA : No

Time Stamp signing : No

Time Stamp signing CA : No

it looks all right to me.
For routing i forced C class 192.168.1.0 client's network to B class 192.168.0.0 for server network TUN0 interface, just to make sure there are no conflicts or more iptables directives.
Regards

Pardon me if I'm not going to try to diagnose this myself. :)

When you connect the client in question, you will see in the logs what its "common name" is (as seen by OpenVPN), and, if a ccd entry is successfully found and read, you will also see the effects of the iroute command. (Simply grep for the IP-address of the remote subnet ...) If you don't see that, the ccd entry was not found and OpenVPN does not know about the remote subnet.

Yees, it looks good so far ...

Quote:

egrep kthulhu /var/log/openvpn/openvpn.log

Tue Dec 6 16:59:30 2016 us=387806 79.46.188.196:56758 VERIFY OK: depth=0, C=XX, ST=Xxxx, L=Xxxx, O=XXXXXXXXXXXXX, OU=VPN, CN=kthulhu, name=EasyRSA, emailAddress=admin@localhost

or ...

Quote:

egrep 192.168.0.0 /var/log/openvpn/openvpn.log
Tue Dec 6 16:59:32 2016 us=790585 user/11.22.33.44:56758 SENT CONTROL [user]: 'PUSH_REPLY,topology subnet,remote-gateway def1 bypass-dhcp,ifconfig 192.168.0.0 255.255.0.0,route 192.168.0.0 255.255.0.0,explicit-exit-notify 2,redirect-gateway,dhcp-option DNS 208.67.220.220,dhcp-option DNS 208.67.222.222,route-gateway 192.168.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.0.2 255.255.0.0' (status=1)

Quote:

egrep 'CN' /var/log/openvpn/openvpn.log
Tue Dec 6 16:59:30 2016 us=385391 79.46.188.196:56758 VERIFY OK: depth=1, C=XX, ST=Xxxx, L=Xxxx, O=XXXXXXXXXXXXXXX, OU=VPN, CN=vpn.domain.ltd, name=EasyRSA, emailAddress=admin@localhost

What I would be looking for in /var/log/syslog are log entries which make specific reference to the first few octets of the remote subnet ... specifically at-or-about the point where that client is (successfully) connecting to the server.

Disconnect and reconnect the client, then immediately look at the syslog. You should plainly see messages to the effect that the CCD entry has been correctly identified and processed.

In the entries you have posted I do not yet see what I am looking for. (And, I am not readily in a position to re-create it.)