Openvpn client AND server at the same time?

hal2100 · October 5, 2017, 9:10am

Hello,

I first set up TO to be a openvpn client, and it works great. I also did some routing to exclude certain IP ranges from going over the vpn.

Now I want to enable the openvpn server in the TO as well, to be able to connect to my LAN and use the same vpn connection the TO is using for the LAN.

When I set up the openvpn server through Foris, it only works if I disable the openvpn client first. With the client enabled at the same time, it does not work, because the external client connection is not established because the handshake fails due to a time out. I believe this is due to the fact that the response of the TO from the openvpn server is not send through the same route it came in, but the VPN the TO is connected to.

Things I tried:

Marking the openvpn packets (port 1194) and route them not through the vpn - Marking seems to work, I guess the routing also but the handshake is not completed.
Binding the openvpn server to a specific interface - Then I lost routing into my LAN

The problem is also described here, but I fail to “translate” the solution to my situation:
https://superuser.com/questions/1152318/policy-routing-for-openvpn-server-client-on-the-same-router

einar · October 5, 2017, 11:24am

You need to have two different configuration files listening on different ports (e.g. one on 1194 and one on 1195). I didn’t use Foris, but one of my two Omnias has 3 openVPN configurations (2 servers, 1 client) running.

hal2100 · October 5, 2017, 12:34pm

I do not understand.

The TO-client connects to the external VPN server on1194, but I am sure it does not start the connection from this port. I also get no error on the server start in the logs, so the 1194 port should not be in use on the TO.

As you managed to do it, could you share your config, so I can simply copy it? Do you have some special routing in place?

einar · October 5, 2017, 1:11pm

Here are the 3 different configurations:

server 1 (comments removed):

port 1194
proto tcp
dev tun0
topology subnet
ca /etc/openvpn/ca.crt
cert /etc/openvpn/cert.crt
key /etc/openvpn/cert.key  # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /tmp/openvpn/clients/ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 # This file is secret
comp-lzo
persist-key
persist-tun
verb 3
mute 20
# Internal routes for my network
push "route 192.168.10.0 255.255.255.0"
push "route 192.168.20.0 255.255.255.0"
client-to-client
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
status /var/log/openvpn-server-status.log

Server 2:

port 1196
proto tcp
dev tun2
ca /etc/openvpn/ca.crt
cert /etc/openvpn/cert2.crt
key /etc/openvpn/cert2.key  
dh /etc/openvpn/dh2048.pem
server 10.8.4.0 255.255.255.0
ifconfig-pool-persist /tmp/openvpn/clients/ipp-local.txt
# Internal routes for a client, you can leave out this one and the "route"
# statement that follow
client-config-dir ccd
route 192.168.20.0 255.255.255.0
client-to-client
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 
comp-lzo
persist-key
persist-tun
verb 3
mute 20
push "route 192.168.10.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"
mssfix
client-to-client
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
status /var/log/openvpn-server-2-status.log
topology subnet

Client:

client
dev tun
proto udp
remote my.remote.example.com 1195
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/external-ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
ns-cert-type server
tls-auth /etc/openvpn/ta-external.key 1
comp-lzo
verb 3
topology subnet
keepalive 10 60
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
status /var/log/openvpn-status.client.log

And the actual configuration for TO:

config openvpn 'custom_config'
         # Server 1
        option config '/etc/openvpn/server.conf'
        option enabled '1'

config openvpn 'remote_vpn'
        option config '/etc/openvpn/remote.conf'
        option enabled '1'

config openvpn 'local_service'
        # Server 2
        option config '/etc/openvpn/server-local.conf'
        option enabled '1'

Interfaces (there is one route for LAN-to-LAN not shown here):

config interface 'vpn0'
        option ifname 'tun0'
        option proto 'none'
        option auto '1'

config interface 'vpn1'
        option ifname 'tun1'
        option proto 'none'
        option auto '1'

config interface 'vpn2'
        option ifname 'tun2'
        option proto 'none'
        option auto '1'

Firewall:

config zone
        option input 'ACCEPT'
        option output 'ACCEPT'
        option name 'vpn'
        option masq '1'
        option network 'vpn0 vpn1 vpn2'
        option forward 'ACCEPT'

config forwarding
        option dest 'lan'
        option src 'vpn'

config rule
        option target 'ACCEPT'
        option proto 'tcp'
        option dest_port '1194'
        option name 'openvpn_inbound'
        option src '*'

# Server 2
config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'tcp udp'
        option dest_port '1196'
        option name 'OpenVPN extra

hal2100 · October 5, 2017, 6:13pm

Thank you very much!

I wonder if it is related to my client configuration (which comes from my 3rd party supplier), and not the server client config.

I’ll try it as soon as I have access to my TO again.

hal2100 · October 6, 2017, 5:39pm

Ok, I guess the routes pushed by my 3rd party vpn provider are the culprit.

Do you have the following also in your routing table after the external vpn is connected?

0.0.0.0/1 via ext.vpn.gw.ip dev tun0

This rule makes sure that everyting goes through the vpn, but it looks like this is also blocking the TO openvpn response.

A different question: which IP do you use to connect to your TO through openvpn? The IP given by your vpn provider or the external IP of your TO?

hal2100 · October 6, 2017, 6:54pm

I guess I “fixed” it.

I added a route from the wan_ip to the vpn exceptions. No the LAN clients are using the vpn and I can access the openvpn server. I just hope I did not tear up more security holes than I want to close.

einar · October 7, 2017, 7:04am

This rule makes sure that everyting goes through the vpn, but it looks like this is also blocking the TO openvpn response.

For various reasons I don’t route everything through the VPN. For me it’s meant as site-to-site (connecting two different LANs).

I use the IP of the TO (so to speak) to connect, or occasionally a SSH tunnel through an external machine I control in case port 1194 is blocked.