OPNsense Forum
Archive => 18.7 Legacy Series => Topic started by: Fatmouse69 on October 17, 2018, 10:20:47 am
-
Hi,
I am trying to configure OpenVPN on my OPNsense (v18.7.5) following this guideline: https://wiki.opnsense.org/manual/how-tos/sslvpn_client.html.
(Btw.: I am aware of the upcoming updates on this documentation. See: https://github.com/opnsense/docs/issues/23). But independently of this, OpenVPN should work.
My problem is, that my client (MacOS 10.14) is not able to connect.
The test-setup is as follows:
- Server WAN address: 192.168.2.146/24
- Client IP address: 192.168.2.71
- I disabled 'Block private networks' on WAN
- OpenVPN is configured to listen on port 11944
- IPv4 tunnel network is 10.0.0.0/24
- WAN interface allows IPv4 UDP for the WAN address and port 11944
- OpenVPN interface allows IPv4 from 10.0.0.0/24 to LAN net (also tried with any...)
When I am trying to connect I get the following output:
2018-10-17 10:03:42 *Tunnelblick: Established communication with OpenVPN
2018-10-17 10:03:42 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:63256
2018-10-17 10:03:42 MANAGEMENT: CMD 'pid'
2018-10-17 10:03:42 MANAGEMENT: CMD 'auth-retry interact'
2018-10-17 10:03:42 MANAGEMENT: CMD 'state on'
2018-10-17 10:03:42 MANAGEMENT: CMD 'state'
2018-10-17 10:03:42 MANAGEMENT: CMD 'bytecount 1'
2018-10-17 10:03:42 MANAGEMENT: CMD 'hold release'
2018-10-17 10:03:55 MANAGEMENT: CMD 'username "Auth" "136"'
2018-10-17 10:03:55 MANAGEMENT: CMD 'password [...]'
2018-10-17 10:03:55 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2018-10-17 10:03:55 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2018-10-17 10:03:55 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2018-10-17 10:03:55 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.2.146:11944
2018-10-17 10:03:55 Socket Buffers: R=[786896->786896] S=[9216->9216]
2018-10-17 10:03:55 UDP link local (bound): [AF_INET][undef]:0
2018-10-17 10:03:55 UDP link remote: [AF_INET]192.168.2.146:11944
2018-10-17 10:03:55 MANAGEMENT: >STATE:1539763435,WAIT,,,,,,
2018-10-17 10:04:55 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2018-10-17 10:04:55 TLS Error: TLS handshake failed
2018-10-17 10:04:55 SIGUSR1[soft,tls-error] received, process restarting
2018-10-17 10:04:55 MANAGEMENT: >STATE:1539763495,RECONNECTING,tls-error,,,,,
2018-10-17 10:04:55 MANAGEMENT: CMD 'hold release'
I already checked that the WAN interface receives UDP traffic on port 11944.
Currently, I do not have a clue, what the problem is and why the TLS handshake fails. I also tried a complete fresh installation.
My problems seems similar to this one: https://forum.opnsense.org/index.php?topic=7675.0. But also changing from UDP to TCP is not changing anything.
Thank you for any hint.
Greetings, David
PS: if any further information is needed, I will provide it of course.
UPDATE:
I read from several sites, that testing the VPN functionality from the same network is not recommended/often not working. I am in the same situation, as my client lies in the same network (192.168.2.0/24).
UPDATE 2:
When I am moving the OpenVPN server from WAN to LAN interface the client connects successfully. In the German forum a very similar topic is currently discussed: https://forum.opnsense.org/index.php?topic=9932.0.
-
Why does you WAN-IP have a class C network? Is this a internal firewall?
Have you given the certificate from the firewall to the client? There is a TLS-error within your protocol. I've installed in on Fedora 29 (Linux), this had to be done manually, there i had to indicate the proper certificate.
-
Why does you WAN-IP have a class C network? Is this a internal firewall?
Have you given the certificate from the firewall to the client? There is a TLS-error within your protocol. I've installed in on Fedora 29 (Linux), this had to be done manually, there i had to indicate the proper certificate.
Hi ruggerio, thanks for your answer.
Currently, I am testing the whole setup internally and therefore used the class C IP address. Tomorrow, I will carry the hardware to its deployment location and there the firewall also will get its public IP address.
I have not given the VPN server certificate to my client explicitely. I extracted the configuration as an archive from the Client export section of OpenVPN and imported it in my VPN software on the MacOS client (Tunnelblick). I thought this would include all necessary certificate stuff, especially because the archive also includes a PKCS12 container which contains the client certificate and the OpenVPN server certificate.
-
I've imported single file profiles into Tunnelblick where the CA cert, client cert, key, and TLS key are all inline with tags like <ca> base64 lines </ca>
Bart...
-
I've imported single file profiles into Tunnelblick where the CA cert, client cert, key, and TLS key are all inline with tags like <ca> base64 lines </ca>
Bart...
Hey Bart, how did you manage receiving such a single file? When selecting "File only" in the Client Export section of OpenVPN, I'll receive the .ovpn configration file - without any certs/keys.
-
VPN, OpenVPN, Client Export. Pick your remote access VPN and drop down the appropriate user. Under 'Inline Configurations' pick 'OpenVPN Connect (iOS/Android)' and download it to your Mac.
Open the file with a text editor and add 'dev tun' (assuming you're using tun) on a line by itself, like so:
dev tun
persist-tun
persist-key
<rest of config>
Right-click, open with Tunnelblick and put your Mac and OPNsense user credentials in the appropriate fields.
Bart...
-
@bartjsmit: thanks for pointing this out.
Today I tested the productive setup and at least the VPN connection establishment worked fine. :)
So it seems that the problem existed because I was testing this with a private WAN IP. Nevertheless, I do not know why...
Unfortunately, I stumbled across another problem which seems to be an erroneous firewall rule configuration: my VPN client (10.0.0.0/24), as well as clients in the local network (192.168.0.0/24) at the deployment location can't access the Internet. All they are possible to do is access everything in the local network including the WAN IP. But any access beyond this is not possible.
My firewall rules are attached and named accordingly.
I am pretty certain that I have made a mistake regarding the rules.
Thank you for any help.
Best regards, David
-
Hi David,
If you can ping your WAN IP but not beyond, then there is likely to be a routing issue. Make sure that the route to and from the internet edge router is either by default gateway, static route, or some form of dynamic routing protocol.
Bart...
-
Hi David,
If you can ping your WAN IP but not beyond, then there is likely to be a routing issue. Make sure that the route to and from the internet edge router is either by default gateway, static route, or some form of dynamic routing protocol.
Bart...
Good morning,
sorry for the confusion, but I tested it right now and must confess that I am not able to ping the WAN IP address of my OPNsense by a VPN client.
Regarding the routing topic: shouldn't it be enough to set my IPv4 Tunnel Network to 10.0.0.0/24 and my IPv4 Local Network to 192.168.0.0/24? I thought this would result in proper routes for my VPN clients?
Btw I've enabled Gateway redirect because I want all traffic from the client sent through the VPN. So the Local Network option is hidden.
My current routes at the VPN client are as follows:
route add -net <WAN_IP> 192.168.2.1 255.255.255.255
route add -net 0.0.0.0 10.0.0.5 128.0.0.0
route add -net 128.0.0.0 10.0.0.5 128.0.0.0
route add -net 192.168.8.0 10.0.0.5 255.255.255.0
route add -net 10.0.0.1 10.0.0.5 255.255.255.255
With this I am only able to ping the VPN tunnel GW (10.0.0.1) and the LAN interface of my OPNsense. But not any further external IPs.
Kind regards, David
-
Hi David,
OPNsense is fine as far as routing is concerned since it has interfaces on 10.0.0.0/24 and 192.168.0.0/24. Can you check for updates from the web interface dashboard? If so, then OPNsense has internet access.
Do you have a router further upstream, or does OPNsense have a public (non-RFC1918) WAN IP address?
Bart...
-
Hi David,
OPNsense is fine as far as routing is concerned since it has interfaces on 10.0.0.0/24 and 192.168.0.0/24. Can you check for updates from the web interface dashboard? If so, then OPNsense has internet access.
Do you have a router further upstream, or does OPNsense have a public (non-RFC1918) WAN IP address?
Bart...
Hi Bart,
OPNsense itself has internet access: I can ping hosts, check for updates and make nslookups for example.
I have a further router in front of the OPNsense - a FRITZ!Box 6490 Cable from my ISP (Unitymedia) which instructs me to set the public (non-RFC1918) IP address as manual IPv4 WAN address to make OPNsense directly accessible from the Internet. Furthermore, to avoid any interfering of the FB I set my OPNsense as exposed host, which results in an deactivated firewall of the FB regarding the OPNsense.
Kind regards (and ty for answering me on sunday), David
-
Hi David,
Are you redirecting the gateway on the VPN clients? It's under 'tunnel settings' on the VPN server page.
Try taking out the source restriction in the VPN firewall rule (replace 10.0.0.0/24 with *). The client may not use the VPN address as its source IP.
If nothing improves, it's worth running a packet capture on the OpenVPN interface to further analyse the traffic.
Bart...
-
Good morning,
Are you redirecting the gateway on the VPN clients? It's under 'tunnel settings' on the VPN server page.
Yes, as I wrote above, I enabled this option.
Try taking out the source restriction in the VPN firewall rule (replace 10.0.0.0/24 with *). The client may not use the VPN address as its source IP.
I already generalized this and other restrictions in the firewall rules to avoid any interfering.
If nothing improves, it's worth running a packet capture on the OpenVPN interface to further analyse the traffic.
I am with you. Let's see if this will bring me some more insight.
All the best, David
-
So I finally found my solution :D
First of all, thank you Bart for your patient support.
I couldn't get it working until I set a manual NAT rule for my WAN interface which masked everything going out. Can anybody tell me, why this is necessary? Before the deployment of my OPNsense it was setup in a lab environment and clients did have internet access without this NAT rule. Now I need it for both, LAN and VPN connected clients to access the internet.
Best regards, David