[SOLVED] PFSense 2.2.4 + OpenVPN 2.3.8: Can not create OpenVPN connection
-
Dear all,
No matter what I do, I can not establish OpenVPN connection to my newly installed PFSense Firewall. I always get the following errors:
Thu Sep 03 22:57:18 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 03 22:57:18 2015 TLS Error: TLS handshake failedVersion Info:
-
PFSense Version: 2.2.4
-
OpenVPN Version: 2.3.8
My small LAN topology is as follows:
-
I have a Modem/Router/4Port Switch which is as well a Default Gateway connected to internet
-
The PFSense appliance's WAN port is connected to this router and has fixed local IP address
-
I have another PC connected to the router simulating public PC and has fixed local IP address
-
I have one more PC connected to the firewall LAN port to simulate private PC and has dynamic IP address obtained from PFSense
My task is to establish OpenVPN connection between the "public" PC and the PFSense's WAN port. Unfortunately, no matter what I do and how many tutorials I follow, I always get error messages as shown below. It is interesting however that I have no problems establishing OpenVPN connection between the "private" PC and PFSense's LAN Port.
I have been trying this for over three days. I have read all the internet links, read documentation, followed Youtube tutorials and PFSense documentation. No matter what, I can not establish VPN to my firewall (PFSense 2.2.4). PFSense has no other firewall ruses set, only those which were automatically created using OpenVPN wizard. I have installed PFSense, made sure, I can get to internet from the "private" PC, and started configuring OpenVPN.
I have followed this PFSense Documentaiton as well, did exactly as recommended, but achieved no results: https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server
Would you be so kind, and take a look if if you find anything suspicious, please? Or, would you have any general advice, what I could check? Maybe I have to pre-configure PFSense for VPN connection, and set some rules?
Client Log Inormation:
Thu Sep 03 22:56:06 2015 OpenVPN 2.3.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 4 2015 Thu Sep 03 22:56:06 2015 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08 Enter Management Password: Thu Sep 03 22:56:18 2015 Control Channel Authentication: using 'pfSense-udp-1194-vpnuser-tls.key' as a OpenVPN static key file Thu Sep 03 22:56:18 2015 UDPv4 link local (bound): [undef] Thu Sep 03 22:56:18 2015 UDPv4 link remote: [AF_INET]192.168.178.10:1194 Thu Sep 03 22:57:18 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 03 22:57:18 2015 TLS Error: TLS handshake failed Thu Sep 03 22:57:18 2015 SIGUSR1[soft,tls-error] received, process restarting Thu Sep 03 22:57:20 2015 UDPv4 link local (bound): [undef] Thu Sep 03 22:57:20 2015 UDPv4 link remote: [AF_INET]192.168.178.10:1194 Thu Sep 03 22:58:20 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 03 22:58:20 2015 TLS Error: TLS handshake failed Thu Sep 03 22:58:20 2015 SIGUSR1[soft,tls-error] received, process restarting Thu Sep 03 22:58:22 2015 UDPv4 link local (bound): [undef] Thu Sep 03 22:58:22 2015 UDPv4 link remote: [AF_INET]192.168.178.10:1194 Thu Sep 03 22:59:22 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 03 22:59:22 2015 TLS Error: TLS handshake failed Thu Sep 03 22:59:22 2015 SIGUSR1[soft,tls-error] received, process restarting Thu Sep 03 22:59:24 2015 UDPv4 link local (bound): [undef] Thu Sep 03 22:59:24 2015 UDPv4 link remote: [AF_INET]192.168.178.10:1194 Thu Sep 03 23:00:25 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 03 23:00:25 2015 TLS Error: TLS handshake failed Thu Sep 03 23:00:25 2015 SIGUSR1[soft,tls-error] received, process restarting Thu Sep 03 23:00:27 2015 UDPv4 link local (bound): [undef] Thu Sep 03 23:00:27 2015 UDPv4 link remote: [AF_INET]192.168.178.10:1194 Thu Sep 03 23:01:27 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Thu Sep 03 23:01:27 2015 TLS Error: TLS handshake failed Thu Sep 03 23:01:27 2015 SIGUSR1[soft,tls-error] received, process restarting Thu Sep 03 23:01:29 2015 UDPv4 link local (bound): [undef] Thu Sep 03 23:01:29 2015 UDPv4 link remote: [AF_INET]192.168.178.10:1194.opvn File:
dev tun persist-tun persist-key cipher AES-256-CBC auth SHA1 tls-client client resolv-retry infinite remote 192.168.178.10 1194 udp lport 0 verify-x509-name "ExampleVPNServer" name auth-user-pass pkcs12 pfSense-udp-1194-vpnuser.p12 tls-auth pfSense-udp-1194-vpnuser-tls.key 1 ns-cert-type serverPlease, let me know if you need any further information. Thank you.
-
-
Well how and the hell are you going to connect from the internet with this IP?
UDPv4 link remote: [AF_INET]192.168.178.10:1194
That is a rfc1918 address.. not routable on the internet. IF you pfsense is behind a nat then you have to forward to pfsense wan IP on whatever that nat device is. And make sure your client actually uses your public IP.
-
Hi Johnpoz,
thank you so much for your answer. May I ask couple of more clarifications, please?
-
I am not sure if you have noticed, but I am testing everything behind an ISPs modem/router/switch. In other words, PFSense is connected to that ISPs modem/router/switch LAN port, and another laptop is connected to another modem/router/switch LAN port. This PC should simulate public PC as it is "outside PFSense". The current IP addresses are not meant to be final ones, and I do not expect to connect to them from Internet now. At this moment, I want to test VPN connection between the PC "outside" PFSense but still on my LAN and the PFSense's WAN port. The only difference I see are different IP address numbers, which will be changed later. Could you tell me, why this simulation would not work? Do I explicitly need to test the VPN from real external IP?
-
At this moment, I do not have convenient access to another PC on Public IP to do VPN tunnel tests. Is there a way, how to test OpenVPN on the LAN side of my modem/router?
Thank you.
-
-
Do a tcp dump on the pfsense wan port. Likely you haven't enabled allow private ip's on pfsense wan interface.
-
Hi Thermo,
this is it!! :-) One checkbox had made it all.
As my WAN has currently internal IP Address: 192.168.178/24, I needed to uncheck Block Private Networks option in WAN settings.
More specifically for those having the same problem, it is necessary to uncheck the following:
PFSense->Interfaces->WAN->Private networks->Block Private Networks.
Thank you so much. I have spent over three days by re-creating the VPNs, changing parameters, and repeating, but I have never came to these settings. Thank you!
-
if your wan currently has 172.16/16 wtf you trying to go to 192.168.178.10:1194 for?
-
Hi Johnpoz,
good question. I have made a mistake in the message above. My PFSense WAN has IP address from: 198.168.178/24. My PFSense LAN has 172.16/16. It is already corrected. Sorry for confusion. Thanks for your comment.
Regards.
-
you really need a /16 on your lan? So you have how many devices on this lan??
That is going to be really fun to try and vpn into when your at a place and they use anything in 172.16-31 on their end..
-
I will surely not connect 65534 devices into the LAN. :-) I did not see any disadvantages using B Class network. I can have maximum of 150 devices, but it could make my life easier when planning network address spaces, having still enough space for devices to grow.
What I do not like very much, if I have my network address spaces planned and say, I plan for 10 Printers. However, after couple of years, we need 11th one. This 11th printer does not fit anymore in the reserved address space, and I have to place it somewhere else.
Are there any disadvantages when using B class networks, please? It looks they are but I did not quite get the full meaning of your message:
"That is going to be really fun to try and vpn into when your at a place and they use anything in 172.16-31 on their end.."
Could you please explain a bit more? Thanks.
-
Yeah, the disadvantage is that you will not be able to connect from any place using the 172.16/12… Sigh.
-
so rfc1918 space is used EVERYWHERE.. So lets say your at starbucks on their wifi and you want to vpn into your network.. What is their local space 192.168.0/24? what if they are using 172.16.0/24 using such a large segment on your side begs for overlap. Say you have a device on 172.16.0.14 now your vpn client says well I have a locally connected network where that IP would be - why should I go down the tunnel to get to it.
You should use an uncommon rfc1918 on your local network say 192.168.14.0/24 - this is 254 addresses - that is hell of a lot of printers ;) Or use a /23 if you really want…
I am not suggesting you use a /28 if you have 14 devices.. But there has to be a more realistic mask vs the number of devices you have and 65K of them!!
Bad IP planning is why we ipv4 space is gone.. While doesn't matter all that much on a local network using rfc1918 space.. Its just the attitude sure lets use address space for 65K when I have 100 devices.. You would NEVER in a million years ever want to put that many devices on the same broadcast domain ever anyway. I would say a /24 or /23 a /22 would be a lot of devices broadcasting!! When you start to get a lot devices you have multiple segments. Say servers on 1, printer on another, end user devices on another, wifi on another.. You don't put everything on a /16..
-
Hi Johnpoz, Doktornotor,
thank you both for your explanation. It makes sense now. The source place from which I connect to my target network per VPN may not contain the source place IP Addresses. It really makes sense. I can dedo my design easily and i will gladly do it.
What would you say to 130.130.130/23 for my network, please? Does it look acceptable to you? Is the network small enough and unique enough fror a LAN?
Thank you. Kind regards,
-
So you have no clue to what rfc1918 space is then? 10.x.x.x/8 192.168.x.x/16 172.16.x.x/12
https://en.wikipedia.org/wiki/Private_network
That space is owned by
inetnum: 130.130.0.0 - 130.130.255.255
netname: UOWNET
descr: University of Wollongong
country: AUAre you them? Then don't use their space!! That is BAD BAD practice!!!! There is plenty of space to use in the private space - no reason to grab public space and use it on your network.. While technically it can be done - its BAD!!! and ever want to go to actual 130.130.130.x on the public internet your not going to get there.
Use something like 172.30.42.0/24 which is highly unlikely to be duplicated at some other site you might want to vpn from..
Common ones to avoid are 192.168.0/24 or 192.168.1/24 for 10.0.0/24 172.16.0/24 –- people like to grab the first subnets in a range 10.1.1/24 is common as well because its easy to type or 10.10.10/24
My main lan is 192.168.9/24 never seen it in use anywhere.. Then my other segments are .2,.3,.4 and .5 while .2 is common maybe even .3 I have multiple segments with some device I could bounce off of to get where I needed to go in my network in a worse case scenario where I was located was overlap one of my segments.
-
Hi Johnpoz,
I am getting really good information from you. Yes, to be honest, I was completely unaware of RFC1918 and about any regulation of what private address space should I use. I have many times wondered, why internal IP address spaces usually start with 172.16.x.x or 192.168.x.x, and why administrators are not a bit more creative. Now I understand.
So to move next step further, I would then go with: 172.20.20/23
This should be in accordance to what you and others told me. So I hope it will pass even your judgement. :-) However, if there is anything wrong with my slection, please, do not hesitate to tell me. :-) Thank you.
-
That would be fine - I personally think /23 is fairly large.. Do you have that many devices?
Keep in mind while 172.20.20/23 is valid private network 172.20.19/23 would not be since it doesn't fall on the border - that would be host in the 172.20.18/23 network.
It would behoove you to do a bit of reading on networking - if you have any questions on subnets, etc. PM me be happy to help.
/24 or 255.255.255.0 is very good border because it is human friendly to read very quickly what the network is and what the host when you get something like your 172.20.20.0 while that is a network 172.20.21.0 is a host if your mask is /23 and 172.20.20.255 is also a valid address with a /23 mask but would be broadcast address if /24
-
Hi Johnpoz,
thank you for this valuable information. To answer your question if I have so many devices, then no I don't. However, the reason why I have decided for /23 subnet mask bits is that I will have almost all the computers connected to this LAN to use Intel AMT. Intel AMT technology allows me to connect to all of them via KVM on hardware level. This is important because the LAN will be over 300 KM distant from me and I need to have good KVM connection.
Regarding the reserved address space, I plan the following:
-
The computers and other devices will use the range: 172.20.20.1 - 172.20.20.254
-
Intel AMT KVM IP addresses will use the range: 172.20.21.1 - 172.20.21.254
-
Device IP Address and its KVM IP Address will have identical last octets from their IP Addresses
An Example:
A server on this network will have its IP Address 172.20.20.1, while Intel AMT KVM IP Address to this device will be: 172.20.21.1.
This is my solution to having access to the devices transparent and easy to use. At this moment, it is for me hard to say, whether this transparency level overweights my /23 address space, but after evaluating what you've just told me, I think I will not do too much harm keeping this kind of address space. I would be happy to hear, what you think. Thank you.
Kind regards,
-
-
Why would you not put the KVM IP space on its own segment? so you have 172.20.20.0/24 for you devices and 172.20.21.0/24 for your KVM IPs
No it becomes very easy to control access into this KVM segment.
-
To answer the question why, well just for transparency reasons. Yes you are correct, I have 172.20.20.0/24 for my devices and 172.20.21.0/24 for your KVM IPs.
In other words, if I know that a device has IP Address: 172.20.20.10, then its KVM must be 172.20.21.10. I do not need any further table, and know the KVM address out of my head.
-
Well if you have 2 /24 why are you thinking you need to use a /23??
-
Well if you have 2 /24 why are you thinking you need to use a /23??
Well with my limited knowledge I think that I establish VPN network from my remote network to the target network. It means I have to define my destination network into when configuring OpenVPN.
If I enter 172.20.20.0/24 as my destination network (IPv4 Local Network in OpenVPN Tunnel Settings) I will be able to reach the devices but not their KVM IP addresses accessed through 172.20.21.0/24.
If I enter 172.20.21.0/24 as my destination network (IPv4 Local Network in OpenVPN Tunnel Settings) I will be able to reach KVMs but not the devices themselves accessed through 172.20.20.0/24.Maybe that is completely incorrect, but it is how I see it now. Entering 172.20.20.0/23 will allow me to access both, the devices and their KVMs.
-
2 /24 networks is a better solution. What would you do if you wanted to allow someone access to the desktop network but not the kvm network?
You can add additional network routes in the openvpn additional options section.
-
Hi Thermo,
thank you very much for your comment. Knowing how to access two networks will definitely be good think to know, and yes, as you said, 2 /24 networks may be a better solution. I will take a look at this. Thank you.
-
so you put in multiple networks as your local, or just route /23 even though you have /24 you could just route 172.16/12 if you wanted too..
-
Hi Johnpoz, Thermo,
I have redone that, as you recommended. As part of my learning process it was great exercise:
-
IPv4 Tunnel NEtwork: 192.168.188.0/24
-
IPv4 Local Networks: 192.168.168.0/24, 192.168.169.0/24
That is correct, that I will have a bit more flexibility now to grant access to only one network if needed. Thank you.
-
