Seu servidor 172.20.24.1 está redirecionando seu gateway padrão do cliente e, portanto, seu cliente tenta rotear tudo pela VPN, o que significa que você não pode se conectar a nenhum serviço até que seu servidor saiba onde eles estão.
Eu configurei recentemente um cliente OpenVPN no meu HTPC, no entanto, uma vez conectado ao servidor VPN, eu não conseguia mais conectar remotamente o SSH ou conectar-me aos outros servidores que eu estava executando no HTPC.
Eu segui o conselho dado aqui e aqui sobre como encaminhar adequadamente o tráfego de entrada e conseguiu se conectar por meio do SSH novamente. Estes são os resultados,
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.20.24.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
128.0.0.0 172.20.24.1 128.0.0.0 UG 0 0 0 tun0
172.20.24.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
198.144.158.43 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0
$ ip route show
0.0.0.0/1 via 172.20.24.1 dev tun0
default via 192.168.0.1 dev eth0 proto static
128.0.0.0/1 via 172.20.24.1 dev tun0
172.20.24.0/22 dev tun0 proto kernel scope link src 172.20.24.240
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.100 metric 1
198.144.158.43 via 192.168.0.1 dev eth0
Infelizmente, ainda não consigo me conectar ao meu servidor TeamSpeak3, que usa uma conexão UDP junto com o TCP. Como o TCP está funcionando bem, presumo que haja algo que esteja faltando para que o UDP funcione.
EDIT: O endereço IP é 192.168.0.100, na sub-rede 192.168.0.0/24 e 192.168.0.1 para o servidor TS3. Estou me conectando a um servidor VPN IPVanish através do cliente OpenVPN no Ubuntu.
Seu servidor 172.20.24.1 está redirecionando seu gateway padrão do cliente e, portanto, seu cliente tenta rotear tudo pela VPN, o que significa que você não pode se conectar a nenhum serviço até que seu servidor saiba onde eles estão.