[Openvpn-users] VirusTotal openvpn-install-2.4.3-I602.exe
Hello, I downloaded openvpn-install-2.4.3-I602.exe from https://openvpn.net/index.php/open-source/downloads.html and uploaded the file to https://www.virustotal.com. Baidu and TrendMicro-HouseCall reported a virus: https://www.virustotal.com/#/file/f722ff1d187951c4e7454e2d845ba6d0d43d505112e073fa60b67b350fd6bc87/detection I used gpg to check the file integrity: gpg -v --verify openvpn-install-2.4.3-I602.exe.asc gpg: armor header: Version: GnuPG v1 gpg: assuming signed data in `openvpn-install-2.4.3-I602.exe' gpg: Signature made петак, 14. јул 2017. (this means Friday, 14th July) 15:28:49 CEST using RSA key ID 8CC2B034 gpg: using subkey 8CC2B034 instead of primary key 2F2B01E7 gpg: using PGP trust model gpg: Good signature from "OpenVPN - Security Mailing List < secur...@openvpn.net>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: F554 A368 7412 CFFE BDEF E0A3 12F5 F7B4 2F2B 01E7 Subkey fingerprint: B596 06E2 D8C6 E10B 80BE 2B31 D72A F344 8CC2 B034 gpg: binary signature, digest algorithm SHA1 I assume it's a false positive, but I would appreciate if you could confirm this. I guess that the exe file could be infected at compile time. Many thanks, Igor Božović -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] VPN allows unencrypted traffic but not encrypted
We’ve got a very odd issue happening at a new customer’s site. The VPN is established quite happily at their site and unencrypted traffic through that VPN works perfectly (HTTP requests). However, encrypted traffic does not (HTTPS and SSH). SSH connections get this far before appearing to hang: debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400 debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [10.10.1.1]:26513 debug1: SSH2_MSG_KEXINIT sent Thie eventually times out. We moved the server to a standard broadband connection and everything works, including HTTPS and SSH connections. Is it possible there’s something on the path from their connection that’s causing this? As far as I’m aware all traffic through the VPN will appear as random bytes to anything it passes through, so I’m at a loss to explain this. Any help would be greatly appreciated. Thanks. -Stuart -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
Please, provide both server and client config. (We saw similar situation, when server was "comp-lzo yes" and client "comp-lzo no") 4 сент. 2017 г. 19:25 пользователь "Stuart Dallas" написал: > We’ve got a very odd issue happening at a new customer’s site. > > > The VPN is established quite happily at their site and unencrypted traffic > through that VPN works perfectly (HTTP requests). > > > However, encrypted traffic does not (HTTPS and SSH). SSH connections get > this far before appearing to hang: > > > > > debug1: Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-2.0-OpenSSH_6.6.1 > > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 > > debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400 > > debug2: fd 3 setting O_NONBLOCK > > debug3: put_host_port: [10.10.1.1]:26513 > > debug1: SSH2_MSG_KEXINIT sent > > > Thie eventually times out. > > > We moved the server to a standard broadband connection and everything > works, including HTTPS and SSH connections. > > > Is it possible there’s something on the path from their connection that’s > causing this? As far as I’m aware all traffic through the VPN will appear > as random bytes to anything it passes through, so I’m at a loss to explain > this. > > > Any help would be greatly appreciated. > > > Thanks. > > > -Stuart > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Openvpn-users mailing list > Openvpn-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
Happy to provide the configs, but as noted the configuration works perfectly when the server is on another internet connection. Server: local 0.0.0.0 port [redacted_port] proto udp dev cloudvpn dev-type tun ca cloud-ca.crt cert cloud-server.crt key cloud-server.key dh cloud-dh2048.pem topology subnet server 10.10.1.0 255.255.255.0 ifconfig-pool-persist cloud-ipp.txt client-config-dir cloud-ccd keepalive 10 120 tls-auth cloud-ta.key 0 cipher AES-256-CBC user nobody group nobody persist-key persist-tun status cloud-openvpn-status.log status-version 3 verb 3 mute 20 Client: client dev tun proto udp remote [redacted_ip] [redacted_port] resolv-retry infinite nobind user nobody group nobody persist-key persist-tun ca cloud-ca.crt cert cloud-client.crt key cloud-client.key remote-cert-tls server tls-auth cloud-ta.key 1 cipher AES-256-CBC mute 20 Thanks. -Stuart On 4 Sep 2017, 15:34 +0100, Илья Шипицин , wrote: > Please, provide both server and client config. > > (We saw similar situation, when server was "comp-lzo yes" and client > "comp-lzo no") > > > 4 сент. 2017 г. 19:25 пользователь "Stuart Dallas" > > написал: > > > We’ve got a very odd issue happening at a new customer’s site. > > > > > > The VPN is established quite happily at their site and unencrypted > > > traffic through that VPN works perfectly (HTTP requests). > > > > > > However, encrypted traffic does not (HTTPS and SSH). SSH connections get > > > this far before appearing to hang: > > > > > > > > > debug1: Enabling compatibility mode for protocol 2.0 > > > debug1: Local version string SSH-2.0-OpenSSH_6.6.1 > > > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 > > > debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400 > > > debug2: fd 3 setting O_NONBLOCK > > > debug3: put_host_port: [10.10.1.1]:26513 > > > debug1: SSH2_MSG_KEXINIT sent > > > > > > Thie eventually times out. > > > > > > We moved the server to a standard broadband connection and everything > > > works, including HTTPS and SSH connections. > > > > > > Is it possible there’s something on the path from their connection that’s > > > causing this? As far as I’m aware all traffic through the VPN will appear > > > as random bytes to anything it passes through, so I’m at a loss to > > > explain this. > > > > > > Any help would be greatly appreciated. > > > > > > Thanks. > > > > > > -Stuart > > > > > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > Openvpn-users mailing list > > > Openvpn-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
Sorry, I meant when the CLIENT is on another internet connection. To clarify, HTTP works fine through the VPN connection. HTTPS and SSH do not work through the VPN connection. All three work outside of the VPN connection. Thanks. -Stuart On 4 Sep 2017, 15:40 +0100, Stuart Dallas , wrote: > Happy to provide the configs, but as noted the configuration works perfectly > when the server is on another internet connection. > > Server: > > local 0.0.0.0 > port [redacted_port] > proto udp > dev cloudvpn > dev-type tun > ca cloud-ca.crt > cert cloud-server.crt > key cloud-server.key > dh cloud-dh2048.pem > topology subnet > server 10.10.1.0 255.255.255.0 > ifconfig-pool-persist cloud-ipp.txt > client-config-dir cloud-ccd > keepalive 10 120 > tls-auth cloud-ta.key 0 > cipher AES-256-CBC > user nobody > group nobody > persist-key > persist-tun > status cloud-openvpn-status.log > status-version 3 > verb 3 > mute 20 > > Client: > > client > dev tun > proto udp > remote [redacted_ip] [redacted_port] > resolv-retry infinite > nobind > user nobody > group nobody > persist-key > persist-tun > ca cloud-ca.crt > cert cloud-client.crt > key cloud-client.key > remote-cert-tls server > tls-auth cloud-ta.key 1 > cipher AES-256-CBC > mute 20 > > Thanks. > > -Stuart > > On 4 Sep 2017, 15:34 +0100, Илья Шипицин , wrote: > > Please, provide both server and client config. > > > > (We saw similar situation, when server was "comp-lzo yes" and client > > "comp-lzo no") > > > > > 4 сент. 2017 г. 19:25 пользователь "Stuart Dallas" > > > написал: > > > > We’ve got a very odd issue happening at a new customer’s site. > > > > > > > > The VPN is established quite happily at their site and unencrypted > > > > traffic through that VPN works perfectly (HTTP requests). > > > > > > > > However, encrypted traffic does not (HTTPS and SSH). SSH connections > > > > get this far before appearing to hang: > > > > > > > > > > > > debug1: Enabling compatibility mode for protocol 2.0 > > > > debug1: Local version string SSH-2.0-OpenSSH_6.6.1 > > > > debug1: Remote protocol version 2.0, remote software version > > > > OpenSSH_6.6.1 > > > > debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400 > > > > debug2: fd 3 setting O_NONBLOCK > > > > debug3: put_host_port: [10.10.1.1]:26513 > > > > debug1: SSH2_MSG_KEXINIT sent > > > > > > > > Thie eventually times out. > > > > > > > > We moved the server to a standard broadband connection and everything > > > > works, including HTTPS and SSH connections. > > > > > > > > Is it possible there’s something on the path from their connection > > > > that’s causing this? As far as I’m aware all traffic through the VPN > > > > will appear as random bytes to anything it passes through, so I’m at a > > > > loss to explain this. > > > > > > > > Any help would be greatly appreciated. > > > > > > > > Thanks. > > > > > > > > -Stuart > > > > > > > > > > > > -- > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > > > > Openvpn-users mailing list > > > > Openvpn-users@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
Also, we observed very rare situations when switching to tcp instead of udp resolved similar issues (did not have a chance to dig deeper) Can you try to switch to tcp? 4 сент. 2017 г. 19:40 пользователь "Stuart Dallas" написал: > Happy to provide the configs, but as noted the configuration works > perfectly when the server is on another internet connection. > > Server: > > local 0.0.0.0 > port [redacted_port] > proto udp > dev cloudvpn > dev-type tun > ca cloud-ca.crt > cert cloud-server.crt > key cloud-server.key > dh cloud-dh2048.pem > topology subnet > server 10.10.1.0 255.255.255.0 > ifconfig-pool-persist cloud-ipp.txt > client-config-dir cloud-ccd > keepalive 10 120 > tls-auth cloud-ta.key 0 > cipher AES-256-CBC > user nobody > group nobody > persist-key > persist-tun > status cloud-openvpn-status.log > status-version 3 > verb 3 > mute 20 > > Client: > > client > dev tun > proto udp > remote [redacted_ip] [redacted_port] > resolv-retry infinite > nobind > user nobody > group nobody > persist-key > persist-tun > ca cloud-ca.crt > cert cloud-client.crt > key cloud-client.key > remote-cert-tls server > tls-auth cloud-ta.key 1 > cipher AES-256-CBC > mute 20 > > Thanks. > > -Stuart > > On 4 Sep 2017, 15:34 +0100, Илья Шипицин , wrote: > > Please, provide both server and client config. > > (We saw similar situation, when server was "comp-lzo yes" and client > "comp-lzo no") > > 4 сент. 2017 г. 19:25 пользователь "Stuart Dallas" > написал: > >> We’ve got a very odd issue happening at a new customer’s site. >> >> >> The VPN is established quite happily at their site and unencrypted >> traffic through that VPN works perfectly (HTTP requests). >> >> >> However, encrypted traffic does not (HTTPS and SSH). SSH connections get >> this far before appearing to hang: >> >> >> >> >> debug1: Enabling compatibility mode for protocol 2.0 >> >> debug1: Local version string SSH-2.0-OpenSSH_6.6.1 >> >> debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 >> >> debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400 >> >> debug2: fd 3 setting O_NONBLOCK >> >> debug3: put_host_port: [10.10.1.1]:26513 >> >> debug1: SSH2_MSG_KEXINIT sent >> >> >> Thie eventually times out. >> >> >> We moved the server to a standard broadband connection and everything >> works, including HTTPS and SSH connections. >> >> >> Is it possible there’s something on the path from their connection that’s >> causing this? As far as I’m aware all traffic through the VPN will appear >> as random bytes to anything it passes through, so I’m at a loss to explain >> this. >> >> >> Any help would be greatly appreciated. >> >> >> Thanks. >> >> >> -Stuart >> >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> Openvpn-users mailing list >> Openvpn-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openvpn-users >> >> -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
We’ve just tried TCP and the issue has gone away. Can anyone tell me why this happens? Also, what’s the reason for UDP being preferred over TCP? Thanks. -Stuart On 4 Sep 2017, 15:46 +0100, Илья Шипицин , wrote: > Also, we observed very rare situations when switching to tcp instead of udp > resolved similar issues (did not have a chance to dig deeper) > > Can you try to switch to tcp? > > > 4 сент. 2017 г. 19:40 пользователь "Stuart Dallas" > > написал: > > > Happy to provide the configs, but as noted the configuration works > > > perfectly when the server is on another internet connection. > > > > > > Server: > > > > > > local 0.0.0.0 > > > port [redacted_port] > > > proto udp > > > dev cloudvpn > > > dev-type tun > > > ca cloud-ca.crt > > > cert cloud-server.crt > > > key cloud-server.key > > > dh cloud-dh2048.pem > > > topology subnet > > > server 10.10.1.0 255.255.255.0 > > > ifconfig-pool-persist cloud-ipp.txt > > > client-config-dir cloud-ccd > > > keepalive 10 120 > > > tls-auth cloud-ta.key 0 > > > cipher AES-256-CBC > > > user nobody > > > group nobody > > > persist-key > > > persist-tun > > > status cloud-openvpn-status.log > > > status-version 3 > > > verb 3 > > > mute 20 > > > > > > Client: > > > > > > client > > > dev tun > > > proto udp > > > remote [redacted_ip] [redacted_port] > > > resolv-retry infinite > > > nobind > > > user nobody > > > group nobody > > > persist-key > > > persist-tun > > > ca cloud-ca.crt > > > cert cloud-client.crt > > > key cloud-client.key > > > remote-cert-tls server > > > tls-auth cloud-ta.key 1 > > > cipher AES-256-CBC > > > mute 20 > > > > > > Thanks. > > > > > > -Stuart > > > > > > On 4 Sep 2017, 15:34 +0100, Илья Шипицин , wrote: > > > > Please, provide both server and client config. > > > > > > > > (We saw similar situation, when server was "comp-lzo yes" and client > > > > "comp-lzo no") > > > > > > > > > 4 сент. 2017 г. 19:25 пользователь "Stuart Dallas" > > > > > написал: > > > > > > We’ve got a very odd issue happening at a new customer’s site. > > > > > > > > > > > > The VPN is established quite happily at their site and unencrypted > > > > > > traffic through that VPN works perfectly (HTTP requests). > > > > > > > > > > > > However, encrypted traffic does not (HTTPS and SSH). SSH > > > > > > connections get this far before appearing to hang: > > > > > > > > > > > > > > > > > > debug1: Enabling compatibility mode for protocol 2.0 > > > > > > debug1: Local version string SSH-2.0-OpenSSH_6.6.1 > > > > > > debug1: Remote protocol version 2.0, remote software version > > > > > > OpenSSH_6.6.1 > > > > > > debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400 > > > > > > debug2: fd 3 setting O_NONBLOCK > > > > > > debug3: put_host_port: [10.10.1.1]:26513 > > > > > > debug1: SSH2_MSG_KEXINIT sent > > > > > > > > > > > > Thie eventually times out. > > > > > > > > > > > > We moved the server to a standard broadband connection and > > > > > > everything works, including HTTPS and SSH connections. > > > > > > > > > > > > Is it possible there’s something on the path from their connection > > > > > > that’s causing this? As far as I’m aware all traffic through the > > > > > > VPN will appear as random bytes to anything it passes through, so > > > > > > I’m at a loss to explain this. > > > > > > > > > > > > Any help would be greatly appreciated. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > -Stuart > > > > > > > > > > > > > > > > > > -- > > > > > > Check out the vibrant tech community on one of the world's most > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > ___ > > > > > > Openvpn-users mailing list > > > > > > Openvpn-users@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > > > > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
Top Posting: UDP is preferred vs TCP because of TCP inside TCP issues - e.g. TCP sliding window ACK inside another TCP sliding window ACK. As packet loss increases, this becomes a huge problem. Essentailly, you have TCP stream inside the OVPN tunnel, and it's being ferried to the remote site/client. And the outside tunnel is also a TCP connection. All the "benefits" of TCP connections, essentially can become problems with having a TCP inside TCP conntection. Rather than rehash it all - here's a decent link that describes some of the problems: http://sites.inka.de/bigred/devel/tcp-tcp.html I don't have any authoritative thoughts on why TCP would work when UDP doesn't, but one thing that comes to mind is MTU size. If the MTU size was too large, UDP will simply fail. TCP *should* [but may not always] get a fragmentation notification telling the sender to fragment the packets down to fit through a smaller than expected MTU in the connection. Do some searches on MTU/MSS and see if you can determine if your pathway has a smaller than expected MTU. PPPoE is one specific case where MTU's are smaller because of the PPPoE overhead. Some good reading re: MTU/MSS. [Not carefully vetted, just quick perusal seems to indicate they might be useful reading.] https://supportforums.cisco.com/t5/lan-switching-and-routing/mtu-mss-and-tcp-window-size/td-p/2966099 https://learningnetwork.cisco.com/thread/91863 -Greg We’ve just tried TCP and the issue has gone away. Can anyone tell me why this happens? Also, what’s the reason for UDP being preferred over TCP? Thanks. -Stuart [SNIP]-- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
This _might_ happen because of mtu issues. tcp has advanced level of negotiation, which udp does not have: mss It would be nice if you would have compared packet sizes in both cases (and have a deep look to mss) udp is preffered, you should not use tcp without strong reason. 4 сент. 2017 г. 20:57 пользователь "Stuart Dallas" написал: > We’ve just tried TCP and the issue has gone away. > > Can anyone tell me why this happens? Also, what’s the reason for UDP being > preferred over TCP? > > Thanks. > > -Stuart > > On 4 Sep 2017, 15:46 +0100, Илья Шипицин , wrote: > > Also, we observed very rare situations when switching to tcp instead of > udp resolved similar issues (did not have a chance to dig deeper) > > Can you try to switch to tcp? > > 4 сент. 2017 г. 19:40 пользователь "Stuart Dallas" > написал: > >> Happy to provide the configs, but as noted the configuration works >> perfectly when the server is on another internet connection. >> >> Server: >> >> local 0.0.0.0 >> port [redacted_port] >> proto udp >> dev cloudvpn >> dev-type tun >> ca cloud-ca.crt >> cert cloud-server.crt >> key cloud-server.key >> dh cloud-dh2048.pem >> topology subnet >> server 10.10.1.0 255.255.255.0 >> ifconfig-pool-persist cloud-ipp.txt >> client-config-dir cloud-ccd >> keepalive 10 120 >> tls-auth cloud-ta.key 0 >> cipher AES-256-CBC >> user nobody >> group nobody >> persist-key >> persist-tun >> status cloud-openvpn-status.log >> status-version 3 >> verb 3 >> mute 20 >> >> Client: >> >> client >> dev tun >> proto udp >> remote [redacted_ip] [redacted_port] >> resolv-retry infinite >> nobind >> user nobody >> group nobody >> persist-key >> persist-tun >> ca cloud-ca.crt >> cert cloud-client.crt >> key cloud-client.key >> remote-cert-tls server >> tls-auth cloud-ta.key 1 >> cipher AES-256-CBC >> mute 20 >> >> Thanks. >> >> -Stuart >> >> On 4 Sep 2017, 15:34 +0100, Илья Шипицин , wrote: >> >> Please, provide both server and client config. >> >> (We saw similar situation, when server was "comp-lzo yes" and client >> "comp-lzo no") >> >> 4 сент. 2017 г. 19:25 пользователь "Stuart Dallas" >> написал: >> >>> We’ve got a very odd issue happening at a new customer’s site. >>> >>> >>> The VPN is established quite happily at their site and unencrypted >>> traffic through that VPN works perfectly (HTTP requests). >>> >>> >>> However, encrypted traffic does not (HTTPS and SSH). SSH connections get >>> this far before appearing to hang: >>> >>> >>> >>> >>> debug1: Enabling compatibility mode for protocol 2.0 >>> >>> debug1: Local version string SSH-2.0-OpenSSH_6.6.1 >>> >>> debug1: Remote protocol version 2.0, remote software version >>> OpenSSH_6.6.1 >>> >>> debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x0400 >>> >>> debug2: fd 3 setting O_NONBLOCK >>> >>> debug3: put_host_port: [10.10.1.1]:26513 >>> >>> debug1: SSH2_MSG_KEXINIT sent >>> >>> >>> Thie eventually times out. >>> >>> >>> We moved the server to a standard broadband connection and everything >>> works, including HTTPS and SSH connections. >>> >>> >>> Is it possible there’s something on the path from their connection >>> that’s causing this? As far as I’m aware all traffic through the VPN will >>> appear as random bytes to anything it passes through, so I’m at a loss to >>> explain this. >>> >>> >>> Any help would be greatly appreciated. >>> >>> >>> Thanks. >>> >>> >>> -Stuart >>> >>> >>> >>> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> ___ >>> Openvpn-users mailing list >>> Openvpn-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/openvpn-users >>> >>> -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
Hi, On Mon, Sep 04, 2017 at 03:25:02PM +0100, Stuart Dallas wrote: > The VPN is established quite happily at their site and unencrypted traffic > through that VPN works perfectly (HTTP requests). > > However, encrypted traffic does not (HTTPS and SSH). SSH connections get this > far before appearing to hang: I'd assume that this has something to do with the compressibility of inside traffic, and fragments getting lost (-> SSH KEX is a big packet, which will end up larger than a full 1500 byte packet after OpenVPN, so gets fragmented - and if the network is broken enough, fragments get lost). Try --mssfix 1200 on client or server. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] VPN allows unencrypted traffic but not encrypted
>I don't have any authoritative thoughts on why TCP would work when UDP doesn't, but one thing that comes to mind is MTU size. If the MTU size was too large, UDP will simply fail. TCP *should* [but may not always] get a fragmentation notification telling the sender to fragment the packets down to fit through a smaller than expected MTU in the connection. Make sense. Try to add following options to both sides: mssfix 1200 # tell up-level tcp to not send a packet larger than 1200,this only works for tcpfragment 1200 # fragment a packet if it is larger than 1200,this works for udp/icmp(also works for tcp if 'mssfix' is not set,but not as efficient as 'mssfix') On Mon, Sep 4, 2017 at 9:13 AM, Gregory Sloop wrote: > Top Posting: > > UDP is preferred vs TCP because of TCP inside TCP issues - e.g. TCP > sliding window ACK inside another TCP sliding window ACK. As packet loss > increases, this becomes a huge problem. Essentailly, you have TCP stream > inside the OVPN tunnel, and it's being ferried to the remote site/client. > And the outside tunnel is also a TCP connection. All the "benefits" of TCP > connections, essentially can become problems with having a TCP inside TCP > conntection. > > Rather than rehash it all - here's a decent link that describes some of > the problems: > http://sites.inka.de/bigred/devel/tcp-tcp.html > > I don't have any authoritative thoughts on why TCP would work when UDP > doesn't, but one thing that comes to mind is MTU size. If the MTU size was > too large, UDP will simply fail. TCP *should* [but may not always] get a > fragmentation notification telling the sender to fragment the packets down > to fit through a smaller than expected MTU in the connection. > > Do some searches on MTU/MSS and see if you can determine if your pathway > has a smaller than expected MTU. PPPoE is one specific case where MTU's are > smaller because of the PPPoE overhead. > > Some good reading re: MTU/MSS. [Not carefully vetted, just quick perusal > seems to indicate they might be useful reading.] > https://supportforums.cisco.com/t5/lan-switching-and- > routing/mtu-mss-and-tcp-window-size/td-p/2966099 > https://learningnetwork.cisco.com/thread/91863 > > -Greg > > > > We’ve just tried TCP and the issue has gone away. > > Can anyone tell me why this happens? Also, what’s the reason for UDP being > preferred over TCP? > > Thanks. > > -Stuart > > [SNIP] > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Openvpn-users mailing list > Openvpn-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
