My openVPN is screwed up after updates

Offline

My openVPN is screwed up after updates

Resolved

0 votes

Hi all
During the summer I had problems with our ClearOS7 gateway with a file server accessed by OpenVPN having multiple WAN and Multiwan app.

I noticed that the webinterface displayed "connection error" and had no updates installed for some time. Syslog showed hartbeat errors and the forum gave me a hint to manually update the network interface which I found was going up and down. During this I also changed the role of the interfaces (machine has 3 and one of them is only standby/backup). The wan interface started to work again after driver update but I could not reach any devices on the LAN over openVPN.
Today I troubleshooted but could not find any error to correct. I removed the extra interface and the multiwan app, tested small changes in the configuration and rebooted several times. VPN connects nicely but nothing is accessible.

I did tcpdump on ClearOS server to look for a ping to a lan device (192.168.156.109) from vpn client (10.9.0.6) but don't see a reply.

tcpdump -eni any icmp

...

17:26:11.907203  In ethertype IPv4 (0x0800), length 76: 10.9.0.6 > 192.168.156.109: ICMP echo request, id 1, seq 588, length 40

How should I proceed?

/Sven

In OpenVPN

Monday, August 24 2020, 02:56 PM

Share this post:

Responses (10)

Accepted Answer

Sven Jungmar

Offline
Wednesday, August 26 2020, 01:51 PM - #Permalink
Resolved

0 votes

Nick Howitt wrote:

The problem you have is the ping is going through ClearOS but nothing is coming back. It is not ClearOS mis-routing the replies. There just aren't any replies.

You are of course right Nick. The target machine is a CentOS8 and it seems the firewall on that one is no longer accepting traffic from other networks. I must have screwed up the VPN when I couldnd get it to work. Troubleshooting continues on that machine (not ClearOS).
Thank you very much for your assistance.
The reply is currently minimized Show
Accepted Answer
Nick Howitt

Offline
Tuesday, August 25 2020, 08:43 PM - #Permalink
Resolved

0 votes

For readability for the user who does not know (me) can you add the -nn switch to your tcpdump? You don't need to re-run it for the moment. The problem you have is the ping is going through ClearOS but nothing is coming back. It is not ClearOS mis-routing the replies. There just aren't any replies. There is no point looking any more at ClearOS. The problem is elsewhere. Are the pings getting through to the target? Is the target replying? If so, where is it replying to? Is there a managed switch in the way blocking things or do you have basic switched?
The reply is currently minimized Show

Accepted Answer

Sven Jungmar

Offline

Tuesday, August 25 2020, 04:59 PM - #Permalink

Resolved

0 votes

Nick Howitt wrote:

Got it. You've put both the UDP and TCP configs on the same subnet. They must be on different subnets.

Yup, true. I wonder how that happend, don't use tcp. Fixed in tcp-client.conf. Now I can ping the LAN interface and access the fileserver via openVPN but still can't access devices on the LAN so still something weired with routing. Ping now go out but don't come back on VPN. Are the firewall rules OK? They should be set automatic I understand.

[root@server ~]# route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

default         h-98-128-230-41 0.0.0.0         UG    0      0        0 enp0s31f6

10.9.0.0        10.9.0.2        255.255.255.0   UG    0      0        0 tun0

10.9.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

10.9.1.0        10.9.1.2        255.255.255.0   UG    0      0        0 tun1

10.9.1.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun1

98.128.230.40   0.0.0.0         255.255.255.248 U     0      0        0 enp0s31f6

192.168.24.0    0.0.0.0         255.255.255.0   U     0      0        0 enp3s0

192.168.156.0   0.0.0.0         255.255.255.0   U     0      0        0 enp5s0

[root@server ~]#

(I added the 3rd interface and Multiwan app again.)

[root@server ~]# tcpdump -i enp5s0 icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes

18:49:03.882481 IP 10.9.0.6 > controlunit.xxxxx.net: ICMP echo request, id 1, seq 10, length 40

18:49:08.884674 IP 10.9.0.6 > controlunit.xxxxx.net: ICMP echo request, id 1, seq 11, length 40

What else should I check?

The reply is currently minimized Show

Accepted Answer
Nick Howitt

Offline
Tuesday, August 25 2020, 11:40 AM - #Permalink
Resolved

0 votes

Got it. You've put both the UDP and TCP configs on the same subnet. They must be on different subnets.
The reply is currently minimized Show

Accepted Answer

Sven Jungmar

Offline

Tuesday, August 25 2020, 11:24 AM - #Permalink

Resolved

0 votes

Here's the outputs. Thanks for helping out



Pingning from Win-PC over open VPN 

[root@server ~]# tcpdump -i enp5s0 icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes

^C

0 packets captured

0 packets received by filter

0 packets dropped by kernel

[root@server ~]#



Pinging from ClearOS

[root@server ~]# tcpdump -i enp5s0 icmp

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on enp5s0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:21:46.403991 IP server.xxxxx.net > ap.xxxxx.net: ICMP echo request, id 29630, seq 6, length 64

13:21:47.403996 IP server.xxxxx.net > ap.xxxxx.net: ICMP echo request, id 29630, seq 7, length 64

13:21:48.403911 IP server.xxxxx.net > ap.xxxxx.net: ICMP echo request, id 29630, seq 8, length 64

13:21:48.404184 IP ap.xxxxx.net > server.xxxxx.net: ICMP echo reply, id 29630, seq 8, length 64

13:21:49.403983 IP server.xxxxx.net > ap.xxxxx.net: ICMP echo request, id 29630, seq 9, length 64

13:21:49.404180 IP ap.xxxxx.net > server.xxxxx.net: ICMP echo reply, id 29630, seq 9, length 64

13:21:50.403981 IP server.xxxxx.net > ap.xxxxx.net: ICMP echo request, id 29630, seq 10, length 64

13:21:50.404194 IP ap.xxxxx.net > server.xxxxx.net: ICMP echo reply, id 29630, seq 10, length 64

13:21:51.403985 IP server.xxxxx.net > ap.xxxxx.net: ICMP echo request, id 29630, seq 11, length 64

13:21:51.404283 IP ap.xxxxx.net > server.xxxxx.net: ICMP echo reply, id 29630, seq 11, length 64

13:21:52.403920 IP server.xxxxx.net > ap.xxxxx.net: ICMP echo request, id 29630, seq 12, length 64

13:21:52.404110 IP ap.xxxxx.net > server.xxxxx.net: ICMP echo reply, id 29630, seq 12, length 64

^C

12 packets captured

12 packets received by filter

0 packets dropped by kernel

[root@server ~]#







# Tip - if you are using this as a template for configuring other VPNs:

# - the ifconfig-pool-persist file must be unique

# - the port/protocol combination must be unique

# - different server IPs are recommended

# - don't forget about the firewall

port 1194

proto udp

dev tun

ca /etc/pki/CA/ca-cert.pem

cert /etc/pki/CA/sys-0-cert.pem

key /etc/pki/CA/private/sys-0-key.pem

dh /etc/openvpn/ssl/dh1024.pem

server 10.9.0.0 255.255.255.0

keepalive 10 120

user nobody

group nobody

multihome

persist-key

persist-tun

ifconfig-pool-persist /var/lib/openvpn/ipp.txt 120

status /var/lib/openvpn/openvpn-status.log

plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

verb 3

push "dhcp-option DNS 192.168.156.1"

push "dhcp-option DOMAIN xxxxx.net"

push "dhcp-option WINS 192.168.156.1"

push "route 192.168.156.0 255.255.255.0"

# added by Sven

#reneg-bytes 64000000

compress stub-v2

push "compress stub-v2"

client-to-client





[root@server ~]# iptables -nvL

Chain INPUT (policy DROP 58 packets, 2322 bytes)

 pkts bytes target     prot opt in     out     source               destination

   31  2296 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set f2b-sshd-ddos src reject-with icmp-port-unreachable

    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set f2b-sshd src reject-with icmp-port-unreachable

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set snortsam_INGRESS src

    4   304 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:123 state RELATED,ESTABLISHED

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID

    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x12/0x12 state NEW reject-with tcp-reset

    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:!0x17/0x02 state NEW

    0     0 DROP       all  --  enp0s31f6 *       127.0.0.0/8          0.0.0.0/0

   54  5276 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0

    0     0 ACCEPT     all  --  pptp+  *       0.0.0.0/0            0.0.0.0/0

    0     0 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0

  812 72160 ACCEPT     all  --  enp5s0 *       0.0.0.0/0            0.0.0.0/0

    3    87 ACCEPT     icmp --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            icmptype 0

    0     0 ACCEPT     icmp --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            icmptype 3

    1    36 ACCEPT     icmp --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            icmptype 8

    0     0 ACCEPT     icmp --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            icmptype 11

    0     0 ACCEPT     udp  --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68

    0     0 ACCEPT     tcp  --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            tcp spt:67 dpt:68

    2    80 ACCEPT     tcp  --  *      *       0.0.0.0/0            98.128.230.43        tcp dpt:80

    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            98.128.230.43        tcp dpt:443

    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            98.128.230.43        udp dpt:1194

    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            98.128.230.43        tcp dpt:1194

  269 16284 ACCEPT     tcp  --  *      *       0.0.0.0/0            98.128.230.43        tcp dpt:2223

  248 54312 ACCEPT     tcp  --  *      *       0.0.0.0/0            98.128.230.43        tcp dpt:10000

  134 43510 ACCEPT     tcp  --  *      *       0.0.0.0/0            98.128.230.43        tcp dpt:81

  765  103K ACCEPT     udp  --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            udp dpts:1024:65535 state RELATED,ESTABLISHED

   11 17585 ACCEPT     tcp  --  enp0s31f6 *       0.0.0.0/0            0.0.0.0/0            tcp dpts:1024:65535 state RELATED,ESTABLISHED



Chain FORWARD (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set snortsam_SELF src,dst,dst

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set snortsam_EGRESS dst

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set snortsam_INGRESS src

   19  5080 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

    0     0 ACCEPT     all  --  pptp+  *       0.0.0.0/0            0.0.0.0/0

    0     0 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0

   18  1080 ACCEPT     all  --  enp5s0 *       0.0.0.0/0            0.0.0.0/0



Chain OUTPUT (policy DROP 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set snortsam_SELF src,dst,dst

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set snortsam_EGRESS dst

   54  5276 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0

    0     0 ACCEPT     all  --  *      pptp+   0.0.0.0/0            0.0.0.0/0

    0     0 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0

  770  103K ACCEPT     all  --  *      enp5s0  0.0.0.0/0            0.0.0.0/0

   34  3195 ACCEPT     icmp --  *      enp0s31f6  0.0.0.0/0            0.0.0.0/0

    0     0 ACCEPT     udp  --  *      enp0s31f6  0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67

    0     0 ACCEPT     tcp  --  *      enp0s31f6  0.0.0.0/0            0.0.0.0/0            tcp spt:68 dpt:67

    5   220 ACCEPT     tcp  --  *      enp0s31f6  98.128.230.43        0.0.0.0/0            tcp spt:80

    0     0 ACCEPT     tcp  --  *      enp0s31f6  98.128.230.43        0.0.0.0/0            tcp spt:443

    0     0 ACCEPT     udp  --  *      enp0s31f6  98.128.230.43        0.0.0.0/0            udp spt:1194

    0     0 ACCEPT     tcp  --  *      enp0s31f6  98.128.230.43        0.0.0.0/0            tcp spt:1194

  414 99764 ACCEPT     tcp  --  *      enp0s31f6  98.128.230.43        0.0.0.0/0            tcp spt:2223

  248 41147 ACCEPT     tcp  --  *      enp0s31f6  98.128.230.43        0.0.0.0/0            tcp spt:10000

  125  154K ACCEPT     tcp  --  *      enp0s31f6  98.128.230.43        0.0.0.0/0            tcp spt:81

  781 49190 ACCEPT     all  --  *      enp0s31f6  0.0.0.0/0            0.0.0.0/0



Chain DROP-lan (0 references)

 pkts bytes target     prot opt in     out     source               destination

    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

[root@server ~]#





[root@server ~]# iptables -nvL -t nat

Chain PREROUTING (policy ACCEPT 999 packets, 72933 bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain INPUT (policy ACCEPT 878 packets, 66578 bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain OUTPUT (policy ACCEPT 799 packets, 49796 bytes)

 pkts bytes target     prot opt in     out     source               destination



Chain POSTROUTING (policy ACCEPT 16 packets, 1322 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0

  790 48894 MASQUERADE  all  --  *      enp0s31f6  0.0.0.0/0            0.0.0.0/0

[root@server ~]#





[root@server ~]# route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

default         h-98-128-230-41 0.0.0.0         UG    0      0        0 enp0s31f6

10.9.0.0        10.9.0.2        255.255.255.0   UG    0      0        0 tun0

10.9.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

10.9.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun1

98.128.230.40   0.0.0.0         255.255.255.248 U     0      0        0 enp0s31f6

192.168.156.0   0.0.0.0         255.255.255.0   U     0      0        0 enp5s0

[root@server ~]#

The reply is currently minimized Show

Accepted Answer
Nick Howitt

Offline
Monday, August 24 2020, 08:05 PM - #Permalink
Resolved

0 votes

Can you run the tcpdump on the LAN interface?

What is the contents of /etc/openvpn/clients.conf and the output to:
iptables -nvL iptables -nvL -t nat
Please put the results between code tags (the piece of paper icon with a <> on it)?
The reply is currently minimized Show
Accepted Answer

Sven Jungmar

Offline
Monday, August 24 2020, 07:24 PM - #Permalink
Resolved

0 votes

I can't access any device on the LAN via openVPN, not even the LAN-interface (with fileserver) on the ClearOS-box. This has all worked withyout a flaw for years with the same setup, until now.

I have from scratch changed the openVPN subnet to 10.9.0.0 to avoid conflict with another VPN-server

Sven Jungmar wrote:
The Lan devices are Linux and embedded devices. It has worked and no changes has been done to any config but there were problem with interface, syswatch and some updates.

None are Windows devices.
The reply is currently minimized Show
Accepted Answer
Nick Howitt

Offline
Monday, August 24 2020, 07:15 PM - #Permalink
Resolved

0 votes

If your LAN device you are pinging is a Wondoze device, you'll need to add an exception in the Windoze firewall for the OpenVPN subnet which you seem to have changed to 10.0.0.0/24. By default the Windozw firewall only allows pings ( and a lot of other communication) from its local LAN.
The reply is currently minimized Show

Accepted Answer

Sven Jungmar

Offline

Monday, August 24 2020, 06:21 PM - #Permalink

Resolved

0 votes

Nick Howitt wrote:

MultiWAN errors can be caused by syswatch not running. Check that is it running and enabled:
systemctl status syswatch

systemctl is-enabled syswatch
Is the LAN device a Windows machine? If it is, try enabling "Enable NAT (Gateway mode only)" in OpenVPN.

Can you post the connection logs from the client and ClearOS. In ClearOS they are part of the messages log.

Thanks for any help Nick.

syswatch is running now after I updated rtl8169 driver this summer and removed Multiwan today.

The Lan devices are Linux and embedded devices. It has worked and no changes has been done to any config but there were problem with interface, syswatch and some updates.

We are several people coming from outside and need to be identified by unique IP so NAT is not a choice.

Not sure what lines from logs that are relevant, there are plenty.....



Client log



Mon Aug 24 19:57:27 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020

Mon Aug 24 19:57:27 2020 Windows version 6.2 (Windows 8 or greater) 64bit

Mon Aug 24 19:57:27 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10

Enter Management Password:

Mon Aug 24 19:57:27 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25343

Mon Aug 24 19:57:27 2020 Need hold release from management interface, waiting...

Mon Aug 24 19:57:28 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25343

Mon Aug 24 19:57:28 2020 MANAGEMENT: CMD 'state on'

Mon Aug 24 19:57:28 2020 MANAGEMENT: CMD 'log all on'

Mon Aug 24 19:57:28 2020 MANAGEMENT: CMD 'echo all on'

Mon Aug 24 19:57:28 2020 MANAGEMENT: CMD 'bytecount 5'

Mon Aug 24 19:57:28 2020 MANAGEMENT: CMD 'hold off'

Mon Aug 24 19:57:28 2020 MANAGEMENT: CMD 'hold release'

Mon Aug 24 19:57:37 2020 MANAGEMENT: CMD 'username "Auth" "svju"'

Mon Aug 24 19:57:37 2020 MANAGEMENT: CMD 'password [...]'

Mon Aug 24 19:57:37 2020 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.

Mon Aug 24 19:57:37 2020 MANAGEMENT: >STATE:1598291857,RESOLVE,,,,,,

Mon Aug 24 19:57:37 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]98.128.230.43:1194

Mon Aug 24 19:57:37 2020 Socket Buffers: R=[65536->65536] S=[65536->65536]

Mon Aug 24 19:57:37 2020 UDP link local: (not bound)

Mon Aug 24 19:57:37 2020 UDP link remote: [AF_INET]98.128.230.43:1194

Mon Aug 24 19:57:37 2020 MANAGEMENT: >STATE:1598291857,WAIT,,,,,,

Mon Aug 24 19:57:37 2020 MANAGEMENT: >STATE:1598291857,AUTH,,,,,,

Mon Aug 24 19:57:37 2020 TLS: Initial packet from [AF_INET]98.128.230.43:1194, sid=af94d712 a5a4012f

Mon Aug 24 19:57:37 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

Mon Aug 24 19:57:37 2020 VERIFY OK: depth=1, C=SE, L=Stockholm, O=xxxxxAB, OU=-, CN=ca.server.xxxxx.net, emailAddress=security@server.xxxxx.net, ST=-

Mon Aug 24 19:57:37 2020 VERIFY OK: nsCertType=SERVER

Mon Aug 24 19:57:37 2020 VERIFY OK: depth=0, C=SE, ST=-, L=Stockholm, O=xxxxxAB, OU=-, CN=server.xxxxx.net, emailAddress=security@server.xxxxx.net

Mon Aug 24 19:57:37 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Mon Aug 24 19:57:37 2020 [server.xxxxx.net] Peer Connection Initiated with [AF_INET]98.128.230.43:1194

Mon Aug 24 19:57:38 2020 MANAGEMENT: >STATE:1598291858,GET_CONFIG,,,,,,

Mon Aug 24 19:57:38 2020 SENT CONTROL [server.xxxxx.net]: 'PUSH_REQUEST' (status=1)

Mon Aug 24 19:57:38 2020 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.156.1,dhcp-option DOMAIN xxxxx.net,dhcp-option WINS 192.168.156.1,route 192.168.156.0 255.255.255.0,compress stub-v2,route 10.9.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.9.0.6 10.9.0.5,peer-id 1,cipher AES-256-GCM'

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: timers and/or timeouts modified

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: compression parms modified

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: --ifconfig/up options modified

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: route options modified

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: peer-id set

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: adjusting link_mtu to 1625

Mon Aug 24 19:57:38 2020 OPTIONS IMPORT: data channel crypto options modified

Mon Aug 24 19:57:38 2020 Data Channel: using negotiated cipher 'AES-256-GCM'

Mon Aug 24 19:57:38 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Aug 24 19:57:38 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Mon Aug 24 19:57:38 2020 interactive service msg_channel=636

Mon Aug 24 19:57:38 2020 ROUTE_GATEWAY 192.168.7.1/255.255.255.0 I=20 HWADDR=a0:ce:c8:c5:72:95

Mon Aug 24 19:57:38 2020 open_tun

Mon Aug 24 19:57:38 2020 TAP-WIN32 device [Anslutning till lokalt nätverk] opened: \\.\Global\{942055F2-645F-4991-9ECF-CCD204E4549F}.tap

Mon Aug 24 19:57:38 2020 TAP-Windows Driver Version 9.24 

Mon Aug 24 19:57:38 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.9.0.6/255.255.255.252 on interface {942055F2-645F-4991-9ECF-CCD204E4549F} [DHCP-serv: 10.9.0.5, lease-time: 31536000]

Mon Aug 24 19:57:38 2020 Successful ARP Flush on interface [14] {942055F2-645F-4991-9ECF-CCD204E4549F}

Mon Aug 24 19:57:38 2020 MANAGEMENT: >STATE:1598291858,ASSIGN_IP,,10.9.0.6,,,,

Mon Aug 24 19:57:43 2020 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up

Mon Aug 24 19:57:43 2020 MANAGEMENT: >STATE:1598291863,ADD_ROUTES,,,,,,

Mon Aug 24 19:57:43 2020 C:\WINDOWS\system32\route.exe ADD 192.168.156.0 MASK 255.255.255.0 10.9.0.5

Mon Aug 24 19:57:43 2020 Route addition via service succeeded

Mon Aug 24 19:57:43 2020 C:\WINDOWS\system32\route.exe ADD 10.9.0.0 MASK 255.255.255.0 10.9.0.5

Mon Aug 24 19:57:43 2020 Route addition via service succeeded

Mon Aug 24 19:57:43 2020 Initialization Sequence Completed

Mon Aug 24 19:57:43 2020 MANAGEMENT: >STATE:1598291863,CONNECTED,SUCCESS,10.9.0.6,98.128.230.43,1194,,





Server log

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 TLS: Initial packet from [AF_INET]5.172.151.99:51095 (via [AF_INET]98.128.230.43%enp0s31f6), sid=81e7048b b5167c9c

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 VERIFY OK: depth=1, C=SE, L=Stockholm, O=xxxxxAB, OU=-, CN=ca.server.xxxxx.net, emailAddress=security@server.xxxxx.net, ST=-

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 VERIFY OK: depth=0, C=SE, ST=-, L=Stockholm, O=xxxxxAB, OU=-, CN=svju, emailAddress=svju@xxxxx.net

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_VER=2.4.9

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_PLAT=win

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_PROTO=2

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_NCP=2

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_LZ4=1

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_LZ4v2=1

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_LZO=1

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_COMP_STUB=1

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_COMP_STUBv2=1

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_TCPNL=1

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 peer info: IV_GUI_VER=OpenVPN_GUI_11

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 PLUGIN_CALL: POST /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 TLS: Username/Password authentication succeeded for username 'svju'

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 5.172.151.99:51095 [svju] Peer Connection Initiated with [AF_INET]5.172.151.99:51095 (via [AF_INET]98.128.230.43%enp0s31f6)

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 MULTI: new connection by client 'svju' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 MULTI_sva: pool returned IPv4=10.9.0.6, IPv6=(Not enabled)

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 MULTI: Learn: 10.9.0.6 -> svju/5.172.151.99:51095

Aug 24 20:14:27 server openvpn: Mon Aug 24 20:14:27 2020 MULTI: primary virtual IP for svju/5.172.151.99:51095: 10.9.0.6

Aug 24 20:14:28 server openvpn: Mon Aug 24 20:14:28 2020 svju/5.172.151.99:51095 PUSH: Received control message: 'PUSH_REQUEST'

Aug 24 20:14:28 server openvpn: Mon Aug 24 20:14:28 2020 svju/5.172.151.99:51095 SENT CONTROL [svju]: 'PUSH_REPLY,dhcp-option DNS 192.168.156.1,dhcp-option DOMAIN xxxxx.net,dhcp-option WINS 192.168.156.1,route 192.168.156.0 255.255.255.0,compress stub-v2,route 10.9.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.9.0.6 10.9.0.5,peer-id 1,cipher AES-256-GCM' (status=1)

Aug 24 20:14:28 server openvpn: Mon Aug 24 20:14:28 2020 svju/5.172.151.99:51095 Data Channel: using negotiated cipher 'AES-256-GCM'

Aug 24 20:14:28 server openvpn: Mon Aug 24 20:14:28 2020 svju/5.172.151.99:51095 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

Aug 24 20:14:28 server openvpn: Mon Aug 24 20:14:28 2020 svju/5.172.151.99:51095 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

The reply is currently minimized Show

Accepted Answer
Nick Howitt

Offline
Monday, August 24 2020, 04:39 PM - #Permalink
Resolved

0 votes

MultiWAN errors can be caused by syswatch not running. Check that is it running and enabled:
systemctl status syswatch systemctl is-enabled syswatch

Is the LAN device a Windows machine? If it is, try enabling "Enable NAT (Gateway mode only)" in OpenVPN.

Can you post the connection logs from the client and ClearOS. In ClearOS they are part of the messages log.
The reply is currently minimized Show

Your Reply

Please login to post a reply

You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.

Community Forums

ClearOS Portal

ClearVM Platform

ClearVM 2 Platform

Forums