OpenVPN P2P not connecting

After wracking my brain for the entire day, I have not been able to figure out why the client cannot connect to the server is a Peer to Peer (Shared key) mode.

I followed this tutorial from the Opnsense documentation in addition to the Lawrence systems video on Site-2-Site VPN

I already have a working Road Warrior OpenVPN setup. I have both the opnsense boxes with me during set up. So I connected the client box to a port on my switch which is configured for a different VLAN. Since I am using a RFC1918 address as WAN IP for the client, I have also disabled the Block Private networks on the Server WAN interface. I disabled it on the client WAN interface as well just to be sure.

Here are my settings for the P2P:
Server:

Server Mode : Peer to Peer (Shared Key)
Protocol : UDP
Device Mode : tun
Interface : WAN
Local Port: 1195
Encryption algorithm: AES-256-CBC
Auth Digest Algorithm: SHA256
IPv4 Tunnel Network: 192.168.50.0/24
IPv4 Local Network : 192.168.1.0/24
IPv4 Remote Network: 192.168.3.0/24
Concurrent Connections: 3

Client:

Server Mode : Peer to Peer (Shared Key)
Protocol : UDP
Device Mode : tun
Interface: WAN
Remote Server: 
   Host: home.publicdomain.net             Port: 1195
Shared Key : (copied from the server)
Encryption Algorithm: AES-256-CBC
Auth Digest Algorithm: SHA256
IPv4 Tunnel Network: 192.168.50.0/24
IPv4 Remote Network: 192.168.1.0/24

Everything else is set to default.

on the Server, under Firewall–>Rules–>WAN, I opened port 1195

allow IPv4+6UDP      *     *    WAN address    1195    *     * 

Under Firewall–>Rules → OpenVPN – I already had the wide open rule created by the wizard (during my Road Warrior server setup)

On the Client, I created a wide open rule under Firewall–>Rules–>OpenVPN. I also assigned the ovpnc1 to an interface which created the relevant gateways. On the client the Outbound NAT is set to Automatic

However, whenever I initiate the connection, I see that the tunnel network is set on both the server and the client, but the dashboard keeps showing red for it. On the client, I checked the VPN–>Connection Status and it shows “waiting” for some time but on a retry it changes to “connecting” but never actually connects.

My log level is currently set to 3(recommended)

Here’s the client log:

2021-04-10T21:19:03	openvpn[8427]	Restart pause, 5 second(s)	 
2021-04-10T21:19:03	openvpn[8427]	SIGUSR1[soft,ping-restart] received, process restarting	 
2021-04-10T21:19:03	openvpn[8427]	Inactivity timeout (--ping-restart), restarting	 
2021-04-10T21:18:03	openvpn[8427]	UDP link remote: [AF_INET]84.xxx.xxx.xxx:1195	 
2021-04-10T21:18:03	openvpn[8427]	UDP link local (bound): [AF_INET]10.100.100.47:0	 
2021-04-10T21:18:03	openvpn[8427]	Socket Buffers: R=[42080->42080] S=[57344->57344]	 
2021-04-10T21:18:03	openvpn[8427]	TCP/UDP: Preserving recently used remote address: [AF_INET]84.xxx.xxx.xxx:1195	 
2021-04-10T21:18:03	openvpn[8427]	Preserving previous TUN/TAP instance: ovpnc1	 
2021-04-10T21:18:03	openvpn[8427]	Re-using pre-shared static key	 
2021-04-10T21:18:03	openvpn[8427]	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts	 
2021-04-10T21:17:58	openvpn[8427]	Restart pause, 5 second(s)	 
2021-04-10T21:17:58	openvpn[8427]	SIGUSR1[soft,ping-restart] received, process restarting	 
2021-04-10T21:17:58	openvpn[8427]	Inactivity timeout (--ping-restart), restarting	 
2021-04-10T21:16:57	openvpn[8427]	UDP link remote: [AF_INET]84.xxx.xxx.xxx:1195	 
2021-04-10T21:16:57	openvpn[8427]	UDP link local (bound): [AF_INET]10.100.100.47:0	 
2021-04-10T21:16:57	openvpn[8427]	Socket Buffers: R=[42080->42080] S=[57344->57344]	 
2021-04-10T21:16:57	openvpn[8427]	TCP/UDP: Preserving recently used remote address: [AF_INET]84.xxx.xxx.xxx:1195	 
2021-04-10T21:16:57	openvpn[8427]	Preserving previous TUN/TAP instance: ovpnc1	 
2021-04-10T21:16:57	openvpn[8427]	Re-using pre-shared static key	 
2021-04-10T21:16:57	openvpn[8427]	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2021-04-10T21:16:52	openvpn[8427]	Restart pause, 5 second(s)	 
2021-04-10T21:16:52	openvpn[8427]	SIGUSR1[soft,ping-restart] received, process restarting	 
2021-04-10T21:16:52	openvpn[8427]	Inactivity timeout (--ping-restart), restarting
2021-04-10T21:15:52	openvpn[8427]	UDP link remote: [AF_INET]84.xxx.xxx.xxx:1195	 
2021-04-10T21:15:52	openvpn[8427]	UDP link local (bound): [AF_INET]10.100.100.47:0	 
2021-04-10T21:15:52	openvpn[8427]	Socket Buffers: R=[42080->42080] S=[57344->57344]	 
2021-04-10T21:15:52	openvpn[8427]	Preserving previous TUN/TAP instance: ovpnc1	 
2021-04-10T21:15:52	openvpn[8427]	RESOLVE: Cannot resolve host address: home.publicdomain.net:1195 (Name does not resolve)	 
2021-04-10T21:15:31	openvpn[8427]	Re-using pre-shared static key	 
2021-04-10T21:15:31	openvpn[8427]	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts	 
2021-04-10T21:15:26	openvpn[8427]	Restart pause, 5 second(s)	 
2021-04-10T21:15:26	openvpn[8427]	SIGUSR1[soft,ping-restart] received, process restarting	 
2021-04-10T21:15:26	openvpn[8427]	Inactivity timeout (--ping-restart), restarting



2021-04-10T21:15:16	openvpn[8427]	MANAGEMENT: Client disconnected	 
2021-04-10T21:15:16	openvpn[8427]	MANAGEMENT: CMD 'state all'	 
2021-04-10T21:15:16	openvpn[8427]	MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock	 
2021-04-10T21:14:26	openvpn[8427]	UDP link remote: [AF_INET]84.xxx.xxx.xxx:1195	 
2021-04-10T21:14:26	openvpn[8427]	UDP link local (bound): [AF_INET]10.100.100.47:0	 
2021-04-10T21:14:26	openvpn[8427]	Socket Buffers: R=[42080->42080] S=[57344->57344]	 
2021-04-10T21:14:26	openvpn[8427]	TCP/UDP: Preserving recently used remote address: [AF_INET]84.xxx.xxx.xxx:1195	 
2021-04-10T21:14:26	openvpn[8427]	/sbin/route add -net 192.168.10 192.168.50.1 255.255.255.0	 
2021-04-10T21:14:24	openvpn[8427]	/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpnc1 1500 1572 192.168.50.2 192.168.50.1 init	 
2021-04-10T21:14:24	openvpn[8427]	/sbin/ifconfig ovpnc1 192.168.50.2 192.168.50.1 mtu 1500 netmask 255.255.255.255 up	 
2021-04-10T21:14:24	openvpn[8427]	TUN/TAP device /dev/tun1 opened	 
2021-04-10T21:14:24	openvpn[8427]	TUN/TAP device ovpnc1 exists previously, keep at program end	 
2021-04-10T21:14:24	openvpn[8427]	ROUTE_GATEWAY 10.100.100.1/255.255.255.0 IFACE=igb0 HWADDR=90:e2:3f:ee:fd:ad	 
2021-04-10T21:14:24	openvpn[8427]	Incoming Static Key Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication	 
2021-04-10T21:14:24	openvpn[8427]	Incoming Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key	 
2021-04-10T21:14:24	openvpn[8427]	Outgoing Static Key Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication	 
2021-04-10T21:14:24	openvpn[8427]	Outgoing Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key	 
2021-04-10T21:14:24	openvpn[8427]	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts	 
2021-04-10T21:14:24	openvpn[8427]	MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock	 
2021-04-10T21:14:24	openvpn[87354]	library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10
2021-04-10T21:14:24	openvpn[8427]	Incoming Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key	 
2021-04-10T21:14:24	openvpn[8427]	Outgoing Static Key Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication	 
2021-04-10T21:14:24	openvpn[8427]	Outgoing Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key	 
2021-04-10T21:14:24	openvpn[8427]	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts	 
2021-04-10T21:14:24	openvpn[8427]	MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock	 
2021-04-10T21:14:24	openvpn[87354]	library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10	 
2021-04-10T21:14:24	openvpn[87354]	OpenVPN 2.4.9 amd64-portbld-freebsd12.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jan 25 2021	 
2021-04-10T21:14:24	openvpn[87354]	disabling NCP mode (--ncp-disable) because not in P2MP client or server mode	 
2021-04-10T21:14:24	openvpn[22639]	SIGTERM[hard,init_instance] received, process exiting	 
2021-04-10T21:14:23	openvpn[22639]	/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown ovpnc1 0 0 192.168.50.2 192.168.50.1 init	 
2021-04-10T21:14:23	openvpn[22639]	Closing TUN/TAP interface	 
2021-04-10T21:14:23	openvpn[22639]	/sbin/route delete -net 192.168.10 192.168.50.1 255.255.255.0	 
2021-04-10T21:14:21	openvpn[22639]	MANAGEMENT: Client disconnected	 
2021-04-10T21:14:21	openvpn[22639]	MANAGEMENT: CMD 'state all'	 
2021-04-10T21:14:21	openvpn[22639]	MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock

10.100.100.0 is the WAN IP for my client opnsense box during testing…Once deployed, it will get it’s WAN from the ISP via DHCP. I have masked my public IP to 84.xxx and my public domain in the above log.

The gap in the log is until when the status is waiting…Then it seems to restart and then gets stuck in “connecting” status

and here’s the server log:

2021-04-10T10:49:03	openvpn[73113]	MANAGEMENT: Client connected from /var/etc/openvpn/server3.sock	
2021-04-10T10:48:01	openvpn[73113]	MANAGEMENT: Client disconnected	
2021-04-10T10:48:01	openvpn[73113]	MANAGEMENT: CMD 'quit'	
2021-04-10T10:48:00	openvpn[73113]	MANAGEMENT: CMD 'status 2'	
2021-04-10T10:48:00	openvpn[73113]	MANAGEMENT: Client connected from /var/etc/openvpn/server3.sock	
2021-04-10T10:46:58	openvpn[73113]	MANAGEMENT: Client disconnected	
2021-04-10T10:46:58	openvpn[73113]	MANAGEMENT: CMD 'quit'	
2021-04-10T10:46:58	openvpn[73113]	MANAGEMENT: CMD 'status 2'	
2021-04-10T10:46:58	openvpn[73113]	MANAGEMENT: Client connected from /var/etc/openvpn/server3.sock	
2021-04-10T10:45:56	openvpn[73113]	MANAGEMENT: Client disconnected	
2021-04-10T10:45:56	openvpn[73113]	MANAGEMENT: CMD 'quit'	
2021-04-10T10:45:56	openvpn[73113]	MANAGEMENT: CMD 'status 2'	
2021-04-10T10:45:56	openvpn[73113]	MANAGEMENT: Client connected from /var/etc/openvpn/server3.sock	
2021-04-10T10:44:54	openvpn[73113]	MANAGEMENT: Client disconnected	
2021-04-10T10:44:54	openvpn[73113]	MANAGEMENT: CMD 'quit'	
2021-04-10T10:44:54	openvpn[73113]	MANAGEMENT: CMD 'status 2'	
2021-04-10T10:44:53	openvpn[73113]	MANAGEMENT: Client connected from /var/etc/openvpn/server3.sock	
2021-04-10T10:43:51	openvpn[73113]	MANAGEMENT: Client disconnected	
2021-04-10T10:43:51	openvpn[73113]	MANAGEMENT: CMD 'quit'	
2021-04-10T10:43:51	openvpn[73113]	MANAGEMENT: CMD 'status 2'	

I did notice that the times don’t match but that’s because the client will eventually be in a different timezone and the firewall is set up with that timezone. Not much info in the server logs. I have more than 100 pages of the same thing.

I also increased the log level on both client and server, but have not found out why the connection is not established. Have I missed some configuration? Can you please help me setup this Peer-2-Peer VPN connection?

Thanks,
Inxsible

Morning,

Lets start with the basics.

Is this a live system and is the road warrior setup currently working and in use?
You have the WAN of the P2P Client on 10.100.100.?, what interface on the server does that connect via and what IP does that interface have?
Can you ping p2p client to server?

It kinda looks like you don’t have a route from the WAN on Client to the WAN on Server

1 Like

The server is my personal home firewall. The client is eventually going to be deployed at my parent’s house. The road warrior set up is functional — but not much in use as I work from home due to Covid. It’s not seen much use since a year or so. But I have verified that it is functional by connecting my phone (over LTE) to my road-warrior VPN server.

on the server, I have a VLAN number 100 on the interface called WORK (igb1_vlan100) which is what I am using as the WAN for the client during setup and testing. Eventually after deployment, the client will have the WAN from an ISP via DHCP. The interface IP is 10.100.100.1

From the client – I can ping 10.100.100.1 (which is the client WAN) but I cannot ping 192.168.1.1 (server side LAN)

This was the million dollar comment that helped me connect the dots.

I have a restricted WORK VLAN because I wanted my work machines to be completely isolated from my home network. For this I had added 2 block rules which blocked RFC1918 networks as the destination and had also blocked anything to the WAN address so that any machine on the WORK VLAN couldn’t directly connect to the WAN.

Disabling both those rules allowed me to connect the Peer-2-Peer VPN. It seems pretty straightforward in hindsight, but previously I was just looking at my VPN configuration to see if I had missed something not realizing that my situation was a bit different as I was testing it in a different scenario then all the videos/tutorials online.

Next thing to figure out is how to serve my DNS to the VPN clients, so that they don’t have to remember the IPs of the services that I provide – like bitwarden and nextcloud.

1 Like

Glad I managed to point you in the right direction.

There is an option in OpenVPN to push dhcp but for a site to site you probably just want to add the dns records to the remote pfSense box or tell that to issue your pfSense box as the dns server via dhcp.

1 Like

Thanks. I have tried a bunch of things as described in this thread but I am still unable to resolve the services on the VPN client side.
If you have any different pointers that could help, I hope you could add it to that thread.

Given that OpenVPN is pretty solid my guess is you have a config error.

You can easily try setting up a RAS on one side and a client on the other using certs instead of PSK, then see if it works.

OpenVPN is also a bit picky on the characters and length used in passwords, so you might also test with something basic/simple.

Not quite sure if you are talking about the connection or the DNS issue…The connection part works as I have noted a few posts above. I am trying to get the client side resolve the server side services using DNS instead of using the IP addresses.

Oh I see … Connection.

I think you need to implement NAT reflection or split-DNS for your scenario, I’ve not done it but the principle fits.

Not looked at the thread but if you use nslookup @ the IP of DNS server then do you get the correct answer?

Can you ping the DNS server when the VPN is connected.

Sorry for the delayed reply, but for nslookup 192.168.1.1 from a machine connected to the VPN client I get
server can't find 1.1.168.192.in.addr: REFUSED

when I ping, I do get the response back though. I guess it might be a firewall issue again, but I have a wide open rule on the OpenVpn tab under Firewall–>Rules–>OpenVpn on the server side

The VPNClientNetworks is just an alias of 2 networks which will connect to my VPN server. (192.168.3.0/24 & 192.168.70.1/24)

Do I need to open up port 53 on the server side WAN too ? Currently I only have the openVPN port open on the server side WAN.

I thought once the VPN connection is established, it would communicate over the vpn interface not via the WAN interface

Thanks.

if you run the following from cmd on a windows box;

nslookup qctech.co.uk

should get something like this back

C:\Users\GarethWestwood>nslookup qctech.co.uk
Server:  qct-pfsense02.internal.qctech.co.uk
Address:  172.16.100.1

Non-authoritative answer:
Name:    qctech.co.uk
Address:  3.10.30.47

Is the server and address in the first two lines showing the local DNS server or the one down the VPN? If it’s the local one then your VPN is not pushing the update to the client that tells it to use the DNS server from the VPN side, so that’s your first problem.

Then to check that DNS is getting through the VPN you could try (if 192.168.1.1 is the IP of your DNS server)

nslookup qctech.co.uk 192.168.1.1

If then try it with your actual domain you are trying to resolve not mine and see if you still get a result.

Unfortunatly I don’t know opensense so will struggle to point you in exactly the right direction but the above should at least let you work out if a/ your client is getting the correct DNS server set and b/ if the DNS packets are getting back and forward over the VPN