VPN Client configuration problems

[NickA]

I have configured a VPN server and it shows up as running.

I have added port forwarding to my ipCOP firewall for UDP port 1194 to the Zentyal server.

I have looked at the certificates under Certification Authority and have downloaded the xxxCA and vpn-xxx ones, and have created one called VPNclient and downloaded that.

I am trying to configure a VPN client under VPN/Clients.   I have created a Client Configuration bundle under VPN Server, but when I try to Upload it under VPN Client, I get the error "This bundle is not a valid Zentyal-to-Zentyal configuration bundle. (Cannot unpack it)".

I have also tried to configure the VPN client and select the above 3 certificates, when I click on the Change button, I get the error "File supplied as CA's certificate is not valid".   I can't find any documentation that actually explains what the Client's certificate and Client's Private key are or how I generate them.

Any help would be appreciated.

[christian]

"Zentyal-to-Zentyal" 

What do you try to achieve ?
server to server tunnel or basic client access over VPN ?

[NickA]

Hi, I'm trying to set up basic client VPN access.

I tried downloading the client package an installing it on a Windows machine, but when trying to connect, I get the following log:

Mon Apr 22 16:32:19 2013 OpenVPN 2.2.0 Win32-MSVC++ [SSL] [LZO2] built on Apr 26 2011
Mon Apr 22 16:32:19 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Mon Apr 22 16:32:19 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Apr 22 16:32:19 2013 LZO compression initialized
Mon Apr 22 16:32:19 2013 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Apr 22 16:32:19 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Apr 22 16:32:19 2013 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Apr 22 16:32:19 2013 Local Options hash (VER=V4): 'd79ca330'
Mon Apr 22 16:32:19 2013 Expected Remote Options hash (VER=V4): 'f7df56b8'
Mon Apr 22 16:32:19 2013 UDPv4 link local: [undef]
Mon Apr 22 16:32:19 2013 UDPv4 link remote: x.x.x.x
Mon Apr 22 16:33:05 2013 SIGTERM received, sending exit notification to peer
Mon Apr 22 16:33:08 2013 TCP/UDP: Closing socket
Mon Apr 22 16:33:08 2013 SIGTERM[soft,exit-with-notification] received, process exiting
Mon Apr 22 16:33:09 2013 OpenVPN 2.2.0 Win32-MSVC++ [SSL] [LZO2] built on Apr 26 2011
Mon Apr 22 16:33:09 2013 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
Mon Apr 22 16:33:09 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Apr 22 16:33:10 2013 LZO compression initialized
Mon Apr 22 16:33:10 2013 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Apr 22 16:33:10 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Apr 22 16:33:10 2013 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Apr 22 16:33:10 2013 Local Options hash (VER=V4): 'd79ca330'
Mon Apr 22 16:33:10 2013 Expected Remote Options hash (VER=V4): 'f7df56b8'
Mon Apr 22 16:33:10 2013 UDPv4 link local: [undef]
Mon Apr 22 16:33:10 2013 UDPv4 link remote: x.x.x.x
Mon Apr 22 16:34:10 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Apr 22 16:34:10 2013 TLS Error: TLS handshake failed
Mon Apr 22 16:34:10 2013 TCP/UDP: Closing socket

[NickA]

But from your question, Christian, I'm guessing for basic VPN access I don't need to create a VPN client on the server ...

[NickA]

My problem seems to be a Firewall issue.

OpenVPN support says that the error "TLS Error: TLS key negotiation failed to occur within 60 seconds" is almost always caused by a firewall issue.

I have disabled the firewall on the Zentyal server because it sits in the green zone of an ipCop firewall.

I have created the rule: UDP DEFAULT IP : 1194 >> 192.x.x.x : 1194 (where 192.x.x.x is the ip address of the Zentyal server)

I have temporarily disabled the Windows firewall on the remote client machine trying to connect.

I'm still getting the TLS error.   Does anyone have any suggestions?

[Sam Graf]

A couple of things:

• Thank you for posting log information. I suggest editing out public IP addresses from the log.
• Is the ipCop firewall allowing traffic at port 1194?
• Correct, at the Zentyal end you need only a VPN server.

[NickA]

Whoops; good point about public ip address ...

Yep, I have opened up UDP port 1194 to be redirected to the Zentyal server.

[Sam Graf]

Since I'm not familiar with ipCop I don't know if forwarding port 1194 means that port 1194 (or any other necessary port) is open in the firewall or not. I've only used Zentyal VPN when Zentyal was the default gateway. To put it another way, I've never run into the kind of problem you describe except in the case where the firewall in the DSL modem was blocking traffic, so I'm suspicious of something similar happening in your case--though admittedly out of my ignorance of how ipCop blocks traffic.

Can you allow all traffic to Zentyal in the ipCop firewall long enough to determine if the the Windows VPN client can connect?

[christian]

I could be firewall issue but also other network related issue. As Zentyal is not your default gateway, you may need to implement some NAT.
You should also explain what your client package is made of. If using wrong certificate, you will face similar issue, as far as I understand.

[NickA]

Hi Christian,

could you explain what sort of NAT I would need?   I have ticked NAT in my VPN Server Configuration, and I am redirecting requests on UDP port 1194 to the ip address of the Zentyal server.

My client package has a client .pem file that I generated with the Certification Authority, a cacert.pem, a ABEEA778FDB.pem, which I understand is the client private key, and a .ovpn configuration file.

[NickA]

In response to Sam's suggesion; I reworked the network setup and removed the ipCop firewall machine.   The setup now is the Zentayal server with 2 physical interfaces, 192.168.1.4 set up as an external interface connected to an ADSL router.   The other interface, 192.168.0.1 connects to the LAN.   

I can now browse out from clients on the LAN; receive mail, ping google, etc, but nothing can get in.   

I can't connect in with the VPN client, I can't access a SimpleHelp server on the LAN, and I can't even ping the public ip address from outside.   

I have set up a port redirection on the Zentyal firewall to allow UDP port 1194 to be redirected to 192.168.0.1.   I have redirected the TCP port for SimpleHelp to point to the SimpleHelp server on 192.168.0.x   I have created an ICMP service and created a rule using this service through to 192.168.0.1.   The modem has also been configured to allow ICMP through.   I have enabled logging on the ICMP service and the SimpleHelp port redirection.

It's as though nothing is getting through to the firewall, because no logging occurs.   If I do  a TraceRT on the public ip address, it traces through to one of the service provider's ip addresses, but never hits my public ip address.

Does anyone have any ideas?   Any suggestions would be appreciated.

[christian]

Now that you have cleaner infrastructure design, you should try solving problems instead of implementing workaround.
What I mean to say is that if you read Zentyal documentation about VPN deployment, there is nowhere anything, as far as I know, suggesting that you should redirect port 1194 to Zentyal internal address. It even doesn't make sense or do I miss something ?

You're on the right track while checking if your external IP can be reached. However, do not rely on ping or traceroute only as ICMP can be blocked by your ISP.
What if you access your IP with web browser ?

Did you also ensure that your front-end router (I assume there is one) redirects incoming connections to Zentyal server ?

[NickA]

Hi Christian, I don't understand; I read the Zentyal VPN documentation and the example they give shows the server setup using UDP port 1194.   By default the firewall blocks this port, so without opening it up, how will an external client using port 1194 be able to get to the VPN server?

My problem is that I am on the application side, so networking and infrastructure is not my forte.   I am sure it is something fairly simple, and anyone familiar with setting this up would probably see the problem in a flash.   The modem has a few options; there is a checkbox for NAT; with this unchecked I get nothing though the modem; either in or out.   There is another option (that disables NAT) for PPP ip extensions.   This seems to be a bridge mode, where not routing or firewall functions are performed by the modem.   I tried this but got nothing in or out.   

What is puzzling me is that I thought leaving  the modem set up in exactly the same way as it was with the ipCOP firewall, which worked with SimpleHelp, and all external access would work with Zentyal swapped in as the firewall, but it doesn't.

[Sam Graf]

This VPN stuff can be terribly confusing. Being a pretty simple-minded person myself, I get confused by the layers that a lot of people have in their networks.

That said, let me try to clarify a couple of things. To do that I want to remove a layer that I understand you to have. I'll start at the perimeter and work in. I mentioned before that my DSL modem has a firewall, and to get VPN to work I had to disable the firewall (which is done per device in that modem). I didn't forward any ports (more on that in a second) but did disable the modem's firewall.

Now let's make our Zentyal server the default gateway (2 NICs) for the local LAN. And since this is also a VPN server, let's give it either a static public IP address or at least a static entry through a dynamic DNS service on the WAN interface. Assuming proper configuration of the WAN gateway (at the modem), our Zentyal server should be exposed to the public Internet. In particular, whatever port my VPN service ends up being available at is also exposed; no port forwarding required.

When the VPN service is set up by Zentyal, it takes care of its own firewall. The key entry is in the section where traffic to the Zentyal server is controlled. There won't be one in the place you might think there should be one--in the internal network section. Keeping in mind that Zentyal is the default gateway of the local LAN, Zentyal's internal magic takes care of all the stuff necessary for VPN to "just work." In the case of a "road warrior" VPN (which is just not the Zentyal-to-Zentyal option), you download the proper client bundle, install it on the client machine, and it should work.

This would be my scenario, where VPN actually does work. Does it make any sense to you?

[christian]

Let me try to explain.

VPN server is a service running on Zentyal server and listening on port 1194 UDP (default value).
This means that incoming connection, from internet, will reach this port on external interface. Thus there is not need to forward incoming connection to internal interface.
Of course, and your concern is somewhat correct here, you have to ensure that FW is configured to accept incoming connection on external interface but when you enable VPN service, Zentyal is supposed to do this on your behalf (otherwise this would be useless to use Zentyal compared to fully manual configuration isn't it ?  )

Now let's put it in perspective:
From internet to you LAN, you will have
- internet -> your ISP -> your public IP -> your external (edge) router -> external Zentyal IP -> Zentyal server -> VPN server -> internal Zentyal IP -> your LAN

above description might be however slightly different depending on how you configure your edge router.
- Either there is NAT and you public IP is on one side of the router while there is another segment between your router and Zentyal (external interface)
- or there is no routing (nor NAT) but gateway: your public IP is directly at your Zentyal external interface

Does it clarify the mater ?