OpenVPN Open Beta

[pmbell]

Finally got it sorted out this morning, after running the windows client and looking at the output in Wireshark to see how the various certs were being used.

This is the process I followed:

Step 0: Delete any prior configuration - openvpn client configurations for the beta, imported keys, certificates, CAs for the beta.

I remember seeing references to always following the order "create the CA, then create the cert" and, welp, ignored it to much wasted time. The creation order seems important here.

1) System. Cert manager. CA. Import CA.

From the .ovpn file downloaded from the web portal at https://beta.vpn.sonic.net, use the uncommented stanza bracketed by

<ca> </ca>

Do not use the private key, that's only for the cert

2) System. Cert Manager. Certificates. Import Cert

Certificate data: paste in stanza bracketd by
<cert> </cert>

Private key data: Paste in stanza bracketed by
<key> </key>

Only after doing 1 and 2, create the VPN:

3) VPN... OpenVPN

These are the settings I used:

peer to peer
udp
tun
pick a phy interface, probably one with an IP address, I used one that had no other tunnels bound

server: beta.vpn.sonic.net
port 1194

Proxy Auth method: None

User Authentication Settings
username: your username at Sonic, without @sonic.net
password: your Sonic account password.

Enable authentication of TLS packets: checked.
Generate key automatically: Unchecked

Paste in the uncommented stanza delimited by
<tls-auth> </tls-auth>

Peer CA - choose the CA you created from scratch in step one
Client cert - choose the cert you created from scratch in step two

If you're on capable hardware, enable the BSD crypto engine

Compression - enable with adaptive.

There is still some ginching in my setup about packet length. That's controlled by one of the
options in the freetext entry box. Options are set as --option-name value and multiple options
are set using a semicolon delimiter.

[mikeditty]

Finally got it sorted out this morning, after running the windows client and looking at the output in Wireshark to see how the various certs were being used.

This is the process I followed:

This worked for me, thanks pmbell!

One thing to note, I did not need to turn on proxy authentication options, just turned on user athentication.

[pmbell]

Right you are! the proxy auth field is apparently ignored. I tested with both fields populated and with only proxy populated but apparently not with only username and password populated *in the test I did after making shiny clean CA and certificate.*

I think the user/pass with no proxy auth data filled in setting was done when I was still getting errors about self-signed certificates because I guilty of poor crypto hygiene. I've cleaned up my post above, both to hide my sloppiness and to make it (hopefully) simpler to follow.

For what it's worth, I tested the win 10 iso download under the following conditions:

- via Sonic VPN
- via VPN with my commercial provider
- over Uverse without VPN.

My impression is that the VPN on the pfsense box can be as fast as a non-vpn connection for downloading. I saw max throughput for that ISO of around 22-25 mbps on the straight download and on the VPN protected download.

As I'm thinking about speeds, I think the FTTN service provides me with enough speed that the internet speed tests stop being all that useful. There's decent evidence that ATT games them where it can. My experience with FTTN with and without VPN and with the 100 meg bidirectional feed at the office suggests that the internet, as of today, has a hard time saturating even a 10 meg pipe over a long time.

That is, I think that a lot of the variation I see in download performance is due to bottlenecks outside of my network. That's a dramatic difference from what I saw with DSL.

[pmbell]

Question on the VPN beta: Is there a proposal in the design for firewalling traffic headed toward the VPN clients, as there is a firewall available upstream for Sonic DSL customers? Also, is the design intended to give each user a unique address, as a rule, or will there be a group who are assigned a static at some nominal cost and a second group who are either cycling through addresses in a pool, or who are sharing addresses in a NAT design?

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.

But it does make me curious - most of the discussions of openVPN security are focused on getting the crypto right and preventing MITM attacks on the tunnel. I don't know how much or how little firewalling of traffic from the internet toward clients an openVPN access server has the potential to do. I don't know if there is firewalling available in the OpenVPN client stack the way there is in the Cisco VPN client stack. I don't know whether customers would see a benefit from the option of giving openVPN traffic some option of being firewalled.

[Guest]

Could you guys raise the key size to 256?

[carlsonm]

Has anyone been able to get the sonicvpn working on Tomato firmware? Maybe someone post the settings?

I found some good articles from expressvpn and tomato. I have TLS keys and everything typed in. Start WAN connection, and redirect internet are both checked. Status says connected.

Yet no traffic seems to be routing through it. How i make my tomato router force all internet traffic through the vpn?

Thanks

[pmbell]

are you getting an ip address bound to the interface once it comes up? are you adding a nat statement for the interface, and is the interface in your routing table once it come up?

I don't know how much firewalling tomato applies by default, but you may also need an outbound rule.

[kgc]

Could you guys raise the key size to 256?

Are you asking that we change the cipher used from AES-128-CBC to AES-256-CBC? We believe that AES-128-CBC provides a reasonable balance of security and performance, especially when lower-end systems are taking into account.

[pmbell]

Could you guys raise the key size to 256?

Are you asking that we change the cipher used from AES-128-CBC to AES-256-CBC? We believe that AES-128-CBC provides a reasonable balance of security in performance, especially when lower-end systems are taking into account.

there are some limited and rather academic scenarios in which aes-256 is weaker than aes-128!

https://www.schneier.com/blog/archives/ ... w_aes.html

I think it's useful to ask "who is the adversary?" here. in my thinking, for this VPN, att is the adversary and the design is fine - so long as att only sees a static tunnel leaving their network, they're unlikely to be able to do much, as traffic analysis is broken.

if the adversary is the government, nothing I do on a networked computer is secure and I need to be able to go out of band for privacy. traffic analysis is the least of my worries, but I do enjoy making it harder, and running VPN to multiple hosts helps. and the more of us running VPN, the more it helps.

[forest]

Kelsey, is the OpenVPN server configured to send ping / keepalive packets? At what interval? I'd like to use the --ping-restart option on my client.