Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here ΞΞ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub ΞΞ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

[root@onyx ~]# host linux-useast.cryptostorm.org;; Truncated, retrying in TCP mode.linux-useast.cryptostorm.org has address 192.158.233.221linux-useast.cryptostorm.org has address 155.254.31.46linux-useast.cryptostorm.org has address 192.158.232.124linux-useast.cryptostorm.org has address 192.158.232.100linux-useast.cryptostorm.org has address 155.254.31.26linux-useast.cryptostorm.org has address 198.7.58.245linux-useast.cryptostorm.org has address 173.234.159.236linux-useast.cryptostorm.org has address 192.158.232.122linux-useast.cryptostorm.org has address 155.254.31.50linux-useast.cryptostorm.org has address 192.158.233.197linux-useast.cryptostorm.org has address 192.158.233.195linux-useast.cryptostorm.org has address 192.158.232.114linux-useast.cryptostorm.org has address 192.158.233.217linux-useast.cryptostorm.org has address 192.158.233.211linux-useast.cryptostorm.org has address 192.158.232.126linux-useast.cryptostorm.org has address 155.254.31.48linux-useast.cryptostorm.org has address 192.158.233.207linux-useast.cryptostorm.org has address 192.158.233.205linux-useast.cryptostorm.org has address 155.254.31.32linux-useast.cryptostorm.org has address 155.254.31.42linux-useast.cryptostorm.org has address 192.158.232.102linux-useast.cryptostorm.org has address 192.158.233.219linux-useast.cryptostorm.org has address 155.254.31.30linux-useast.cryptostorm.org has address 192.158.233.213linux-useast.cryptostorm.org has address 155.254.29.121linux-useast.cryptostorm.org has address 155.254.31.28linux-useast.cryptostorm.org has address 155.254.29.123linux-useast.cryptostorm.org has address 155.254.31.40linux-useast.cryptostorm.org has address 192.158.232.108linux-useast.cryptostorm.org has address 155.254.31.44linux-useast.cryptostorm.org has address 155.254.31.38linux-useast.cryptostorm.org has address 192.158.232.110linux-useast.cryptostorm.org has address 155.254.31.34linux-useast.cryptostorm.org has address 192.158.233.199linux-useast.cryptostorm.org has address 155.254.29.119linux-useast.cryptostorm.org has address 192.158.232.120linux-useast.cryptostorm.org has address 192.158.233.203linux-useast.cryptostorm.org has address 155.254.29.115linux-useast.cryptostorm.org has address 155.254.31.36linux-useast.cryptostorm.org has address 192.158.232.104linux-useast.cryptostorm.org has address 192.158.233.201linux-useast.cryptostorm.org has address 192.158.233.215linux-useast.cryptostorm.org has address 155.254.29.125linux-useast.cryptostorm.org has address 192.158.232.116linux-useast.cryptostorm.org has address 192.158.233.209linux-useast.cryptostorm.org has address 192.158.232.112linux-useast.cryptostorm.org has address 155.254.29.117linux-useast.cryptostorm.org has address 192.158.232.118linux-useast.cryptostorm.org has address 192.158.232.106

US east did get a bunch of new IPs recently. Normally, if there are too many records in the DNS response when using UDP, the DNS client software will switch to TCP automatically. I guess some older or non-RFC compliant DNS clients might have a problem with the large number of records returned for linux-useast (or windows-useast).

So to solve your issue, you could either upgrade whatever DNS software your system is using, or switch to a more RFC compliant one, or you could just replace the linux-useast.* line(s) in your config with one of the above IPs.If you don't want to keep using the same US east IP every time you connect, you can instead use 192.158.232.98That IP is a balancer for all of the North Carolina IPs in US east. So if you connect to 192.158.232.98, you'll get an exit IP of one of the ones listed above.

Also, since you're on Linux, your DNS software might be fine. It could instead be the DNS server your system is using that's not doing RFC compliant things, like reattempting some DNS with TCP. If that's the case you could try using a different DNS server, like 155.254.29.113 for our North Carolina DNS server, or if you want to use a non-CS one, Cloudflare's 1.1.1.1 seems good.

[code][root@onyx ~]# host linux-useast.cryptostorm.org;; Truncated, retrying in TCP mode.linux-useast.cryptostorm.org has address 192.158.233.221linux-useast.cryptostorm.org has address 155.254.31.46linux-useast.cryptostorm.org has address 192.158.232.124linux-useast.cryptostorm.org has address 192.158.232.100linux-useast.cryptostorm.org has address 155.254.31.26linux-useast.cryptostorm.org has address 198.7.58.245linux-useast.cryptostorm.org has address 173.234.159.236linux-useast.cryptostorm.org has address 192.158.232.122linux-useast.cryptostorm.org has address 155.254.31.50linux-useast.cryptostorm.org has address 192.158.233.197linux-useast.cryptostorm.org has address 192.158.233.195linux-useast.cryptostorm.org has address 192.158.232.114linux-useast.cryptostorm.org has address 192.158.233.217linux-useast.cryptostorm.org has address 192.158.233.211linux-useast.cryptostorm.org has address 192.158.232.126linux-useast.cryptostorm.org has address 155.254.31.48linux-useast.cryptostorm.org has address 192.158.233.207linux-useast.cryptostorm.org has address 192.158.233.205linux-useast.cryptostorm.org has address 155.254.31.32linux-useast.cryptostorm.org has address 155.254.31.42linux-useast.cryptostorm.org has address 192.158.232.102linux-useast.cryptostorm.org has address 192.158.233.219linux-useast.cryptostorm.org has address 155.254.31.30linux-useast.cryptostorm.org has address 192.158.233.213linux-useast.cryptostorm.org has address 155.254.29.121linux-useast.cryptostorm.org has address 155.254.31.28linux-useast.cryptostorm.org has address 155.254.29.123linux-useast.cryptostorm.org has address 155.254.31.40linux-useast.cryptostorm.org has address 192.158.232.108linux-useast.cryptostorm.org has address 155.254.31.44linux-useast.cryptostorm.org has address 155.254.31.38linux-useast.cryptostorm.org has address 192.158.232.110linux-useast.cryptostorm.org has address 155.254.31.34linux-useast.cryptostorm.org has address 192.158.233.199linux-useast.cryptostorm.org has address 155.254.29.119linux-useast.cryptostorm.org has address 192.158.232.120linux-useast.cryptostorm.org has address 192.158.233.203linux-useast.cryptostorm.org has address 155.254.29.115linux-useast.cryptostorm.org has address 155.254.31.36linux-useast.cryptostorm.org has address 192.158.232.104linux-useast.cryptostorm.org has address 192.158.233.201linux-useast.cryptostorm.org has address 192.158.233.215linux-useast.cryptostorm.org has address 155.254.29.125linux-useast.cryptostorm.org has address 192.158.232.116linux-useast.cryptostorm.org has address 192.158.233.209linux-useast.cryptostorm.org has address 192.158.232.112linux-useast.cryptostorm.org has address 155.254.29.117linux-useast.cryptostorm.org has address 192.158.232.118linux-useast.cryptostorm.org has address 192.158.232.106[/code]

US east did get a bunch of new IPs recently. Normally, if there are too many records in the DNS response when using UDP, the DNS client software will switch to TCP automatically. I guess some older or non-RFC compliant DNS clients might have a problem with the large number of records returned for linux-useast (or windows-useast).

So to solve your issue, you could either upgrade whatever DNS software your system is using, or switch to a more RFC compliant one, or you could just replace the linux-useast.* line(s) in your config with one of the above IPs.If you don't want to keep using the same US east IP every time you connect, you can instead use 192.158.232.98That IP is a balancer for all of the North Carolina IPs in US east. So if you connect to 192.158.232.98, you'll get an exit IP of one of the ones listed above.

Also, since you're on Linux, your DNS software might be fine. It could instead be the DNS server your system is using that's not doing RFC compliant things, like reattempting some DNS with TCP. If that's the case you could try using a different DNS server, like 155.254.29.113 for our North Carolina DNS server, or if you want to use a non-CS one, Cloudflare's 1.1.1.1 seems good.

[root@onyx ~]# ./ping windows-useast.cstorm.pw 443UDP OpenVPN is UP on 192.158.232.121:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.194:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.105:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.125:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.208:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.119:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.33:443 and responded in 88 msUDP OpenVPN is UP on 192.158.232.101:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.196:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.222:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.115:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.202:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.39:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.212:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.122:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.123:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.45:443 and responded in 86 msUDP OpenVPN is UP on 155.254.29.120:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.124:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.218:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.116:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.113:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.206:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.216:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.214:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.109:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.47:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.114:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.103:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.31:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.29:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.49:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.111:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.117:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.27:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.220:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.35:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.43:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.200:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.198:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.41:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.37:443 and responded in 86 msUDP OpenVPN is UP on 198.7.58.246:443 and responded in 84 msUDP OpenVPN is UP on 155.254.29.118:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.204:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.107:443 and responded in 86 msUDP OpenVPN is UP on 172.241.166.147:443 and responded in 80 msUDP OpenVPN is UP on 192.158.233.210:443 and responded in 87 ms[root@onyx ~]# ./ping linux-useast.cstorm.pw 443UDP OpenVPN is UP on 192.158.233.213:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.38:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.211:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.40:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.104:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.118:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.112:443 and responded in 88 msUDP OpenVPN is UP on 155.254.31.28:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.44:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.219:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.201:443 and responded in 87 msUDP OpenVPN is UP on 173.234.159.236:443 and responded in 74 msUDP OpenVPN is UP on 192.158.233.221:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.50:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.205:443 and responded in 88 msUDP OpenVPN is UP on 155.254.29.121:443 and responded in 86 msUDP OpenVPN is UP on 155.254.29.123:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.125:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.199:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.117:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.46:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.122:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.207:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.32:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.36:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.120:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.203:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.197:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.108:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.116:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.209:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.215:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.124:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.110:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.114:443 and responded in 86 msUDP OpenVPN is UP on 155.254.29.119:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.48:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.30:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.100:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.115:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.26:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.102:443 and responded in 88 msUDP OpenVPN is UP on 192.158.233.195:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.42:443 and responded in 86 msUDP OpenVPN is UP on 198.7.58.245:443 and responded in 90 msUDP OpenVPN is UP on 192.158.233.217:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.126:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.106:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.34:443 and responded in 87 ms

@sottovoceWhat error are you getting? I just checked all the UDP IPs on port 443 for USEast and they seem responsive:

[code][root@onyx ~]# ./ping windows-useast.cstorm.pw 443UDP OpenVPN is UP on 192.158.232.121:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.194:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.105:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.125:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.208:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.119:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.33:443 and responded in 88 msUDP OpenVPN is UP on 192.158.232.101:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.196:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.222:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.115:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.202:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.39:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.212:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.122:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.123:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.45:443 and responded in 86 msUDP OpenVPN is UP on 155.254.29.120:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.124:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.218:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.116:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.113:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.206:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.216:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.214:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.109:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.47:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.114:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.103:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.31:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.29:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.49:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.111:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.117:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.27:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.220:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.35:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.43:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.200:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.198:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.41:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.37:443 and responded in 86 msUDP OpenVPN is UP on 198.7.58.246:443 and responded in 84 msUDP OpenVPN is UP on 155.254.29.118:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.204:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.107:443 and responded in 86 msUDP OpenVPN is UP on 172.241.166.147:443 and responded in 80 msUDP OpenVPN is UP on 192.158.233.210:443 and responded in 87 ms[root@onyx ~]# ./ping linux-useast.cstorm.pw 443UDP OpenVPN is UP on 192.158.233.213:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.38:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.211:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.40:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.104:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.118:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.112:443 and responded in 88 msUDP OpenVPN is UP on 155.254.31.28:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.44:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.219:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.201:443 and responded in 87 msUDP OpenVPN is UP on 173.234.159.236:443 and responded in 74 msUDP OpenVPN is UP on 192.158.233.221:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.50:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.205:443 and responded in 88 msUDP OpenVPN is UP on 155.254.29.121:443 and responded in 86 msUDP OpenVPN is UP on 155.254.29.123:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.125:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.199:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.117:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.46:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.122:443 and responded in 86 msUDP OpenVPN is UP on 192.158.233.207:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.32:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.36:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.120:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.203:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.197:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.108:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.116:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.209:443 and responded in 87 msUDP OpenVPN is UP on 192.158.233.215:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.124:443 and responded in 86 msUDP OpenVPN is UP on 192.158.232.110:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.114:443 and responded in 86 msUDP OpenVPN is UP on 155.254.29.119:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.48:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.30:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.100:443 and responded in 87 msUDP OpenVPN is UP on 155.254.29.115:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.26:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.102:443 and responded in 88 msUDP OpenVPN is UP on 192.158.233.195:443 and responded in 86 msUDP OpenVPN is UP on 155.254.31.42:443 and responded in 86 msUDP OpenVPN is UP on 198.7.58.245:443 and responded in 90 msUDP OpenVPN is UP on 192.158.233.217:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.126:443 and responded in 87 msUDP OpenVPN is UP on 192.158.232.106:443 and responded in 87 msUDP OpenVPN is UP on 155.254.31.34:443 and responded in 87 ms[/code]

westerndigital.secure.force.com now fails to resolve on England and Frankfurt. This site handles support for Western Digital (warranty, RMA etc.) so I have no idea how it made its way onto a blocklist.

[b]@thread[/b]

[b]westerndigital.secure.force.com[/b] now fails to resolve on England and Frankfurt. This site handles support for Western Digital (warranty, RMA etc.) so I have no idea how it made its way onto a blocklist.

@parityboyYea. First one pushed would be the primary, second one pushed would be the secondary, etc.In my test, when I added "dhcp-option DNS 10.31.33.7" to my client config, it set that as the primary DNS and the one pushed by the OpenVPN server as the secondary DNS. If had a regular/default client config and I changed the server-side config from:push "dhcp-option DNS 212.129.46.86"to:push "dhcp-option DNS 212.129.46.86"push "dhcp-option DNS 8.8.8.8"then it would set 212.129.46.86 as the primary and 8.8.8.8 as the secondary.

As for your second question, I think that is somewhat possible if we were doing client certificates and static IP pools, but with our current setup all clients appear the same in this context. Most configuration directives are loaded in from a single file, and all clients use that configuration.Some dynamic directives can be pushed from the server though, like in our --client-connect script @ https://cryptostorm.is/conf/session_up.sh.txt we use to randomly generate then push the 10.x.x.x IP the client gets assigned.Reason we do that is by default OpenVPN uses simple sequential numbering for the last octets in that 10.x.x.x IP.With sequential numbering, if you connect to the server and get 10.22.0.4 then you know there's 2 other clients on that OpenVPN server instance (.1 is the gateway, .2 is client1, .3 is client2, .4 is you).That might be useful information in a correlation attack, like if you knew the b-class of a client's real IP but weren't sure, you could DDoS parts of that b-class until the number of clients on the VPN server decreased.When it decreased, you probably hit the client, so you rinse and repeat until the target network gets small enough that you end up with a single IP.Not a very likely scenario if a server's busy enough with many clients connecting/disconnecting all the time, but since randomly generating those 10.x.x.x VPN IPs is easy enough, we thought it'd be better to have it :-P

@parityboyYea. First one pushed would be the primary, second one pushed would be the secondary, etc.In my test, when I added "dhcp-option DNS 10.31.33.7" to my client config, it set that as the primary DNS and the one pushed by the OpenVPN server as the secondary DNS. If had a regular/default client config and I changed the server-side config from:push "dhcp-option DNS 212.129.46.86"to:push "dhcp-option DNS 212.129.46.86"push "dhcp-option DNS 8.8.8.8"then it would set 212.129.46.86 as the primary and 8.8.8.8 as the secondary.

As for your second question, I think that is somewhat possible if we were doing client certificates and static IP pools, but with our current setup all clients appear the same in this context. Most configuration directives are loaded in from a single file, and all clients use that configuration.Some dynamic directives can be pushed from the server though, like in our --client-connect script @ https://cryptostorm.is/conf/session_up.sh.txt we use to randomly generate then push the 10.x.x.x IP the client gets assigned.Reason we do that is by default OpenVPN uses simple sequential numbering for the last octets in that 10.x.x.x IP.With sequential numbering, if you connect to the server and get 10.22.0.4 then you know there's 2 other clients on that OpenVPN server instance (.1 is the gateway, .2 is client1, .3 is client2, .4 is you).That might be useful information in a correlation attack, like if you knew the b-class of a client's real IP but weren't sure, you could DDoS parts of that b-class until the number of clients on the VPN server decreased.When it decreased, you probably hit the client, so you rinse and repeat until the target network gets small enough that you end up with a single IP.Not a very likely scenario if a server's busy enough with many clients connecting/disconnecting all the time, but since randomly generating those 10.x.x.x VPN IPs is easy enough, we thought it'd be better to have it :-P

Anyways, all the OpenVPN directives to call scripts are: up, down, ipchange, route-up, tls-verify, auth-user-pass-verify, client-connect, client-disconnect, and learn-addressSee https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage#lbAT and other parts of the manual

Quick question: can the server push more than one DNS server entry to the client? Are they stacked on the client, i.e. last in first out?

Also, when the OpenVPN server forks an instance for a given session, can it load a configuration file for that specific instance, or is the configuration global?

I'm wondering if it would be possible to indeed use the password as an option source, combined with sed to modify a config on the fly before pushing anything back to the client. That way, you could use the auth script to choose which DNS option to send to the client.

Forget it, it's going to spawn a process as soon as the connection comes in so it will already have its config. Pity.

[b]@df[/b]

Cheers for the explanation. :)

Quick question: can the server push more than one DNS server entry to the client? Are they stacked on the client, i.e. last in first out?

[s]Also, when the OpenVPN server forks an instance for a given session, can it load a configuration file for that specific instance, or is the configuration global?

I'm wondering if it would be possible to indeed use the password as an option source, combined with [i]sed[/i] to modify a config on the fly before pushing anything back to the client. That way, you could use the auth script to choose which DNS option to send to the client.[/s]

Forget it, it's going to spawn a process as soon as the connection comes in so it will already have its config. Pity.

@parityboyYea, plus doing this with LUA/pdns means all DNS requests would have to pass through that LUA script, which would decrease performance.The password option does sound easier for clients, even with the required instance restart.

The only thing I haven't decided yet is do I make TS the default, and require setting a specific password to disable it, or do I make it disabled by default, and have setting the password enable it.

EDIT:It doesn't look like the password method is going to work. The server-side --auth-user-pass-verify script is the only thing that has access to the password, unless I did some additional logging that would tie a token to an IP, which is definitely not a good idea. Also, I would need the client's internal 10.x.x.x internal IP to forward DNS for that client to the non-TS DNS server, and that internal IP doesn't get generated until the --client-connect script runs, which doesn't have access to the password.

I think I found a solution that'll work though. If I add to the client config "dhcp-option DNS 10.31.33.7", then it'll set that IP as the primary DNS server, and keep the one pushed by the VPN server as a secondary.Already tested on an empty server and doing that lets me resolve things blocked by TS, and when I tell nslookup to use the secondary DNS server, it's correctly blocked by TS.The only real downside to doing it this way is that I can't instantly enable or disable TS, the client would have to disconnect/reconnect for that change to take effect.There are other more complex options that would allow me to instantly enable/disable TS, but they all seem to require more steps than I think most users would care for.For widget users, it would be easy enough to select the TS option and have the widget do all the work.But for Linux or OpenVPN GUI users, I don't see them doing all that work.Adding a single line to the config seems more likely, especially if I update the configs on github to include the option, but commented out.

Also, I've seen a lot of complaints from non-CS members who are using the DNS servers on their systems and some things not resolving because of TS, and since they don't know about TS (our fault for poorly documenting it), they think the server is bugged.Mainly for that reason, I think when I make this need option live, I'll have TS disabled by default.So instead, adding "dhcp-option DNS 10.31.33.7" to the client config would enable TS.

@parityboyYea, plus doing this with LUA/pdns means all DNS requests would have to pass through that LUA script, which would decrease performance.The password option does sound easier for clients, even with the required instance restart.

The only thing I haven't decided yet is do I make TS the default, and require setting a specific password to disable it, or do I make it disabled by default, and have setting the password enable it.

EDIT:It doesn't look like the password method is going to work. The server-side --auth-user-pass-verify script is the only thing that has access to the password, unless I did some additional logging that would tie a token to an IP, which is definitely not a good idea. Also, I would need the client's internal 10.x.x.x internal IP to forward DNS for that client to the non-TS DNS server, and that internal IP doesn't get generated until the --client-connect script runs, which doesn't have access to the password.

I think I found a solution that'll work though. If I add to the client config "dhcp-option DNS 10.31.33.7", then it'll set that IP as the primary DNS server, and keep the one pushed by the VPN server as a secondary.Already tested on an empty server and doing that lets me resolve things blocked by TS, and when I tell nslookup to use the secondary DNS server, it's correctly blocked by TS.The only real downside to doing it this way is that I can't instantly enable or disable TS, the client would have to disconnect/reconnect for that change to take effect.There are other more complex options that would allow me to instantly enable/disable TS, but they all seem to require more steps than I think most users would care for.For widget users, it would be easy enough to select the TS option and have the widget do all the work.But for Linux or OpenVPN GUI users, I don't see them doing all that work.Adding a single line to the config seems more likely, especially if I update the configs on github to include the option, but commented out.

Also, I've seen a lot of complaints from non-CS members who are using the DNS servers on their systems and some things not resolving because of TS, and since they don't know about TS (our fault for poorly documenting it), they think the server is bugged.Mainly for that reason, I think when I make this need option live, I'll have TS disabled by default.So instead, adding "dhcp-option DNS 10.31.33.7" to the client config would enable TS.

The only issue with the two-step approach is that it's two steps. A small price to pay for better security but you know what people are like. One good thing about the password field approach is that it's scalable - you can add switches to activate other features in the future, much like a Web API.

[b]@df[/b]

The only issue with the two-step approach is that it's two steps. :) A small price to pay for better security but you know what people are like. :P One good thing about the password field approach is that it's scalable - you can add switches to activate other features in the future, much like a Web API. :)

@parityboyThat's one method I was thinking of, the only problem is that doing it that way requires all the server-side OpenVPN's to be restarted so that I can change --auth-user-pass-verify from via-env to via-file, or change --script-security 2 to 3.Another idea I was considering is using pdns-recursor's (part of DeepDNS) LUA scripting to monitor for a specific hostname, say "nots.cryptostorm.is". If the client resolves that IP, then a new iptables rule is created that forwards all further DNS to a secondary pdns-recursor instance that has TS disabled.For the users that don't know how to run `nslookup` or `ping` to activate that DNS resolution, they could simply use their browser to go to the hostname.One benefit of doing it that way is that I can also have the hostname resolve to that 10.31.33.7 IP that all the servers have an Apache listening on, mostly used for widget updates. I could setup a VirtualHost config on there so when people goto http://nots.cryptostorm.is/ they see a page telling them that TS is disabled now.I guess for widget users, it'd be easier since I could do the nslookup from there, so widget people only have to select the "Disable TrackerSmacker" option.

Anyways, I'll test out the LUA/pdns thing. If the performance hit is too much, I guess I'll bite the bullet and change all the configs to use via-file or script-security 3 so I can access the password.

@parityboyThat's one method I was thinking of, the only problem is that doing it that way requires all the server-side OpenVPN's to be restarted so that I can change --auth-user-pass-verify from via-env to via-file, or change --script-security 2 to 3.Another idea I was considering is using pdns-recursor's (part of DeepDNS) LUA scripting to monitor for a specific hostname, say "nots.cryptostorm.is". If the client resolves that IP, then a new iptables rule is created that forwards all further DNS to a secondary pdns-recursor instance that has TS disabled.For the users that don't know how to run `nslookup` or `ping` to activate that DNS resolution, they could simply use their browser to go to the hostname.One benefit of doing it that way is that I can also have the hostname resolve to that 10.31.33.7 IP that all the servers have an Apache listening on, mostly used for widget updates. I could setup a VirtualHost config on there so when people goto http://nots.cryptostorm.is/ they see a page telling them that TS is disabled now.I guess for widget users, it'd be easier since I could do the nslookup from there, so widget people only have to select the "Disable TrackerSmacker" option.

Anyways, I'll test out the LUA/pdns thing. If the performance hit is too much, I guess I'll bite the bullet and change all the configs to use via-file or script-security 3 so I can access the password.

I think this was mentioned back in the early days of TrackerSmacker being deployed - since the password credential isn't used as part of Cryptostorm's security model, why not use that as a field to pass switches to the exit node to activate/deactivate certain features?

[b]@df[/b]

I think this was mentioned back in the early days of TrackerSmacker being deployed - since the password credential isn't used as part of Cryptostorm's security model, why not use that as a field to pass switches to the exit node to activate/deactivate certain features?

This is due to the TrackerSmacker DNS-based anti-invasive/malicious ads/tracking that's running on about half of the DeepDNS servers.The ones that have TS enabled are using https://github.com/notracking/hosts-blocklistsIf a legitimate or popular enough site ends up in that list, we can add an exclusion if anyone needs it.

Here's a quick/messy one-liner that shows the current list of servers that have it enabled:

[root@b ~]# for x in `host public.deepdns.net|grep addr|awk '{print $NF}'`;do check=`host test.com $x 2>&1|grep " has "`;if [[ $check = *"0.0.0.0"* ]];then echo "$x has TS enabled"; else echo "$x does NOT have TS enabled";fi;done5.133.8.187 has TS enabled212.129.46.32 has TS enabled212.129.46.86 does NOT have TS enabled173.208.95.75 has TS enabled5.101.149.3 has TS enabled5.254.96.195 has TS enabled173.234.159.235 has TS enabled198.7.58.227 has TS enabled185.212.169.139 has TS enabled185.60.147.77 does NOT have TS enabled213.163.64.208 has TS enabled185.94.193.234 has TS enabled209.58.147.36 has TS enabled108.62.19.131 does NOT have TS enabled167.114.84.132 has TS enabled80.233.134.52 has TS enabled89.163.214.174 does NOT have TS enabled212.83.175.31 has TS enabled104.238.195.139 has TS enabled162.221.207.228 has TS enabled185.107.80.84 has TS enabled109.71.42.228 has TS enabled185.117.118.20 has TS enabled173.234.56.115 has TS enabled64.120.5.251 has TS enabled84.16.240.43 does NOT have TS enabled

One of these days I'll figure out a decent way to make TS optional on all servers, but I haven't figured out a reliable method yet.

This is due to the TrackerSmacker DNS-based anti-invasive/malicious ads/tracking that's running on about half of the DeepDNS servers.The ones that have TS enabled are using https://github.com/notracking/hosts-blocklistsIf a legitimate or popular enough site ends up in that list, we can add an exclusion if anyone needs it.

Here's a quick/messy one-liner that shows the current list of servers that have it enabled:

[root@b ~]# for x in `host public.deepdns.net|grep addr|awk '{print $NF}'`;do check=`host test.com $x 2>&1|grep " has "`;if [[ $check = *"0.0.0.0"* ]];then echo "$x has TS enabled"; else echo "$x does NOT have TS enabled";fi;done5.133.8.187 has TS enabled212.129.46.32 has TS enabled212.129.46.86 does NOT have TS enabled173.208.95.75 has TS enabled5.101.149.3 has TS enabled5.254.96.195 has TS enabled173.234.159.235 has TS enabled198.7.58.227 has TS enabled185.212.169.139 has TS enabled185.60.147.77 does NOT have TS enabled213.163.64.208 has TS enabled185.94.193.234 has TS enabled209.58.147.36 has TS enabled108.62.19.131 does NOT have TS enabled167.114.84.132 has TS enabled80.233.134.52 has TS enabled89.163.214.174 does NOT have TS enabled212.83.175.31 has TS enabled104.238.195.139 has TS enabled162.221.207.228 has TS enabled185.107.80.84 has TS enabled109.71.42.228 has TS enabled185.117.118.20 has TS enabled173.234.56.115 has TS enabled64.120.5.251 has TS enabled84.16.240.43 does NOT have TS enabled

One of these days I'll figure out a decent way to make TS optional on all servers, but I haven't figured out a reliable method yet.

I have noticed that certain exit nodes are guilty of not resolving domains that other exit nodes will happily resolve and return an IP address for, so I thought it would be a good idea to collate them in a single thread.

I have noticed that certain exit nodes are guilty of not resolving domains that other exit nodes will happily resolve and return an IP address for, so I thought it would be a good idea to collate them in a single thread.