Sorry, I'll be clearer. The entire LAN is connected to another network, but the devices on the LAN still are behind the router, and still get the same protection (firewall, NAT) as they have when the VPN is not being used.virtualmike wrote:If the VPN runs on the router, then all devices are still on the LAN, and the entire LAN is virtually on another network. The devices on the LAN can talk to each other.
OpenVPN Open Beta
Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
235 posts
Page 15 of 24
pmbell wrote: I'm seeing SSH and SQL portscans inbound over the Sonic VPN, scans that I don't recall seeing coming across my VPN provider's design, which NATs customers into pools. If I were running openVPN as a software client stack on a single box, those scans would be reaching that box; as it is, the only service potentially at risk is ssh.
I can't believe how long I stared at these statements trying to make sense of them. Let's see if I understood you guys correctly.virtualmike wrote:Sorry, I'll be clearer. The entire LAN is connected to another network, but the devices on the LAN still are behind the router, and still get the same protection (firewall, NAT) as they have when the VPN is not being used.virtualmike wrote:If the VPN runs on the router, then all devices are still on the LAN, and the entire LAN is virtually on another network. The devices on the LAN can talk to each other.
Going back to what pmbell said about his VPN provider NATing customers into pools, it sounds like Sonic's VPN doesn't use NAT protection at all, leaving its users completely at the mercy of the whole Internet. If this is true, you better have a software firewall on any device connecting to Sonic's VPN, or you could be hacked just by connecting to it. If you're using a mobile device to connect, it is highly unlikely to have a firewall. If you're running some Linux distribution, you'll have to know how to use iptables. If you're running Windows, you would want a personal firewall.
That article I linked to earlier about traffic going right through NAT was bothering me. At some point, I realized that if OpenVPN is running on the router itself, then the endpoint IS the router rather than a computer connected to it. So if my understanding is correct, malicious traffic going into the tunnel must be inspected by the router before being allowed to proceed, because the router is where the tunnel ends.
If Sonic's not going to implement NAT, the question then becomes how to configure a router to properly firewall malicious traffic. I then went back to what pmbell said earlier which went completely over my head at first:
I've made some progress on this. Do these rules look correct for the OpenVPN interface?:pmbell wrote:treat the openvpn interface as an untrusted interface and firewall it at your router - it is effectively one of your public IP addresses. bind the tunnel to an address and interface that is not on your inside lan.
a big advantage to openvpn over ipsec in device to device mode is the ease of applying firewall rules to the interface.
Input: reject, Output: accept, Forward: reject
I still don't understand the part about device to device mode. Is this something on Sonic's end or mine? And if the endpoint is my router and my router still has NAT protection against traffic coming in from the OpenVPN interface, how does the interface know which specific local IP address to send authorized incoming traffic to?
pmbell and virtualmike, I really need your help here! I had to do 4 hours of reading on background material just to begin to understand what you are saying. Am I on the right track?
Yes, you're on the right track.
Start with the simple case. You have a router that's connected to an ISP. Each time a device on your LAN accesses a remote computer, the router sees the request. It makes note of the request, so that when the response(s) arrives, the router then forwards the response(s) to the device.
The second case is a single computer on the LAN that is on a VPN (e.g, it is running VPN software and is active with a VPN host), its traffic still passes through the router. Each outgoing packet is forwarded to the VPN server. Responses come from the VPN server, and the router forwards them to the device that made the request (the device with the active VPN session). The key point is that the traffic between the device running the VPN software and the VPN server is encrypted. As a matter of fact, the router does not know that, nor does it care. It's simply routing traffic per its design.
That device with the VPN talks *only* to the VPN server, which redirects the traffic to the requested sites. However, the VPN server does not about the other devices on the LAN. Therefore, the device running the VPN software is unable to connect to the other devices on the LAN.
In the third scenario, the VPN software runs on the router. In that case, the devices on the LAN can connect to each other. When any one of them wants to connect to a service on the greater Internet, it sends the request to the router, which makes note of the request and the device that made it, encrypts the data, and sends it to the VPN server. The VPN server then forwards it to the requested server. That server then sends the response back to the VPN server, which recognizes that it needs to go back to the router from which the original request was sent. That router then decrypts the response packet and forwards it to the device that made the original request.
Referring back to the second case, *some* implementations of VPN software have advanced configuration settings that will allow specific traffic to bypass the VPN and access other devices on the LAN. Whether this can be done depends on the VPN software, the local site administrators, and other factors. It's also not foolproof, as it's basically a leak in the VPN, which can be exploited. Odds aren't high, but it can happen.
Is that clearer?
Start with the simple case. You have a router that's connected to an ISP. Each time a device on your LAN accesses a remote computer, the router sees the request. It makes note of the request, so that when the response(s) arrives, the router then forwards the response(s) to the device.
The second case is a single computer on the LAN that is on a VPN (e.g, it is running VPN software and is active with a VPN host), its traffic still passes through the router. Each outgoing packet is forwarded to the VPN server. Responses come from the VPN server, and the router forwards them to the device that made the request (the device with the active VPN session). The key point is that the traffic between the device running the VPN software and the VPN server is encrypted. As a matter of fact, the router does not know that, nor does it care. It's simply routing traffic per its design.
That device with the VPN talks *only* to the VPN server, which redirects the traffic to the requested sites. However, the VPN server does not about the other devices on the LAN. Therefore, the device running the VPN software is unable to connect to the other devices on the LAN.
In the third scenario, the VPN software runs on the router. In that case, the devices on the LAN can connect to each other. When any one of them wants to connect to a service on the greater Internet, it sends the request to the router, which makes note of the request and the device that made it, encrypts the data, and sends it to the VPN server. The VPN server then forwards it to the requested server. That server then sends the response back to the VPN server, which recognizes that it needs to go back to the router from which the original request was sent. That router then decrypts the response packet and forwards it to the device that made the original request.
Referring back to the second case, *some* implementations of VPN software have advanced configuration settings that will allow specific traffic to bypass the VPN and access other devices on the LAN. Whether this can be done depends on the VPN software, the local site administrators, and other factors. It's also not foolproof, as it's basically a leak in the VPN, which can be exploited. Odds aren't high, but it can happen.
Is that clearer?
And as far as firewalling goes, in each of the cases virtualmike outlines above, one question is "what happens to unsolicited traffic over the vpn connection?" I just portscanned a cisco client signed in over ipsec, and found multiple open ports *over the vpn tunnel.* So, although the Cisco client includes a firewall, the firewall does not apply itself to the ipsec tunnel.
On a home router/firewall (case 1) the firewall may or may not do anything active with unsolicited traffic, but as a general rule, the NAT translation makes it difficult to get unsolicited traffic from the internet to a particular host inside the firewall.
In the case of either an openVPN or a Cisco client connected to the internet and getting an internet ip address assigned (case 2), I wouldn't expect that the connection to the internet would be firewalled by default but it may well be that Sonic is firewalling those Cisco assigned addresses. I have a system here with the Cisco client configured to connect to Sonic, and I need to look more carefully at that - or someone else can.
In the case of a router configured to connect to an openVPN server (case 3), you can and should configure the router to treat the openvpn interface as an untrusted interface and configure firewall rules to reject any unsolicited traffic sent to or across it. It is easier to do that in openVPN than in the equivalent IPSEC router to server setup. (Or perhaps I should say just that it's more obvious rather than easier.)
On a home router/firewall (case 1) the firewall may or may not do anything active with unsolicited traffic, but as a general rule, the NAT translation makes it difficult to get unsolicited traffic from the internet to a particular host inside the firewall.
In the case of either an openVPN or a Cisco client connected to the internet and getting an internet ip address assigned (case 2), I wouldn't expect that the connection to the internet would be firewalled by default but it may well be that Sonic is firewalling those Cisco assigned addresses. I have a system here with the Cisco client configured to connect to Sonic, and I need to look more carefully at that - or someone else can.
In the case of a router configured to connect to an openVPN server (case 3), you can and should configure the router to treat the openvpn interface as an untrusted interface and configure firewall rules to reject any unsolicited traffic sent to or across it. It is easier to do that in openVPN than in the equivalent IPSEC router to server setup. (Or perhaps I should say just that it's more obvious rather than easier.)
I'm an Ubuntu 14.04 LTS user.
Following the instructions in the original post in this thread, I get
Mon Oct 5 14:01:20 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Enter Auth Username(...)
Enter Auth Password(..)
Then a bunch of stuff (including some VERIFY OK messages)... and finally, sadly,
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:18: register-dns (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:19: block-ipv6 (2.3.2)
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: explicit notify parm(s) modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: LZO parms modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: route options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: route-related options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Oct 5 14:02:04 2015 ROUTE_GATEWAY (...) IFACE=eth0 HWADDR=(...)
Mon Oct 5 14:02:04 2015 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
Mon Oct 5 14:02:04 2015 Exiting due to fatal error
Tried again a couple times with similar results. Kinda sad as I was looking forward to this particular version of it.
That was all from terminal.
I went to System Settings in my Ubuntu OS and went to create a new VPN, figuring there might be a simpler way, but rather than do it in Cisco format suggested at https://web.archive.org/web/20110626124 ... y-opensuse (which is linked to in Sonic's VPN wiki at https://wiki.sonic.net/wiki/VPN_Service) I decided to go with OpenVPN as the option to start with, being as that is a menu option. But it could not be saved, as the system settings now didn't want to save new options (following the installation of client.ovpn file)...
Well, this is frustrating.
Following the instructions in the original post in this thread, I get
Mon Oct 5 14:01:20 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Enter Auth Username(...)
Enter Auth Password(..)
Then a bunch of stuff (including some VERIFY OK messages)... and finally, sadly,
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:18: register-dns (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:19: block-ipv6 (2.3.2)
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: explicit notify parm(s) modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: LZO parms modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: route options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: route-related options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Oct 5 14:02:04 2015 ROUTE_GATEWAY (...) IFACE=eth0 HWADDR=(...)
Mon Oct 5 14:02:04 2015 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
Mon Oct 5 14:02:04 2015 Exiting due to fatal error
Tried again a couple times with similar results. Kinda sad as I was looking forward to this particular version of it.
That was all from terminal.
I went to System Settings in my Ubuntu OS and went to create a new VPN, figuring there might be a simpler way, but rather than do it in Cisco format suggested at https://web.archive.org/web/20110626124 ... y-opensuse (which is linked to in Sonic's VPN wiki at https://wiki.sonic.net/wiki/VPN_Service) I decided to go with OpenVPN as the option to start with, being as that is a menu option. But it could not be saved, as the system settings now didn't want to save new options (following the installation of client.ovpn file)...
Well, this is frustrating.
Its complaining that it can't create the tun device, due to lack of permissions. That suggests that you're not running as root (or equivalent). What command(s) are you running, and against which user?pcvcolin wrote:I'm an Ubuntu 14.04 LTS user.
Following the instructions in the original post in this thread, I get
Mon Oct 5 14:01:20 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Enter Auth Username(...)
Enter Auth Password(..)
Then a bunch of stuff (including some VERIFY OK messages)... and finally, sadly,
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:18: register-dns (2.3.2)
Mon Oct 5 14:02:04 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:19: block-ipv6 (2.3.2)
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: explicit notify parm(s) modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: LZO parms modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: route options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: route-related options modified
Mon Oct 5 14:02:04 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Oct 5 14:02:04 2015 ROUTE_GATEWAY (...) IFACE=eth0 HWADDR=(...)
Mon Oct 5 14:02:04 2015 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
Mon Oct 5 14:02:04 2015 Exiting due to fatal error
Tried again a couple times with similar results. Kinda sad as I was looking forward to this particular version of it.
That was all from terminal.
netllama ~ Well the commands I ran to get to that point were basically this in terminal:
openvpn --config /home/myusername/Downloads/client.ovpn
then it prompted me Enter Auth Username which is sonic username
and Enter Auth Password which is sonic password, I guess, since it all seemed ok
I am guessing you are saying I didn't have proper permissions and should have done this as root, thus sudo?
So it should have been, sudo openvpn --config /home/myusername/Downloads/client.ovpn
Trying that (though another layer to this issue is that in Settings, if I go now to create a new VPN and simply try to create it by import it by existing saved configuration menu option (and use the client.ovpn file as the option) it won't allow me to save it, the save button is greyed out... very strange
so anyway, back to terminal, I am now trying what you suggested regarding root... I think it made more progress, but am not sure how much.
Here's the output:
Mon Oct 5 15:18:26 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Enter Auth Username:(...)
Enter Auth Password:
Mon Oct 5 15:18:40 2015 Control Channel Authentication: tls-auth using INLINE static key file
Mon Oct 5 15:18:40 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:40 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:40 2015 Socket Buffers: R=[212992->200000] S=[212992->200000]
Mon Oct 5 15:18:40 2015 UDPv4 link local: [undef]
Mon Oct 5 15:18:40 2015 UDPv4 link remote: [AF_INET]184.23.168.54:1194
Mon Oct 5 15:18:40 2015 TLS: Initial packet from [AF_INET]184.23.168.54:1194, sid=(...)
Mon Oct 5 15:18:40 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Oct 5 15:18:40 2015 VERIFY OK: depth=1, CN=OpenVPN CA
Mon Oct 5 15:18:40 2015 VERIFY OK: nsCertType=SERVER
Mon Oct 5 15:18:40 2015 VERIFY OK: depth=0, CN=OpenVPN Server
Mon Oct 5 15:18:41 2015 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Oct 5 15:18:41 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:41 2015 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Oct 5 15:18:41 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:41 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Mon Oct 5 15:18:41 2015 [OpenVPN Server] Peer Connection Initiated with [AF_INET]184.23.168.54:1194
Mon Oct 5 15:18:43 2015 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
Mon Oct 5 15:18:43 2015 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,auth-token SESS_ID,comp-lzo yes,redirect-gateway def1,redirect-gateway bypass-dhcp,redirect-gateway autolocal,route-gateway 69.12.223.193,dhcp-option DNS 208.201.224.33,dhcp-option DNS 208.201.224.11,register-dns,block-ipv6,ifconfig 69.12.223.203 255.255.255.192'
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:18: register-dns (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:19: block-ipv6 (2.3.2)
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: explicit notify parm(s) modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: LZO parms modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: route options modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: route-related options modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Oct 5 15:18:43 2015 ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=wlan0 HWADDR=(....)
Mon Oct 5 15:18:43 2015 TUN/TAP device tun0 opened
Mon Oct 5 15:18:43 2015 TUN/TAP TX queue length set to 100
Mon Oct 5 15:18:43 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Oct 5 15:18:43 2015 /sbin/ip link set dev tun0 up mtu 1500
Mon Oct 5 15:18:44 2015 /sbin/ip addr add dev tun0 69.12.223.203/26 broadcast 69.12.223.255
Mon Oct 5 15:18:49 2015 ROUTE remote_host is NOT LOCAL
Mon Oct 5 15:18:49 2015 /sbin/ip route add 184.23.168.54/32 via 192.168.1.254
Mon Oct 5 15:18:49 2015 /sbin/ip route add 0.0.0.0/1 via 69.12.223.193
Mon Oct 5 15:18:49 2015 /sbin/ip route add 128.0.0.0/1 via 69.12.223.193
Mon Oct 5 15:18:49 2015 Initialization Sequence Completed
And that was it. It doesn't appear in the network list, however. Also under my "VPN Connections" list there are no signs of a possible VPN connection to connect to or an active one running.
openvpn --config /home/myusername/Downloads/client.ovpn
then it prompted me Enter Auth Username which is sonic username
and Enter Auth Password which is sonic password, I guess, since it all seemed ok
I am guessing you are saying I didn't have proper permissions and should have done this as root, thus sudo?
So it should have been, sudo openvpn --config /home/myusername/Downloads/client.ovpn
Trying that (though another layer to this issue is that in Settings, if I go now to create a new VPN and simply try to create it by import it by existing saved configuration menu option (and use the client.ovpn file as the option) it won't allow me to save it, the save button is greyed out... very strange
so anyway, back to terminal, I am now trying what you suggested regarding root... I think it made more progress, but am not sure how much.
Here's the output:
Mon Oct 5 15:18:26 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014
Enter Auth Username:(...)
Enter Auth Password:
Mon Oct 5 15:18:40 2015 Control Channel Authentication: tls-auth using INLINE static key file
Mon Oct 5 15:18:40 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:40 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:40 2015 Socket Buffers: R=[212992->200000] S=[212992->200000]
Mon Oct 5 15:18:40 2015 UDPv4 link local: [undef]
Mon Oct 5 15:18:40 2015 UDPv4 link remote: [AF_INET]184.23.168.54:1194
Mon Oct 5 15:18:40 2015 TLS: Initial packet from [AF_INET]184.23.168.54:1194, sid=(...)
Mon Oct 5 15:18:40 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Oct 5 15:18:40 2015 VERIFY OK: depth=1, CN=OpenVPN CA
Mon Oct 5 15:18:40 2015 VERIFY OK: nsCertType=SERVER
Mon Oct 5 15:18:40 2015 VERIFY OK: depth=0, CN=OpenVPN Server
Mon Oct 5 15:18:41 2015 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Oct 5 15:18:41 2015 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:41 2015 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Oct 5 15:18:41 2015 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 5 15:18:41 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Mon Oct 5 15:18:41 2015 [OpenVPN Server] Peer Connection Initiated with [AF_INET]184.23.168.54:1194
Mon Oct 5 15:18:43 2015 SENT CONTROL [OpenVPN Server]: 'PUSH_REQUEST' (status=1)
Mon Oct 5 15:18:43 2015 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,auth-token SESS_ID,comp-lzo yes,redirect-gateway def1,redirect-gateway bypass-dhcp,redirect-gateway autolocal,route-gateway 69.12.223.193,dhcp-option DNS 208.201.224.33,dhcp-option DNS 208.201.224.11,register-dns,block-ipv6,ifconfig 69.12.223.203 255.255.255.192'
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:18: register-dns (2.3.2)
Mon Oct 5 15:18:43 2015 Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:19: block-ipv6 (2.3.2)
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: explicit notify parm(s) modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: LZO parms modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: route options modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: route-related options modified
Mon Oct 5 15:18:43 2015 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Oct 5 15:18:43 2015 ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=wlan0 HWADDR=(....)
Mon Oct 5 15:18:43 2015 TUN/TAP device tun0 opened
Mon Oct 5 15:18:43 2015 TUN/TAP TX queue length set to 100
Mon Oct 5 15:18:43 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Oct 5 15:18:43 2015 /sbin/ip link set dev tun0 up mtu 1500
Mon Oct 5 15:18:44 2015 /sbin/ip addr add dev tun0 69.12.223.203/26 broadcast 69.12.223.255
Mon Oct 5 15:18:49 2015 ROUTE remote_host is NOT LOCAL
Mon Oct 5 15:18:49 2015 /sbin/ip route add 184.23.168.54/32 via 192.168.1.254
Mon Oct 5 15:18:49 2015 /sbin/ip route add 0.0.0.0/1 via 69.12.223.193
Mon Oct 5 15:18:49 2015 /sbin/ip route add 128.0.0.0/1 via 69.12.223.193
Mon Oct 5 15:18:49 2015 Initialization Sequence Completed
And that was it. It doesn't appear in the network list, however. Also under my "VPN Connections" list there are no signs of a possible VPN connection to connect to or an active one running.
You've got an IP address and routes using it, at least according your logs.
Once you get to that stage in the process, if you visit whatismyip or similar, what IP address does the tool think you have?
Once you get to that stage in the process, if you visit whatismyip or similar, what IP address does the tool think you have?
A VPN session that was set up from the command line might be working just fine but not show up in the NetworkManager GUI. I suggest you open another terminal window and check the output of the ip addr and ip route commands.pcvcolin wrote:And that was it. It doesn't appear in the network list, however. Also under my "VPN Connections" list there are no signs of a possible VPN connection to connect to or an active one running.
@ pmbell, forest,
Oh my land!
Apparenty I was getting spoiled by the GNOME interface, or something...
I need to seriously familiarize myself with the terminal commands for OpenVPN, it would seem. But the GUI style that I was using before was easy and served me just fine, until a couple days ago when inexplicably Sonic's older one, ipsec.vpn.sonic.net and corresponding data as saved per the recommended configuration in https://web.archive.org/web/20110626124 ... y-opensuse stopped working.
Wish there was a way for this VPN to fire up automatically every time I connect wirelessly through my Sonic home connection (click, click). That's how I had it before and it worked. Now I'm lost in the weeds due to that the beta product, beta.vpn.sonic.net, is (at least for Linux users, from what I can tell) something we have to negotiate from the command line, and it seems it's not visible for a number of us in the network connections area.
So, anyway, trying again:
this time,
sudo mv /home/myusername/Downloads/client.ovpn /usr/share/openvpn
(check new file location to be sure, then)
sudo openvpn --config /usr/share/openvpn/client.ovpn
It asks for username and password, and eventually gets to the part where it says, Initialization Sequence Completed, but has some errors, so I am checking my IP as suggested.
The IP address shows I am in Texas.
(As checked through https://www.whatismyip.com/ and https://www.whatismyip.com/my-ip-information/)
I am definitely not in Texas.
So, it would seem this is working, but it as of right now it has to be started from the command line. Ideally I would like it to start automatically when my wireless connection starts. It is good to know it is working, but if anyone has ideas for a way to make it auto-start (and how to monitor and keep it from dropping) in Ubuntu 14.04 LTS, please post. The last thing I saw about monitoring VPNs to keep them from dropping for this circumstance was kind of whack... https://askubuntu.com/questions/328823/vpn-autoconnect May work for this Sonic beta, may not.
Oh my land!
Apparenty I was getting spoiled by the GNOME interface, or something...
I need to seriously familiarize myself with the terminal commands for OpenVPN, it would seem. But the GUI style that I was using before was easy and served me just fine, until a couple days ago when inexplicably Sonic's older one, ipsec.vpn.sonic.net and corresponding data as saved per the recommended configuration in https://web.archive.org/web/20110626124 ... y-opensuse stopped working.
Wish there was a way for this VPN to fire up automatically every time I connect wirelessly through my Sonic home connection (click, click). That's how I had it before and it worked. Now I'm lost in the weeds due to that the beta product, beta.vpn.sonic.net, is (at least for Linux users, from what I can tell) something we have to negotiate from the command line, and it seems it's not visible for a number of us in the network connections area.
So, anyway, trying again:
this time,
sudo mv /home/myusername/Downloads/client.ovpn /usr/share/openvpn
(check new file location to be sure, then)
sudo openvpn --config /usr/share/openvpn/client.ovpn
It asks for username and password, and eventually gets to the part where it says, Initialization Sequence Completed, but has some errors, so I am checking my IP as suggested.
The IP address shows I am in Texas.
(As checked through https://www.whatismyip.com/ and https://www.whatismyip.com/my-ip-information/)
I am definitely not in Texas.
So, it would seem this is working, but it as of right now it has to be started from the command line. Ideally I would like it to start automatically when my wireless connection starts. It is good to know it is working, but if anyone has ideas for a way to make it auto-start (and how to monitor and keep it from dropping) in Ubuntu 14.04 LTS, please post. The last thing I saw about monitoring VPNs to keep them from dropping for this circumstance was kind of whack... https://askubuntu.com/questions/328823/vpn-autoconnect May work for this Sonic beta, may not.
235 posts
Page 15 of 24
