OpenVPN

millpond · 2017-04-22 19:29:26

Here is the issue:
I have Devuan on 2 systems here.

On the 32 bit system, it was 'upgraded' onto Jesse that was upgraded from Wheezy all the way to original Debian Mint.
OpenVPN loads and works fine here. Using it now.

The 64 bit system is a CLEAN install. Bare metal.
OVPN does not work.

It will connect and reconfigure the routing tables. No errors. Except perhaps something about IPV6=0, but IPV6 *should* be totally disabled on that system. I have IPV4_forwarding=1, but supposedly in etc/systemd/network there should be an ipv4_forwarding=yes - BUT there is of course no etc/systemd/network file here.

Even a simple ping will not get through.

Dunno if this is relevant or no, but originally the cable modem was set at 10.0.0.1 and OVPN uses 10.x.x.x addresses. Reset the modem to 172.x.x.x. - but still problem persists.

And killing OVPN immediately restores network connectivity.

DNSMASQ daemon is installed - no difference in whether working or disabled.

ralph.ronnquist · 2017-04-23 02:08:17

Ok. Details, please. When you've started openvpn (not working), include the following:
the routing table

# ip route list all

iptables rules

# iptables-save

DNS configuration

# cat /etc/resolv.conf

the result of

# cat /proc/sys/net/ipv4/ip_forward

and interfaces

# ifconfig -a

.

One or some of those should probably tell what the problem might be.

millpond · 2017-04-23 08:46:11

Yikes: Just lost my lengthy reply, and getting late!
Will give a full reply tomorrow, the basics... :

root@devuan:/new# iptables-save
# Generated by iptables-save v1.4.21 on Sun Apr 23 04:26:35 2017
*filter
:INPUT ACCEPT [18008:10309478]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [17011:1651376]
COMMIT

root@devuan:/new# ip route list all
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.101

root@devuan:/new# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:27:0e:0a:98:b1
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::227:eff:fe0a:98b1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14348 errors:0 dropped:0 overruns:0 frame:0
TX packets:12522 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10246751 (9.7 MiB) TX bytes:1637414 (1.5 MiB)
Interrupt:20 Memory:e0200000-e0220000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:4236 errors:0 dropped:0 overruns:0 frame:0
TX packets:4236 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:352569 (344.3 KiB) TX bytes:352569 (344.3 KiB)

root@devuan:/new# cat /proc/sys/net/ipv4/ip_forward
1

root@devuan:/new# cat /etc/resolv.conf
nameserver 127.0.0.1
domain hsdx.dx.comcast.net
search hsdx.dx.comcast.net
nameserver 75.75.75.75
nameserver 75.75.76.76

ralph.ronnquist · 2017-04-23 09:58:07

Maybe I misunderstood the set up, because there's no trace of using openvpn there? And there's also nothing stopping network traffic, but rather a quite normal, working set up.
Did you really start openvpn before capturing all that?

millpond · 2017-04-24 08:35:19

Apologies, was late and forgot that it would not post wit the VPN connection.
So pasted to kate, this is the networking *with* OVPN:

root@devuan:/etc/apt# iptables-save
# Generated by iptables-save v1.4.21 on Mon Apr 24 04:18:22 2017
*filter
:INPUT ACCEPT [363744:515591608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [210128:12894234]
COMMIT

root@devuan:/etc/apt# ip route list all
0.0.0.0/1 via 10.3.0.1 dev tun0
default via 192.168.1.1 dev eth0
10.3.0.0/16 dev tun0 proto kernel scope link src 10.3.0.42
128.0.0.0/1 via 10.3.0.1 dev tun0
185.96.32.74 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.101

ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:27:0e:0a:98:b1
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::227:eff:fe0a:98b1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:374688 errors:0 dropped:0 overruns:0 frame:0
TX packets:201572 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:522608050 (498.3 MiB) TX bytes:15971600 (15.2 MiB)
Interrupt:20 Memory:e0200000-e0220000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:9082 errors:0 dropped:0 overruns:0 frame:0
TX packets:9082 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:745949 (728.4 KiB) TX bytes:745949 (728.4 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.3.0.42 P-t-P:10.3.0.42 Mask:255.255.0.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:486 errors:0 dropped:0 overruns:0 frame:0
TX packets:974 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:36576 (35.7 KiB) TX bytes:73276 (71.5 KiB)

cat /proc/sys/net/ipv4/ip_forward = 1 (same)

cat /etc/resolv.conf
nameserver 127.0.0.1
domain hsdx.dx.comcast.net
search hsdx.dx.comcast.net
nameserver 75.75.75.75
nameserver 75.75.76.76
(same)

It should be noted that the connection appears complete:
Mon Apr 24 04:16:32 2017 Socket flags: TCP_NODELAY=1 succeeded
Mon Apr 24 04:16:32 2017 OPTIONS IMPORT: --ifconfig/up options modified
Mon Apr 24 04:16:32 2017 OPTIONS IMPORT: route options modified
Mon Apr 24 04:16:32 2017 OPTIONS IMPORT: route-related options modified
Mon Apr 24 04:16:32 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Apr 24 04:16:32 2017 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Apr 24 04:16:32 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 24 04:16:32 2017 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Apr 24 04:16:32 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Apr 24 04:16:32 2017 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=00:27:0e:0a:98:b1
Mon Apr 24 04:16:32 2017 TUN/TAP device tun0 opened
Mon Apr 24 04:16:32 2017 TUN/TAP TX queue length set to 100
Mon Apr 24 04:16:32 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Apr 24 04:16:32 2017 /sbin/ip link set dev tun0 up mtu 1500
Mon Apr 24 04:16:32 2017 /sbin/ip addr add dev tun0 10.3.0.42/16 broadcast 10.3.255.255
Mon Apr 24 04:16:32 2017 /sbin/ip route add 185.96.32.74/32 via 192.168.1.1
Mon Apr 24 04:16:32 2017 /sbin/ip route add 0.0.0.0/1 via 10.3.0.1
Mon Apr 24 04:16:32 2017 /sbin/ip route add 128.0.0.0/1 via 10.3.0.1
Mon Apr 24 04:16:32 2017 Initialization Sequence Completed

Hope this helps better to figure out this mystery!

ralph.ronnquist · 2017-04-24 11:11:36

Ah. the tun interface is not configured correctly. Its P-t-P address should be 10.3.0.1.

The problem is to determine why. And how come it works on the 32bit host (does it get configured correctly)?

millpond · 2017-04-25 17:20:50

Not on the machine now.

Would something like this help:
https://serverfault.com/questions/64232 … xxx-xxx-11

The server is not running (I dont use it as a server).

It came along with the Jessie/Devuan install (beta).
Is there a way to recompile it without any systemd garbage?

Perhaps if i pull the old binary from a Wheezy archive?

ralph.ronnquist · 2017-04-26 01:56:09

I'm not sure how the tun0 interface is created, but the problem here is that its "remote address" is not configured correctly. The interface correctly should have 10.3.0.42 as its own address, but it should have 10.3.0.1 as its PtP address. To do this manually I think you'd do

ip link set tun0 peer 10.3.0.1

But I would have thought that openvpn would do so itself via its configuration. I'm not using openvpn myself so I don't know exactly, but its configuration should declare that 10.3.0.1 is "its" IP address, whereas 10.3.0.42 is the client's IP address (or one of them, depending on how it assigns those).

millpond · 2017-04-26 06:06:01

root@devuan:~# ip link set tun0 peer 10.3.0.1
Error: either "dev" is duplicate, or "peer" is a garbage.
root@devuan:~#

Wed Apr 26 01:32:22 2017 /sbin/ip addr add dev tun0 10.3.0.84/16 broadcast 10.3.255.255

But it changed to 84.

My knowledge of networking at this level is rudimentary, but isnt this some kind of broadcasting address - with the mask at the end.

OVPN docs are hard to decipher, and their forum is outright hostile to non-programmers.

Trying :
root@devuan:/new# ip addr del 10.3.0.84/24 dev tun0
RTNETLINK answers: Cannot assign requested address

Onnce again, the readout:

root@devuan:/etc/openvpn/config# ./vegt
Wed Apr 26 01:32:19 2017 WARNING: file 'auth.txt' is group or others accessible
Wed Apr 26 01:32:19 2017 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jan 14 2017
Wed Apr 26 01:32:19 2017 library versions: OpenSSL 1.0.2k 26 Jan 2017, LZO 2.08
Wed Apr 26 01:32:19 2017 NOTE: --fast-io is disabled since we are not using UDP
Wed Apr 26 01:32:19 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 26 01:32:19 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 26 01:32:19 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]186.96.30.66:443
Wed Apr 26 01:32:19 2017 Socket Buffers: R=[87380->87380] S=[16384->16384]
Wed Apr 26 01:32:19 2017 Attempting to establish TCP connection with [AF_INET]186.96.30.66:443 [nonblock]
Wed Apr 26 01:32:20 2017 TCP connection established with [AF_INET]186.96.30.66:443
Wed Apr 26 01:32:20 2017 TCP_CLIENT link local: (not bound)
Wed Apr 26 01:32:20 2017 TCP_CLIENT link remote: [AF_INET]186.96.30.66:443
Wed Apr 26 01:32:20 2017 TLS: Initial packet from [AF_INET]186.96.30.66:443, sid=482606ff b1436f06
Wed Apr 26 01:32:20 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Apr 26 01:32:21 2017 VERIFY OK: depth=1, C=US, ST=DE, L=Wilmington, O=VpnHT, OU=VPNHT, CN=vpn.ht, name=VPNHT, emailAddress=support@vpn.ht
Wed Apr 26 01:32:21 2017 VERIFY OK: nsCertType=SERVER
Wed Apr 26 01:32:21 2017 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOrganizationalUnit, CN=server, name=EasyRSA, emailAddress=me@myhost.mydomain
Wed Apr 26 01:32:21 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Wed Apr 26 01:32:21 2017 [server] Peer Connection Initiated with [AF_INET]185.94.30.66:443
Wed Apr 26 01:32:22 2017 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Apr 26 01:32:22 2017 PUSH: Received control message: 'PUSH_REPLY,topology subnet,route-gateway 10.3.0.1,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.3.0.1,route-gateway 10.3.0.1,topology subnet,socket-flags TCP_NODELAY,ifconfig 10.3.0.84 255.255.0.0'
Wed Apr 26 01:32:22 2017 OPTIONS IMPORT: --socket-flags option modified
Wed Apr 26 01:32:22 2017 Socket flags: TCP_NODELAY=1 succeeded
Wed Apr 26 01:32:22 2017 OPTIONS IMPORT: --ifconfig/up options modified
Wed Apr 26 01:32:22 2017 OPTIONS IMPORT: route options modified
Wed Apr 26 01:32:22 2017 OPTIONS IMPORT: route-related options modified
Wed Apr 26 01:32:22 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Apr 26 01:32:22 2017 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Apr 26 01:32:22 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 26 01:32:22 2017 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Apr 26 01:32:22 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Apr 26 01:32:22 2017 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=00:27:0e:0a:98:b1
Wed Apr 26 01:32:22 2017 TUN/TAP device tun0 opened
Wed Apr 26 01:32:22 2017 TUN/TAP TX queue length set to 100
Wed Apr 26 01:32:22 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Wed Apr 26 01:32:22 2017 /sbin/ip link set dev tun0 up mtu 1500
Wed Apr 26 01:32:22 2017 /sbin/ip addr add dev tun0 10.3.0.84/16 broadcast 10.3.255.255
Wed Apr 26 01:32:22 2017 /sbin/ip route add 186.96.30.66/32 via 192.168.1.1
Wed Apr 26 01:32:22 2017 /sbin/ip route add 0.0.0.0/1 via 10.3.0.1
Wed Apr 26 01:32:22 2017 /sbin/ip route add 128.0.0.0/1 via 10.3.0.1
Wed Apr 26 01:32:22 2017 Initialization Sequence Completed

shutdown:
Wed Apr 26 01:41:53 2017 event_wait : Interrupted system call (code=4)
Wed Apr 26 01:41:53 2017 /sbin/ip route del 186.96.30.66/32
Wed Apr 26 01:41:53 2017 /sbin/ip route del 0.0.0.0/1
Wed Apr 26 01:41:53 2017 /sbin/ip route del 128.0.0.0/1
Wed Apr 26 01:41:53 2017 Closing TUN/TAP interface
Wed Apr 26 01:41:53 2017 /sbin/ip addr del dev tun0 10.3.0.84/16
Wed Apr 26 01:41:53 2017 SIGTERM[hard,] received, process exiting

Shutdown works flawlessly. connections return immediately.

Note that this is not a problem with the 32 bit system, but that Devuan was an *upgrade*, not bare install.

There WAS a networking issue on this machine when Comcast decided to 'upgrade' their modem, and deprecate my Netgear router. Switched to a Linksys that worked, but both were on 10.x.x.x IP's and creating havoc. Weird because the Linksys is a 192.168.x.x address for login.

Switched the comcast router to 72.x.x.x and normal networking returned. But that setup *might* have shagged something in the install setup for Devuan, which was prior to the change.

In the Win boot it had a residual address in the routing table i easily deleted. with route del x.x.x.x

But in Linux the normal routing table seems unaffected.

It should also be noted that I am using this with a VPN provider, and not a local network. As noted, no daemon running.

Last edited by millpond (2017-04-26 06:12:07)

ralph.ronnquist · 2017-04-26 07:48:31

Sorry. I think I don't understand the "ip" man page; and maybe it is that the peer address must be given at the same time as configuring it's own address.

Anyhow, maybe use "ipconfig" instead:

# ifconfig tun0 dstaddr 10.3.0.1

That should accomplish the same thing.

malinas · 2017-04-27 03:44:08

Hi there,

Can you please do two things:

Use BBCode to format your posts (it will make for an easier read to other people)
Put the contents of your server and client openvpn config files

catprints · 2017-04-27 13:01:10

If learning to use BBCode is a prerequisite to using this forum I am in the wrong place. This is not a criticism but a simple fact.

golinux · 2017-04-27 14:09:22

iamwhatiam wrote:

If learning to use BBCode is a prerequisite to using this forum I am in the wrong place. This is not a criticism but a simple fact.

The only tags you are likely to need are code, b and maybe a quote here and there. Is that such a stretch? That being said, we'll look into adding a simple formatting mod.

FOSSuser · 2017-04-29 09:45:28

It's not rocket science.

Just start with a [ then write the word code, then put a ] write your actual code, then close the tag with a [ followed by a / then the word code followed by another ] that's all that's needed.

 some code

catprints · 2017-04-29 13:12:26

Got it. Not a stretch and not rocket science.np

golinux · 2017-04-29 15:04:03

FYI, I have put a link to a list of the BBCode tags available in FluxBB in an announcement at the top of the forum.

greenjeans · 2017-04-29 19:47:45

golinux wrote:

That being said, we'll look into adding a simple formatting mod.

Best policy IMO.

It's not offered as an option in this BB template? Small toolbar for the bottom that offers to tag img, url, code, quote etc.?

golinux · 2017-04-29 20:08:17

greenjeans wrote:

golinux wrote:
That being said, we'll look into adding a simple formatting mod.
Best policy IMO.
It's not offered as an option in this BB template? Small toolbar for the bottom that offers to tag img, url, code, quote etc.?

No. Only third party mods. I couldn't find one compatible with our version. rrq is looking into it. Heck, he could probably write it himself! Some of the recent posts are unreadable so we need to do something . . .

The officially official Devuan Forum!

#1 2017-04-22 19:29:26

OpenVPN

#2 2017-04-23 02:08:17

Re: OpenVPN

#3 2017-04-23 08:46:11

Re: OpenVPN

#4 2017-04-23 09:58:07

Re: OpenVPN

#5 2017-04-24 08:35:19

Re: OpenVPN

#6 2017-04-24 11:11:36

Re: OpenVPN

#7 2017-04-25 17:20:50

Re: OpenVPN

#8 2017-04-26 01:56:09

Re: OpenVPN

#9 2017-04-26 06:06:01

Re: OpenVPN

#10 2017-04-26 07:48:31

Re: OpenVPN

#11 2017-04-27 03:44:08

Re: OpenVPN

#12 2017-04-27 13:01:10

Re: OpenVPN

#13 2017-04-27 14:09:22

Re: OpenVPN

#14 2017-04-29 09:45:28

Re: OpenVPN

#15 2017-04-29 13:12:26

Re: OpenVPN

#16 2017-04-29 15:04:03

Re: OpenVPN

#17 2017-04-29 19:47:45

Re: OpenVPN

#18 2017-04-29 20:08:17

Re: OpenVPN

Board footer