Linux How to setup Oeck in pfSense

[Wayne]

As a pfSense Newbie, I am seeking advice on how to setup Oeck in pfSense Qotom Q355G4.

 

[Wayne]

I now have two other VPN services running fine in the pfSense, plus another which was running fine until I broke it, all I need is a few ideas on how to get Oeck up and running. I will need an address for the server to start with. I tried using 103.18.84.72 to kick the show off from Sydney, but so far no luck in having Oeck to connect. Any helpful advice gratefully received.

 

[Cameron]

Hi Wayne,

I have not set up pfSense, but if you already have 2 services running then I would imagine that you only need the info that is in the .ovpn files. You can download one from here. Make sure you keep obfuscation turned off.


Regards,
Cameron @ Oeck

 

[Wayne]

Hi Cameron, thanks for the response. I have interrogated the Sydney .UDP .ovpn file and grabbed some data from therein. The addressing appears to be an issue, I have tried a couple from the .ovpn file however no joy so far, I need a functional IP address to point the VPN client to. Attached screenshot demonstrates.

 

[Cameron]

Hi Wayne,

Do you have a log from an attempted connection?

Regards,
Cameron @ Oeck

 

[Wayne]

Hi Cameron,

Log attached. I subscribe to (now) 4 VPN services which should show up in the log. Should I reboot the pfSense box, 3 of the VPN's appear to be connected whilst Oeck is not. I have experimented by turning off all the VPN's services and then activate only Oeck.VPN client, however no luck connecting Oeck.

 

[Cameron]

Hi Wayne,

Is that the whole log? I can't see any entries relating to Oeck. There's only about 50 lines.

Cameron

 

[Wayne]

This is what is reported in the log when I attempt a start of Oeck.VPN client. Clearly, I have more work to do in the structure of the setup for the VPN clients.

Aug 13 04:14:40	php-fpm	342	/status_services.php: The command '/usr/local/sbin/openvpn --config '/var/etc/openvpn/client2.conf'' returned exit code '1', the output was ''
Aug 13 04:14:40	php-fpm	342	OpenVPN failed to start
Aug 13 04:14:40	check_reload_status		Reloading filter

 

[Cameron]

So, what does your "/var/etc/openvpn/client2.conf" look like?

 

[Cameron]

As an aside, we have a couple of people on here using untangle instead of pfSense on qotom.
Might be worth checking out.

Linux - How to setup Oeck on Untangle

How to setup Oeck(OpenVPN) on Untangle. Untangle is a router solution based on Linux Debian, it is very easy to use once setup, the solution itself is mostly free but the part that costs money is their premium filtering apps which shouldn't interest you unless you want to view any and all...

www.oeck.com

 

[Wayne]

So, what does your "/var/etc/openvpn/client2.conf" look like?

Attached for information.

 

[Wayne]

As an aside, we have a couple of people on here using untangle instead of pfSense on qotom.
Might be worth checking out.

Linux - How to setup Oeck on Untangle

How to setup Oeck(OpenVPN) on Untangle. Untangle is a router solution based on Linux Debian, it is very easy to use once setup, the solution itself is mostly free but the part that costs money is their premium filtering apps which shouldn't interest you unless you want to view any and all...

www.oeck.com

Thanks, however, I have my hands full at the moment with pfSense and the Qotom box. Once I have that sorted, then perhaps time to look further afield.

Cheers,

Wayne

 

[Cameron]

So I have a few things I can see-

• auth-user-pass doesn't need a file parameter after it
• seems to be 4 different dev lines (maybe a pfsense thing)
• key-direction is for an inline tls cert, not a file
• a few lines are in multiple times - maybe ok, not sure but worth cleaning up
• protocol is specified twice - proto udp4 and on the remote line. openvpn manual doesn't list udp4 as an option under proto.
• ncp-ciphers is not used on the server end, may be a problem listing ncp in client end

Some of these things may be due to the pfSense implementation of openvpn. I've never set up a pfSense device.

Regards,
Cameron @ Oeck

 

[Wayne]

So I have a few things I can see-

• auth-user-pass doesn't need a file parameter after it
• seems to be 4 different dev lines (maybe a pfsense thing)
• key-direction is for an inline tls cert, not a file
• a few lines are in multiple times - maybe ok, not sure but worth cleaning up
• protocol is specified twice - proto udp4 and on the remote line. openvpn manual doesn't list udp4 as an option under proto.
• ncp-ciphers is not used on the server end, may be a problem listing ncp in client end

Some of these things may be due to the pfSense implementation of openvpn. I've never set up a pfSense device.

Regards,
Cameron @ Oeck

Thanks Cameron,

Seems there are issues, plenty to keep me busy for a while it seems. This is my first experience with pfSense and will need working thorough. I have been researching online which has got me this far, with some progress to show.

Cheers,

Wayne

 

[Cameron]

Seems like you are having fun with it anyway.
I'll help if I can.

Cameron.

 

[Wayne]

Seems like you are having fun with it anyway.
I'll help if I can.

Cameron.

Thanks Cameron,

Fun sometimes, frustrating other times. I will get there, along with a little help from others.

Cheers,

Wayne

 

[Wayne]

Seems like you are having fun with it anyway.
I'll help if I can.

Cameron.

OK Cameron,

I now have three of my four VPN services working in the pfSense. VPN.AC, NordVPN, SurfSharkVPN, leaving OeckVPN not yet connecting.

At this stage, I believe I require a server host or address plus a server port before I may progress with Oeck. The one's I have taken from the .ovpn file are not cutting the mustard for me.

Any clues here?

Cheers,

Wayne

 

[Cameron]

Hi Wayne,

The one in your conf file should be OK, but if you want to try a different one, you can use 103.18.84.81, port 1194.
The port will depend on the type of connection and encryption:
1194 - UDP - AES-256-GCM
1196 - UDP - AES-128-CBC
443 - TCP - AES-256-GCM
445 - TCP - AES-128-CBC


Cameron.

 

[Wayne]

Hi Wayne,

The one in your conf file should be OK, but if you want to try a different one, you can use 103.18.84.81, port 1194.
The port will depend on the type of connection and encryption:
1194 - UDP - AES-256-GCM
1196 - UDP - AES-128-CBC
443 - TCP - AES-256-GCM
445 - TCP - AES-128-CBC


Cameron.

OK, that helps, I will try them out and see how it turns out.

Ummm what about these Custom Options, are they correct?

client
dev tun
auth-user-pass
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
key-direction 1
verb 3
dhcp-option DOMAIN-ROUTE .

cheers

Wayne

 

[Cameron]

I'll do my best - without knowing if any are pfsense specific:

client - yes
dev tun - yes (depending on other pfsense options
auth-user-pass - yes, although pfsense might use a file specified here (I didnt find that before)
resolv-retry infinite - not necessary
nobind - cannot be used together with lport, otherwise yes
persist-key - depends on privileges in pfsense, probably yes
persist-tun - - depends on privileges in pfsense, probably yes
remote-cert-tls server - yes
key-direction 1 - no, clashes with tls-auth
verb 3 - yes
dhcp-option DOMAIN-ROUTE . - not necessary

 

[Wayne]

I'll do my best - without knowing if any are pfsense specific:

client - yes
dev tun - yes (depending on other pfsense options
auth-user-pass - yes, although pfsense might use a file specified here (I didnt find that before)
resolv-retry infinite - not necessary
nobind - cannot be used together with lport, otherwise yes
persist-key - depends on privileges in pfsense, probably yes
persist-tun - - depends on privileges in pfsense, probably yes
remote-cert-tls server - yes
key-direction 1 - no, clashes with tls-auth
verb 3 - yes
dhcp-option DOMAIN-ROUTE . - not necessary

Thanks Cameron,

I made these adjustments in the client file accordingly.

Now for a day of trial and testing.

First attempt = Oeck failed to start.

Aug 13 21:56:11	check_reload_status		Reloading filter
Aug 13 21:58:26	php-fpm	60266	/status_services.php: The command '/usr/local/sbin/openvpn --config '/var/etc/openvpn/client2.conf'' returned exit code '1', the output was ''
Aug 13 21:58:26	php-fpm	60266	OpenVPN failed to start
Aug 13 21:58:26	check_reload_status		Reloading filter

Cheers,


Wayne

 

[Cameron]

Hi Wayne,

I think it would be helpful to find the openvpn log. That one seems to be an overall system log.

Cameron.

 

[Wayne]

Hi Wayne,

I think it would be helpful to find the openvpn log. That one seems to be an overall system log.

Cameron.

It would help I am sure, took a little searching, but here it is.

Plus a screenshot immediately after a reboot of the pfSense. Once settled from the reboot, I shut down two of the three activated VPN services, leaving one operational whilst Oeck sits idle.

Cheers,

Wayne

 

[Cameron]

Hi Wayne,

I can't find anything in the log related to either client2 or Oeck.
Looks like it has a problem before openvpn does anything.
Could this be a file permission problem?
Or something in pfSense that is controlling which client files to open?

Cameron

 

[Wayne]

Hi Wayne,

I can't find anything in the log related to either client2 or Oeck.
Looks like it has a problem before openvpn does anything.
Could this be a file permission problem?
Or something in pfSense that is controlling which client files to open?

Cameron

Hi Cameron,

Yeah, something isn't right here for sure. I am now going through the Oeck VPN client setup in pfSense step by step, if I cannot find the issue, I intend to delete all the Oeck pfSense files and start from scratch in pfSense setting up Oeck again.

What gives me heart is the fact the other three VPN client services are working fine, thus there is a 'key' to Oeck in here somewhere, which needs finding.

Cheers,

Wayne

 

[Wayne]

Hi Cameron,

I have made a little progress, changes to the Custom Settings seemed to have assisted, also changing the Server Host back to the file name seems to have an impact too. At the moment, the issue seems to be revolving around these two things, however, I suspect there is another issue hiding away which I have not yet located.

 

[Wayne]

This would not attach to the previous message, so I zipped it and voila!

Showing a slight change of status for Oeck.VPN in the pfSense.

 

[Wayne]

Hi Cameron,

I forgot to include the changed Custom Settings.
remote-random
resolv-retry infinite
pull-filter ignore ifconfig-ipv6
pull-filter ignore route-ivp6
remote-cert-tls server
dhcp-option DOMAIN-ROUTE .
tun-mtu 32000
fragment 0
mssfix 0
explicit-exit-notify 1

I copy these from my ASUS router Oeck.VPN client settings within to see if it helps.

Cheers,

Wayne

 

[Wayne]

Hi Cameron,

Update.

If I put an actual Oeck IP address into Oeck VPN client file, I get a 'down' message in the connection status.

Should I remove the IP address and put in the OpenVPN file name (linux-Sydney-udp-256), I get this message 'reconnecting; init_instance' in the connection status, which is indicating to me, this could be where the issue resides.

Oh well, enough for today. Tomorrow should bring new ideas.

Cheers,

Wayne

 

[PetSue]

Boy I'm glad I went with Untangle after having a look first at pfSense on my Qotom.

 

[Cameron]

Hi Wayne,

So it might be changing the message, but you can't use linux-Sydney-udp-256 as the remote hostname.
Also you can't use 103.18.84.166.
The only ones you can use are listed in the .ovpn file:
103.18.84.72
103.18.84.73
103.18.84.74
103.18.84.75
103.18.84.76
103.18.84.77
103.18.84.78
103.18.84.80
103.18.84.81
103.18.84.82
103.18.84.83
103.18.84.84
103.18.84.85
103.18.84.86

They are the only ip addresses with openvpn servers running on them.
Also, none of those IP's have DNS entries. The IP is the only way to connect.

Hope this helps a bit.

Cameron.

 

[Wayne]

Hi Wayne,

So it might be changing the message, but you can't use linux-Sydney-udp-256 as the remote hostname.
Also you can't use 103.18.84.166.
The only ones you can use are listed in the .ovpn file:
103.18.84.72
103.18.84.73
103.18.84.74
103.18.84.75
103.18.84.76
103.18.84.77
103.18.84.78
103.18.84.80
103.18.84.81
103.18.84.82
103.18.84.83
103.18.84.84
103.18.84.85
103.18.84.86

They are the only ip addresses with openvpn servers running on them.
Also, none of those IP's have DNS entries. The IP is the only way to connect.

Hope this helps a bit.

Cameron.

Hi Cameron,

Thanks for that, I have put it to use.

I have made some advances, however the current issue appears to be linked to credentials as the attempt to connect to Oeck is rejected according to the log.

Log attached for info/comment.

Regards,


Wayne

 

[Cameron]

So far - that log looks OK.
Is that the whole log? It looks a little light.

Cameron.

 

[Wayne]

So far - that log looks OK.
Is that the whole log? It looks a little light.

Cameron.

Hi Cameron,

Yep, that is the whole log, the logs are set to 50 lines. I can increase this if required.

I have pretty much exhausted my options with this setup and if no luck later this evening/tomorrow, then I will need to consider a factory reset of the Qotom pfSense box and start clean.

What is curious, is the fact the other three VPN services I play around with, all installed, all work fine, why is it so?

Cheers,

Wayne

 

[Cameron]

I think the key will be somewhere in the log. If it's not connecting, the openvpn log should tell us why.
At the moment the log you have seems to be only the beginning of the process, which looks Ok.
The next steps should see it checking certificates and authenticating.

I can't tell from the log whether it is going through the whole connection process and not telling us about it, or not doing it at all.

Cameron.

 

[Wayne]

I think the key will be somewhere in the log. If it's not connecting, the openvpn log should tell us why.
At the moment the log you have seems to be only the beginning of the process, which looks Ok.
The next steps should see it checking certificates and authenticating.

I can't tell from the log whether it is going through the whole connection process and not telling us about it, or not doing it at all.

Cameron.

Hi Cameron,

I note, when Oeck attempts to connect, it disconnects with no revealing log entries whilst, when I connect a working VPN, the log is verbose in comparison. I have gone through other logs to see if there is a clue, nothing yet.

Maybe my connection is being immediately rejected by Oeck for some reason. I have checked and rechecked login credentials and all good there locally. Another thought is the pfSense firewall rejecting incoming data from Oeck for some reason, however I have not yet found anything there.

Cheers,

Wayne

 

[Cameron]

Hi Wayne,

Well I guess this is a downside of not logging. The one thing I can tell you is the status of your last login. It's limited to: Successful login, Wrong password, Account in arrears, and Too many concurrent devices.
Currently it's a successful login. If you try now, I'll be able to tell you something.

Cameron

 

[Wayne]

Hi Wayne,

Well I guess this is a downside of not logging. The one thing I can tell you is the status of your last login. It's limited to: Successful login, Wrong password, Account in arrears, and Too many concurrent devices.
Currently it's a successful login. If you try now, I'll be able to tell you something.

Cameron

Hi Cameron,

I ran three attempts at an Oeck connect, all failed. Attached the log to see if you can see something I have missed.

Regards,


Wayne

 

[Cameron]

I can tell there has been no attempt at a login recorded in our database, so at least it's nothing to do with username/password being wrong.

Do you have a line in your config file:
verb 3

Because if you don't, that would explain the lack of logging.

Cameron.

 

[Wayne]

Yes, have verb 3 in my config file, also have verbose level 3 set in the config file. Interesting info though, this means my system is not presenting to Oeck for access, which could be the addressing in the config file.

 

[Cameron]

This is getting stranger the longer it goes. Can you send your openvpn config as it is now?

 

[Wayne]

Hi Cameron,

Attached as requested.

Regards,

Wayne

 

[Cameron]

Hi Wayne,

So there are a few things that need to change:

cipher AES-128-GCM
-> cipher AES-256-GCM

auth SHA512
-> auth SHA256

tls-crypt /var/etc/openvpn/client2.tls-crypt
-> tls-auth /var/etc/openvpn/client2.tls-crypt 1


Those 3 will stop it from working, but I would have thought each one would have error messages associated.

Cameron.

 

[Wayne]

Hi Wayne,

So there are a few things that need to change:

cipher AES-128-GCM
-> cipher AES-256-GCM

auth SHA512
-> auth SHA256

tls-crypt /var/etc/openvpn/client2.tls-crypt
-> tls-auth /var/etc/openvpn/client2.tls-crypt 1


Those 3 will stop it from working, but I would have thought each one would have error messages associated.

Cameron.

Hi Cameron,

Not sure what to do with this:
tls-crypt /var/etc/openvpn/client2.tls-crypt
-> tls-auth /var/etc/openvpn/client2.tls-crypt 1

The second file does not exist. The first file is the TLS key.

Changed the other two items successfully.

Cheers,


Wayne

 

[Cameron]

Hi Wayne,

I assume you got the client2.xxxx files from the relevant section of the ovpn file. If so, the tls file is the same one you already have.

Just to make sure we're on the same page,
client2.ca should be everything between <ca> and </ca>
client2.cert should be everything between <cert> and </cert>
client2.key should be everything between <key> and </key>
client2.tls-crypt should be everything between <tls-auth> and </tls-auth>

We use tls-auth instead of tls-crypt.
tls-auth /var/etc/openvpn/client2.tls-crypt 1
The 1 at the end is the key direction.

 

[Wayne]

Hi Cameron,

Are you referring to the TLS key as shown in my screenshot, I lifted this from the openvpn file for Sydney linux-Sydney-udp-256.ovpn

Cheers,

Wayne

 

[Cameron]

That's the one.

I'm not sure how that relates to the files listed in the config file. I assume pfsense puts them in the relevant files.
Looks like 'TLS key usage mode' needs to be set to 'Authenticate' not 'Encrypt and Authenticate'
That would be the difference between tls-crypt and tls-auth.
If you do that, then I assume the name of the file will be client2.tls-auth, but i have no idea how you would find that out.

Cameron.

 

[Wayne]

That's the one.

I'm not sure how that relates to the files listed in the config file. I assume pfsense puts them in the relevant files.
Looks like 'TLS key usage mode' needs to be set to 'Authenticate' not 'Encrypt and Authenticate'
That would be the difference between tls-crypt and tls-auth.
If you do that, then I assume the name of the file will be client2.tls-auth, but i have no idea how you would find that out.

Cameron.

OK, thanks Cameron.

I did all that, rebooted the Qotom to ensure a 'fresh' start, but no joy, Oeck still not connecting.

Buggar.


Cheers,


Wayne

 

[Cameron]

Any more help from the log file?

 

[Wayne]

Any more help from the log file?

Not really. Attached for info.

I also had a look around the System -> Routing -> Gateway Groups, but cannot see an issue there at this stage.

Cheers.

Wayne

 

[Cameron]

Ok - looks like we're getting somewhere.

Aug 15 10:18:05 openvpn 57810 TLS Error: TLS handshake failed
Aug 15 10:18:05 openvpn 57810 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Something to do with the TLS key.
Need to find out where pfsense puts the key, and the filename, and check it against the openvpn conf file.

 

[Wayne]

Thanks Cameron,

Great that you noted that, as I missed it.

Something to work at today for me it seems.

Thanks for the pointer.


Regards,

Wayne

 

[Peter]

Can't wait to see how much Google traffic this thread is going to bring
I'm pretty sure that between @Wayne and @Cameron pfsense can write half a troubleshooting document.

 

[Wayne]

Hi Cameron,

Not having much luck during the morning, I decided to reset to factory defaults to get rid of any interferences which could possibly occur from the other three VPN services setups, leaving the Qotom pfSense bare of any VPN.

Then I rebuilt the Oeck client in pfSense and have been testing various settings with no success so far. It seems to me there is something in the Custom Options needed, so I have been trialling various parameters within the Custom Settings, again without any joy.

With your advice in respect of the TLS Certificate and Custom Options it seems this is where the problem is.

Maybe within the latest log file there is something which jumps out, however I haven't seen it.

Cheers,


Wayne

 

[Cameron]

Ok, so I compared your log to my ubuntu log. Mine is line-for-line identical to yours until yours stops.
The next thing mine does is this:

Sun Aug 16 08:14:03 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA

I think we still have a TLS config problem. Do you have any settings that look like that?


Cameron.

 

[Wayne]

Ok, so I compared your log to my ubuntu log. Mine is line-for-line identical to yours until yours stops.
The next thing mine does is this:

Sun Aug 16 08:14:03 2020 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA

I think we still have a TLS config problem. Do you have any settings that look like that?


Cameron.

Gidday Cameron,

There is a setting in the Oeck config file I created, it is the Encryption Algorithm set at AES 256 GCM (256 bit key, 128 bit block), this sits under the Cryptographic Settings.

Cheers,

Wayne

 

[Wayne]

Hi Cameron

Here is the config file.

Cheers,

Wayne

 

[Cameron]

Hi Wayne,

Can you test this config file?
Copy your old one to a backup, then put this in:

dev ovpnc1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
remote 103.18.84.72 1194
cipher AES-256-GCM
auth SHA256
remote-cert-tls server
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.1.5
lport 0
client
management /var/etc/openvpn/client1.sock unix
auth-user-pass /var/etc/openvpn/client1.up
ca /var/etc/openvpn/client1.ca
cert /var/etc/openvpn/client1.cert
key /var/etc/openvpn/client1.key
tls-auth /var/etc/openvpn/client1.tls-auth 1
explicit-exit-notify 1
tun-mtu 32000
fragment 0
mssfix 0

 

[Wayne]

Hi Wayne,

Can you test this config file?
Copy your old one to a backup, then put this in:

dev ovpnc1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
remote 103.18.84.72 1194
cipher AES-256-GCM
auth SHA256
remote-cert-tls server
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.1.5
lport 0
client
management /var/etc/openvpn/client1.sock unix
auth-user-pass /var/etc/openvpn/client1.up
ca /var/etc/openvpn/client1.ca
cert /var/etc/openvpn/client1.cert
key /var/etc/openvpn/client1.key
tls-auth /var/etc/openvpn/client1.tls-auth 1
explicit-exit-notify 1
tun-mtu 32000
fragment 0
mssfix 0

Hi Cameron,

After some hours at this it seems I am going to have to do this the hard way.

I firstly backed up then edited the client1.conf within pfSense and saved it.
Nothing changed so rebooted.
pfSense overwrote the client1.conf file back to original.

I then edited the file remotely and copied back to pfSense, did a chown 600 to ensure correct permissions.
Fired up the pfSense GUI, checked the VPN service - not connecting.
So, checked the files back in the /var/etc/openvpn/ and pfSense had overwritten every file including client1.conf back to the original structure.

I will need to go through the pfSense VPN client setup again, this time endeavouring to ensure the suggested changes are made, these changes should 'stick' by this process.

Cheers,


Wayne

 

[Cameron]

You'll be a pro at this by the end.

 

[Wayne]

You'll be a pro at this by the end.

Gidday Cameron,

It seems so close now, however not quite.

The latest log file for your information.

I have been working on the Custom Settings quite a bit to see if the outcome of the Client1.conf improves. Progress has been made, error messages seem to have diminished, yet, still cannot connect.

Cheers,


Wayne

 

[Cameron]

Hi Wayne,

The log looks ok, it just stops without error.
I've been trying to replicate your problem by trying to break my config - I can't get anything to look like yours.

I have 2 plans:
1. Try TCP - should be only 2 changes necessary, anywhere you see UDP, put TCP. also port needs to change from 1194 to 443

If it connects on TCP - great. If it does work you should download an .ovpn file for TCP as there are a few other changes.

If not-
2. Now with TCP, I would like to get you on my test server. The setup is the same, but I can log everything. Maybe we get lucky and there is an error on the server end that helps.
When you are ready to try, can you put in a support ticket - that way I can give you the test IP address without it being public. I have no issue with this all being public - just not my test IP.

Cameron.

 

[Wayne]

Hi Cameron,

Did the TCP changes, no joy yet. Attached are the relevant logs.

I shall raise a ticket now and go from there.

cheers,

Wayne

 

[Wayne]

At last resolved satisfactorily using the assistance from Cameron and various online searches.

cheers,

Wayne

 

[iddqd]

can you please share with us what you found out so others may follow in your footsteps? perhaps edit your original post with some notes?

 

[Wayne]

can you please share with us what you found out so others may follow in your footsteps? perhaps edit your original post with some notes?

I understand Oeck staff will be placing up some info from working through pfSense with me.

Essentially, following guides from other VPN services helps a good deal.

A couple of areas which gave trouble were within the Oeck client file setup Custom Options worked after a lot of trial and error, these options are what I ended up with and are working:

fast-io;remote-random;pull;tls-client;remote-cert-tls server;route-method exe;route-delay 2;mssfix 1450;verb 3;

Another area causing bother within the same Oeck client file was Compression needed to be set at Omit Preference, + Disable Adaptive LZO Compression [Legacy Style, comp-noadapt]

I am working on the DNS settings at the moment as something there is just not quite right....

Hope this helps.

Cheers,

Wayne

 

[Cameron]

Ok. For everyone playing along at home - following is the support ticket between Wayne and myself.
The only thing I have removed is the relevant ip addresses and screenshots which also show ips or certificates, other than that it's all here.
----------------------------------------


Hi, As you no doubt are aware, I have been attempting to have Oeck enjoy a life in my Qotom pfSense box, so far, a life not yet happening for some reason.

Any guidance leading to success will be greatly appreciated.

Regards,

Wayne

=======================================================================================



Hi Wayne,

If you change the remote ip to xx.xx.xx.xx - that is my test server.
It doesn't work the same as the regular servers, but the connection is the same and I log everything on it.

It's sitting there right now whenever you are ready.

If you want to send logs - please either post them here or remove the ip if you want to put them on the community forum.

Cameron.

=======================================================================================

Hi Cameron,

I made the changes, no luck. Attached are the relevant logs.

Cheers,


Wayne
Client1 config. Tue Aug 18 2020 at 10:36


dev ovpnc1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp4-client
cipher AES-256-GCM
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.1.5
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote xx.xx.xx.xx 443 tcp4
auth-user-pass /var/etc/openvpn/client1.up
auth-retry nointeract
ca /var/etc/openvpn/client1.ca
cert /var/etc/openvpn/client1.cert
key /var/etc/openvpn/client1.key
tls-auth /var/etc/openvpn/client1.tls-auth 1
ncp-disable
compress
resolv-retry infinite
remote-random

tun-mtu-extra 32

mssfix 0

reneg-sec 0

remote-cert-tls server

tun-mtu 32000

fragment 0

OpenVPN log trialling TCP/IP Tue Aug 18 @ 10:34



Aug 18 00:33:25 openvpn 85199 Restart pause, 10 second(s)
Aug 18 00:33:25 openvpn 85199 SIGUSR1[soft,connection-reset] received, process restarting
Aug 18 00:33:25 openvpn 85199 Connection reset, restarting [0]
Aug 18 00:33:25 openvpn 85199 VERIFY OK: depth=0, CN=oeck-vpn
Aug 18 00:33:25 openvpn 85199 VERIFY EKU OK
Aug 18 00:33:25 openvpn 85199 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Aug 18 00:33:25 openvpn 85199 Validating certificate extended key usage
Aug 18 00:33:25 openvpn 85199 VERIFY KU OK
Aug 18 00:33:25 openvpn 85199 VERIFY OK: depth=1, CN=Oeck-CA
Aug 18 00:33:24 openvpn 85199 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:443, sid=e8076179 1f0c6c0a
Aug 18 00:33:24 openvpn 85199 TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:443
Aug 18 00:33:24 openvpn 85199 TCPv4_CLIENT link local (bound): [AF_INET]192.168.1.5:0
Aug 18 00:33:24 openvpn 85199 TCP connection established with [AF_INET]xx.xx.xx.xx:443
Aug 18 00:33:23 openvpn 85199 Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:443 [nonblock]
Aug 18 00:33:23 openvpn 85199 Socket Buffers: R=[65228->65228] S=[65228->65228]
Aug 18 00:33:23 openvpn 85199 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:443
Aug 18 00:33:23 openvpn 85199 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 18 00:33:17 openvpn 85199 MANAGEMENT: Client disconnected
Aug 18 00:33:17 openvpn 85199 MANAGEMENT: CMD 'state 1'
Aug 18 00:33:17 openvpn 85199 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Aug 18 00:33:13 openvpn 85199 Restart pause, 10 second(s)
Aug 18 00:33:13 openvpn 85199 SIGUSR1[soft,connection-reset] received, process restarting
Aug 18 00:33:13 openvpn 85199 Connection reset, restarting [0]
Aug 18 00:33:13 openvpn 85199 VERIFY OK: depth=0, CN=oeck-vpn
Aug 18 00:33:13 openvpn 85199 VERIFY EKU OK
Aug 18 00:33:13 openvpn 85199 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Aug 18 00:33:13 openvpn 85199 Validating certificate extended key usage
Aug 18 00:33:13 openvpn 85199 VERIFY KU OK
Aug 18 00:33:13 openvpn 85199 VERIFY OK: depth=1, CN=Oeck-CA
Aug 18 00:33:13 openvpn 85199 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Aug 18 00:33:13 openvpn 85199 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:443, sid=4b949c42 753f1b98
Aug 18 00:33:13 openvpn 85199 TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:443
Aug 18 00:33:13 openvpn 85199 TCPv4_CLIENT link local (bound): [AF_INET]192.168.1.5:0
Aug 18 00:33:13 openvpn 85199 TCP connection established with [AF_INET]xx.xx.xx.xx:443
Aug 18 00:33:12 openvpn 85199 Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:443 [nonblock]
Aug 18 00:33:12 openvpn 85199 Socket Buffers: R=[65228->65228] S=[65228->65228]
Aug 18 00:33:12 openvpn 85199 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:443
Aug 18 00:33:12 openvpn 85199 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 18 00:33:12 openvpn 85199 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 18 00:33:12 openvpn 85199 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 18 00:33:12 openvpn 85199 MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Aug 18 00:33:12 openvpn 84975 library versions: OpenSSL 1.0.2u-freebsd 20 Dec 2019, LZO 2.10
Aug 18 00:33:12 openvpn 84975 OpenVPN 2.4.9 amd64-portbld-freebsd11.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on May 4 2020
Aug 18 00:33:12 openvpn 84975 WARNING: file '/var/etc/openvpn/client1.up' is group or others accessible
Aug 18 00:33:12 openvpn 10378 SIGTERM[hard,init_instance] received, process exiting
Aug 18 00:33:09 openvpn 10378 MANAGEMENT: Client disconnected
Aug 18 00:33:09 openvpn 10378 MANAGEMENT: CMD 'state 1'
Aug 18 00:33:09 openvpn 10378 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Aug 18 00:33:08 openvpn 10378 Restart pause, 10 second(s)
Aug 18 00:33:08 openvpn 10378 SIGUSR1[soft,connection-reset] received, process restarting


=======================================================================================

Hi Wayne,

I have some more help from my end.

Tue Aug 18 10:33:13 2020 us=676880 x.x.x.x:2661 VERIFY ERROR: depth=0, error=unable to get local issuer certificate: O=pfSense webConfigurator Self-Signed Certificate, CN=pfSense-5f39ddbbe692e
Tue Aug 18 10:33:13 2020 us=676930 x.x.x.x:2661 OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
Tue Aug 18 10:33:13 2020 us=676939 x.x.x.x:2661 TLS_ERROR: BIO read tls_read_plaintext error
Tue Aug 18 10:33:13 2020 us=676945 x.x.x.x:2661 TLS Error: TLS object -> incoming plaintext read error
Tue Aug 18 10:33:13 2020 us=676950 x.x.x.x:2661 TLS Error: TLS handshake failed
Tue Aug 18 10:33:13 2020 us=677013 x.x.x.x:2661 Fatal TLS error (check_tls_errors_co), restarting

I google some of these errors, most likely points to the .key and .cert files.
Can you make sure that they are readable, and they contain the relevant sections from the .ovpn file?
It looks to me like pfsense is creating the cert - which it can't do without our CA. You need to use the key and cert from us.

Cameron.

=======================================================================================


Hi Cameron,

I am using the CA and TLS certificates copy and pasted from the Oeck Sydney 256 file. I have checked them again and they appear to be entire within the Oeck pfSense setup.

I even recreated the .ovpn profile on Oeck and downloaded it again yesterday to make sure.

Cheers,

Wayne

=======================================================================================

I think it's the key and cert sections, not the CA and TLS sections.

 

[Cameron]

=======================================================================================

This line from my log:
VERIFY ERROR: depth=0, error=unable to get local issuer certificate: O=pfSense webConfigurator Self-Signed Certificate, CN=pfSense-5f39ddbbe692e

The CN=pfsense... at the end means the certificate was created by pfsense.

If I do it from a working client, I get this:
VERIFY OK: depth=0, CN=oeck-abtsfWaChs

That is a cert created by us. If you look in the .ovpn file <cert> section, you can see the CN=oeck-xxxx

=======================================================================================


Now something changed - now there is no certificate at all.

OpenSSL: error:1417C0C7:SSL routines:tls_process_client_certificateeer did not return a certificate

=======================================================================================

Hi Cameron

OK, I will make a change in the client1 file to drop the webConfigurator option out if it is actually enabled.

Attached is the result.


Cheers,

Wayne

client1 config. Tue August 18 2020 at 11:11


dev ovpnc1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp4-client
cipher AES-256-GCM
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.1.5
tls-client
client
lport 0
management /var/etc/openvpn/client1.sock unix
remote xx.xx.xx.xx 443 tcp4
auth-user-pass /var/etc/openvpn/client1.up
auth-retry nointeract
ca /var/etc/openvpn/client1.ca
tls-auth /var/etc/openvpn/client1.tls-auth 1
ncp-disable
compress
resolv-retry infinite
remote-random

tun-mtu-extra 32

mssfix 0

reneg-sec 0

remote-cert-tls server

tun-mtu 32000

fragment 0



openvpn log file Tue August 18 2020 at 11:10.


Aug 18 01:09:22 openvpn 49447 Restart pause, 10 second(s)
Aug 18 01:09:22 openvpn 49447 SIGUSR1[soft,connection-reset] received, process restarting
Aug 18 01:09:22 openvpn 49447 Connection reset, restarting [0]
Aug 18 01:09:22 openvpn 49447 VERIFY OK: depth=0, CN=oeck-vpn
Aug 18 01:09:22 openvpn 49447 VERIFY EKU OK
Aug 18 01:09:22 openvpn 49447 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Aug 18 01:09:22 openvpn 49447 Validating certificate extended key usage
Aug 18 01:09:22 openvpn 49447 VERIFY KU OK
Aug 18 01:09:22 openvpn 49447 VERIFY OK: depth=1, CN=Oeck-CA
Aug 18 01:09:22 openvpn 49447 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:443, sid=81eab66a ab1c80ff
Aug 18 01:09:22 openvpn 49447 TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:443
Aug 18 01:09:22 openvpn 49447 TCPv4_CLIENT link local (bound): [AF_INET]192.168.1.5:0
Aug 18 01:09:22 openvpn 49447 TCP connection established with [AF_INET]xx.xx.xx.xx:443
Aug 18 01:09:21 openvpn 49447 Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:443 [nonblock]
Aug 18 01:09:21 openvpn 49447 Socket Buffers: R=[65228->65228] S=[65228->65228]
Aug 18 01:09:21 openvpn 49447 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:443
Aug 18 01:09:21 openvpn 49447 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 18 01:09:15 openvpn 49447 MANAGEMENT: Client disconnected
Aug 18 01:09:15 openvpn 49447 MANAGEMENT: CMD 'state 1'
Aug 18 01:09:15 openvpn 49447 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Aug 18 01:09:11 openvpn 49447 Restart pause, 10 second(s)
Aug 18 01:09:11 openvpn 49447 SIGUSR1[soft,connection-reset] received, process restarting
Aug 18 01:09:11 openvpn 49447 Connection reset, restarting [0]
Aug 18 01:09:11 openvpn 49447 VERIFY OK: depth=0, CN=oeck-vpn
Aug 18 01:09:11 openvpn 49447 VERIFY EKU OK
Aug 18 01:09:11 openvpn 49447 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Aug 18 01:09:11 openvpn 49447 Validating certificate extended key usage
Aug 18 01:09:11 openvpn 49447 VERIFY KU OK
Aug 18 01:09:11 openvpn 49447 VERIFY OK: depth=1, CN=Oeck-CA
Aug 18 01:09:10 openvpn 49447 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Aug 18 01:09:10 openvpn 49447 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:443, sid=46d93594 dede7762
Aug 18 01:09:10 openvpn 49447 TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:443
Aug 18 01:09:10 openvpn 49447 TCPv4_CLIENT link local (bound): [AF_INET]192.168.1.5:0
Aug 18 01:09:10 openvpn 49447 TCP connection established with [AF_INET]xx.xx.xx.xx:443
Aug 18 01:09:09 openvpn 49447 Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:443 [nonblock]
Aug 18 01:09:09 openvpn 49447 Socket Buffers: R=[65228->65228] S=[65228->65228]
Aug 18 01:09:09 openvpn 49447 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:443
Aug 18 01:09:09 openvpn 49447 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 18 01:09:09 openvpn 49447 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 18 01:09:09 openvpn 49447 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 18 01:09:09 openvpn 49447 MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client1.sock
Aug 18 01:09:09 openvpn 49417 library versions: OpenSSL 1.0.2u-freebsd 20 Dec 2019, LZO 2.10
Aug 18 01:09:09 openvpn 49417 OpenVPN 2.4.9 amd64-portbld-freebsd11.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on May 4 2020
Aug 18 01:09:09 openvpn 49417 WARNING: file '/var/etc/openvpn/client1.up' is group or others accessible
Aug 18 01:09:09 openvpn 91018 SIGTERM[hard,init_instance] received, process exiting
Aug 18 01:09:07 openvpn 91018 MANAGEMENT: Client disconnected
Aug 18 01:09:07 openvpn 91018 MANAGEMENT: CMD 'state 1'
Aug 18 01:09:07 openvpn 91018 MANAGEMENT: Client connected from /var/etc/openvpn/client1.sock
Aug 18 01:09:05 openvpn 91018 Restart pause, 10 second(s)
Aug 18 01:09:05 openvpn 91018 SIGUSR1[soft,connection-reset] received, process restarting

=======================================================================================


Ok, so it looks like the key and cert have been dropped from the config file. Which lines up with my end saying the peer did not return a certificate.

Is there some way that you can put the cert and key from the .ovpn file into for config without enabling webConfigurator?

The key and cert need to be ours - not pfsense's.

 

[Cameron]

Found this on netgate's site:

Cryptographic Settings
The settings in this section are identical to those on their corresponding options on the server side except for the new Client Certificate option, where the certificate is selected for use by this client. This certificate (and the associated key, and CA Certificate) must be imported to this firewall before they can be chosen.

Shared Key / TLS Authentication
These options work similar to the server side counterparts, but be aware that the key from the server must be copied here, rather than generating a new key on the client.

=======================================================================================

These are screens shots referring to certificates. I place Oeck CA and TLS copy and paste into the config file.

=======================================================================================

I think I found what you need, and why the other VPNs work.
Nord, Surfshark and PIA rely on username/password only. They don't care about the cert and key.
ExpressVPN uses the cert and key along with user/pass.
So do we. Only difference is ExpressVPN gives you a unique cert/key pair for your user - we create a random one when you download the .ovpn file. We don't actually know what cert/key you have.

According to expressvpn's pfsense page:
Add the certificate to System->Cert.Manager->Certificates.

You should then be able to select it instead of webConfigurator.

=======================================================================================
Hi Cameron,

Attached screenshots show the one CA certificate, Oeck's.

Cheers,

=======================================================================================

I think the revocation list is for an openvpn server. You need to add the cert and key to the certificates section.
=======================================================================================

Well that looks better.
=======================================================================================
Gidday Cameron,

Yeah, it seems closer, but not quite there yet.

Cheers,

Wayne
=======================================================================================

Ok, so what are we up to?

As far as I can tell, it connects to my test server OK.
=======================================================================================

Oeck Openvpn says it is 'up', but I cannot connect to anything via. It is possible I will now need to setup the firewall rules.

I attached the current logfiles.

Cheers,


Wayne

Client2 Tue August 18 2020 at 13:20


dev ovpnc2
verb 3
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_client2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto tcp4-client
cipher AES-256-GCM
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 192.168.1.5
tls-client
client
lport 0
management /var/etc/openvpn/client2.sock unix
remote xx.xx.xx.xx 443 tcp4
auth-user-pass /var/etc/openvpn/client2.up
auth-retry nointeract
ca /var/etc/openvpn/client2.ca
cert /var/etc/openvpn/client2.cert
key /var/etc/openvpn/client2.key
tls-auth /var/etc/openvpn/client2.tls-auth 1
ncp-ciphers AES-256-GCM:AES-128-GCM
resolv-retry infinite
remote-random

tun-mtu-extra 32

mssfix 0

reneg-sec 0

remote-cert-tls server

tun-mtu 32000

fragment 0

Openvpn log file Tue August 18 2020 13:24


Aug 18 03:19:20 openvpn 42927 MANAGEMENT: Client disconnected
Aug 18 03:19:20 openvpn 42927 MANAGEMENT: CMD 'status 2'
Aug 18 03:19:20 openvpn 42927 MANAGEMENT: CMD 'state 1'
Aug 18 03:19:20 openvpn 42927 MANAGEMENT: Client connected from /var/etc/openvpn/client2.sock
Aug 18 03:19:18 openvpn 42927 Initialization Sequence Completed
Aug 18 03:19:18 openvpn 42927 /sbin/route add -net 10.8.1.1 10.8.1.5 255.255.255.255
Aug 18 03:19:18 openvpn 42927 /sbin/route add -net 128.0.0.0 10.8.1.5 128.0.0.0
Aug 18 03:19:18 openvpn 42927 /sbin/route add -net 0.0.0.0 10.8.1.5 128.0.0.0
Aug 18 03:19:18 openvpn 42927 /sbin/route add -net xx.xx.xx.xx 192.168.1.1 255.255.255.255
Aug 18 03:19:18 openvpn 42927 /usr/local/sbin/ovpn-linkup ovpnc2 32000 32086 10.8.1.6 10.8.1.5 init
Aug 18 03:19:18 openvpn 42927 /sbin/ifconfig ovpnc2 10.8.1.6 10.8.1.5 mtu 32000 netmask 255.255.255.255 up
Aug 18 03:19:18 openvpn 42927 TUN/TAP device /dev/tun2 opened
Aug 18 03:19:18 openvpn 42927 TUN/TAP device ovpnc2 exists previously, keep at program end
Aug 18 03:19:18 openvpn 42927 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=igb0 HWADDR=40:62:31:13:f5:26
Aug 18 03:19:18 openvpn 42927 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 18 03:19:18 openvpn 42927 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: data channel crypto options modified
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: adjusting link_mtu to 32158
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: peer-id set
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: route options modified
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: --ifconfig/up options modified
Aug 18 03:19:18 openvpn 42927 Socket Buffers: R=[65700->393216] S=[65700->393216]
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Aug 18 03:19:18 openvpn 42927 OPTIONS IMPORT: timers and/or timeouts modified
Aug 18 03:19:18 openvpn 42927 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:4: block-outside-dns (2.4.9)
Aug 18 03:19:18 openvpn 42927 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.8.1.1,dhcp-option DOMAIN-ROUTE .,block-outside-dns,sndbuf 393216,rcvbuf 393216,route 10.8.1.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.1.6 10.8.1.5,peer-id 0,cipher AES-256-GCM'
Aug 18 03:19:18 openvpn 42927 SENT CONTROL [oeck-vpn]: 'PUSH_REQUEST' (status=1)
Aug 18 03:19:17 openvpn 42927 [oeck-vpn] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:443
Aug 18 03:19:17 openvpn 42927 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Aug 18 03:19:17 openvpn 42927 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Aug 18 03:19:17 openvpn 42927 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Aug 18 03:19:17 openvpn 42927 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-GCM', remote='cipher AES-128-CBC'
Aug 18 03:19:17 openvpn 42927 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 32032', remote='tun-mtu 1500'
Aug 18 03:19:17 openvpn 42927 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 32083', remote='link-mtu 1571'
Aug 18 03:19:16 openvpn 42927 VERIFY OK: depth=0, CN=oeck-vpn
Aug 18 03:19:16 openvpn 42927 VERIFY EKU OK
Aug 18 03:19:16 openvpn 42927 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Aug 18 03:19:16 openvpn 42927 Validating certificate extended key usage
Aug 18 03:19:16 openvpn 42927 VERIFY KU OK
Aug 18 03:19:16 openvpn 42927 VERIFY OK: depth=1, CN=Oeck-CA
Aug 18 03:19:16 openvpn 42927 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Aug 18 03:19:16 openvpn 42927 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:443, sid=c0708492 ecf91e1a
Aug 18 03:19:16 openvpn 42927 TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:443
Aug 18 03:19:16 openvpn 42927 TCPv4_CLIENT link local (bound): [AF_INET]192.168.1.5:0
Aug 18 03:19:16 openvpn 42927 TCP connection established with [AF_INET]xx.xx.xx.xx:443
Aug 18 03:19:15 openvpn 42927 Attempting to establish TCP connection with [AF_INET]xx.xx.xx.xx:443 [nonblock]
Aug 18 03:19:15 openvpn 42927 Socket Buffers: R=[65228->65228] S=[65228->65228]
Aug 18 03:19:15 openvpn 42927 TCP/UDP: Preserving recently used remote address: [AF_INET]xx.xx.xx.xx:443
Aug 18 03:19:15 openvpn 42927 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication

=======================================================================================
You logfile says all is good - you are connected.
The firewall will be all pfSense. I won't be much help to you there.

It's probably easier to go back to the regular servers now - things like DNS and internal addresses will be different to the test server.

Cameron.

=======================================================================================

 

[Cameron]

OK Cameron,

I will reset the IP addressing and the UDP and see what happens. Currently, pfSense says the Oeck VPN is 'up', however not yet able to access the web.

Did the IP change and over to UDP protocol and now, the connection is 'down'. Buggar.


cheers,

Wayne
=======================================================================================
Did you change the port back to 1194?

=======================================================================================

Thanks, I didn't. Done now, no connection.

Buggar.

Cheers,

Wayne
=======================================================================================
Any help in the log?

=======================================================================================

A little help. First it showed issues with the MTU, removed MTU from Custom Configs, then it was a password problem, so I redid that, then it has evolved into a TLS handshake error again, a bit like the dog down the street chasing it's tail it seems!

I shall do a bit more, if no good I might do a factory reset again and start from scratch following the ExpressVPN pfSense guide this time.

A related question: Does Oeck have an alert system whereby I get an alert email when a ticket has been responded to, like the alert I get from the Community blogs.


Cheers,

Wayne
=======================================================================================

I think it does - but honestly I know very little about the website side of the business.
I'll find out for you.
=======================================================================================

Turns out we had a few people with the notification turned off, and you were one of them. It should be on again.

Just so we can track why - did you ever click an unsubscribe link on an email from us?
We think that about a month ago, clicking that link may have also switched off notifications for support tickets.
=======================================================================================

Never clicked an unsubscribe, only clicked the notify emails to 'on' under the Oeck Community blogs

Whilst the pfSense is connecting, I am not able to transverse the 'net', yet. I needed to swap and switch the compression settings a few times before I found one which did not fault, or drop the connection.

All I need to do now is find why the data is not flowing <-> .

A job for me tomorrow, methinks.

Thank you for your help up to date, we have made progress with a short step (remaining - hopefully) to conclude.

Cheers,

Wayne
=======================================================================================

No problem - I'll help where I can.
=======================================================================================
Thanks.

FYI, I did another factory reset not long ago, rebuilt the Oeck client files and am at the point immediately prior, that is, Oeck seems to be connecting to the Oeck Sydney server, yet I am unable to stream data either way. As before, a job for tomorrow for me.

cheers,

Wayne

=======================================================================================
Hi Cameron,

At last, success.

This is the leak test result: https://ipx.ac/results/xxx which shows that Oeck is watertight for me.

This morning, I did yet another factory reset, then rebuilt the client from scratch yet again, all good until I got to the tunnelling/gateway settings, I did considerable testing, changing a parameter then more testing to whittle away all the errors.

Long story short, the final adjustment was within the 'System - General Setup', where I disabled the DNS forwarder, and viola!

I have re-booted the pfSense to ensure the settings 'stuck', and so far it looks good.

Speed tests results are excellent as per attached screenshot. (I am on a ABB 50/20 plan and 906 metres of 40 year degraded old copper to the NBN pillar.

Thanks again for your help and guidance without which I would surely have not a hair left on my head.

Cheers,

=======================================================================================
Hi Wayne,

Great news!
But I think there is 1 more thing.

The DNS shown in your leak test should be Oeck. The DNS is what will make your Netflix work.
Ideally, the router should get a DNS from the server when it connects, and then become the DNS server for any connected clients.

For example, if your router is 192.168.1.1:

Router connects to Oeck, gets a DNS server to use (10.204.2.1).
Local clients have a local IP (192.168.1.150), and DNS (192.168.1.1).
When the client needs a DNS lookup, it will ask the router, which will ask Oeck.

This is exactly how a regular home router works.

We need to do that because we hijack the request to netflix.
The best way to tell if you are using our DNS properly is to do this from a command prompt:
nslookup www.netflix.com

If you are not using our DNS, it will come back with about 10 answers.
If you are using our DNS, there will be 1 answer - something like 10.200.0.13.

If you need Cloudflare for some reason, we'll talk about that after everything else is working. You can still do it.


Cameron.

 

[Cameron]

=======================================================================================
Hi Cameron,

This is the result of nslookup www.netflix.com:

wayne@mainpc:~$ nslookup www.netflix.com
Server: 1.1.1.1
Address: 1.1.1.1#53

Non-authoritative answer:
www.netflix.com canonical name = www.geo.netflix.com.
www.geo.netflix.com canonical name = www.us-west-2.prodaa.netflix.com.
Name: www.us-west-2.prodaa.netflix.com
Address: 54.68.124.197
Name: www.us-west-2.prodaa.netflix.com
Address: 34.210.217.170
Name: www.us-west-2.prodaa.netflix.com
Address: 52.35.217.11
Name: www.us-west-2.prodaa.netflix.com
Address: 34.213.69.2
Name: www.us-west-2.prodaa.netflix.com
Address: 54.187.29.151
Name: www.us-west-2.prodaa.netflix.com
Address: 52.24.208.219
Name: www.us-west-2.prodaa.netflix.com
Address: 34.208.14.211
Name: www.us-west-2.prodaa.netflix.com
Address: 52.32.11.65
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3418:d0db
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3420:b41
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3423:f741
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3694:9f79
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3421:86d7
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3459:d6d6
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3423:18cf
Name: www.us-west-2.prodaa.netflix.com
Address: 2620:108:700f::3644:4be1

wayne@mainpc:~$

What now?

Cheers,


Wayne
=======================================================================================

Yep.
That means mainpc is not using the DNS from Oeck.
It's traffic may be going through the VPN, but it's not using our DNS.

The usual way to get your DNS from us, would be via the router.
So the router would connect to Oeck, get a DNS from us when it connects, and use it for itself.
It would then become the DNS server for your local network.
Each device would then have it's DNS set (either manually, or via DHCP) to the router IP.

The nslookup that you did came from 1.1.1.1.
Probably mainpc has it set manually.
You can find out if the router is acting as a DNS server with the following:
nslookup www.netflix.com 192.168.0.5 (or whatever your router address is)

If it comes back with nothing, or an error - then it's not a DNS server.
If it comes back with 1 answer (10.200.0.xx) - then it's a DNS server, and it's using Oeck.
If it comes back with many answers like before - then it's a DNS server, but not using Oeck.

Depending what it comes back with, we go a different way.
=======================================================================================
Hi Cameron,

Results:
wayne@mainpc:~$ nslookup www.netflix.com 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53

** server can't find www.netflix.com: REFUSED

wayne@mainpc:~$ nslookup www.netflix.com 192.168.1.0
;; connection timed out; no servers could be reached


wayne@mainpc:~$ nslookup www.netflix.com 192.168.1.5
;; connection timed out; no servers could be reached


wayne@mainpc:~$

192.168.1.5 is the Qotom WAN,
192.168.1.1 is my Main PC running Ubuntu,
192.168.1.0 is the start point for IP addressing in the Qotom pfSense box.

The 1.1.1.1 is set in Main PC Ubuntu Network-Manager.

Cheers,

Wayne
=======================================================================================

Ok, so it looks like the Qotom box is not a DNS server - that can be a job for later.
In the meantime, if you set the DNS in Ubuntu to 10.201.1.1, it should start using Oeck.

After changing it - do another nslookup www.netflix.com
=======================================================================================

Hi Cameron,

That did the trick, thanks.

Output of nslookup.

wayne@mainpc:~$ nslookup netflix.com
Server: 10.201.1.1
Address: 10.201.1.1#53

Name: netflix.com
Address: 10.200.0.17

wayne@mainpc:~$


Regards and thanks again.

Wayne
=======================================================================================
Awesome!

Something to keep in mind though-
The Oeck DNS server is only visible when connected to Oeck. If the router VPN stops, the pc will lose DNS.

That's why it's worth figuring out the DNS server in pfSense. Then the router controls it - if the VPN stops, it can fall back to your ISP or another DNS, and the PC keeps working.
=======================================================================================
Thanks Cameron,

A task then for me, to get to work on the DNS server in pfSense, I best get to it.

Cheers,

Wayne
=======================================================================================

 

[justinmeryment]

Thanks Wayne and Cameron, following these notes I've also managed to get Oeck to connect on my Pfsense box.
I've also just figured out the DNS server settings.
What I've done:
1. Go to system/general setup
2. Configure Oeck DNS servers (10.204.2.1, 10.207.0.1) with your VPN interface as the gateway
3. Add your ISP DNS servers with your WAN interface as the gateway, ensuring these are below the Oeck ones
4. Disable "DNS Server Override"
5. Save this page and apply changes if required.
6. Go to "Services/DNS Resolver"
7. Untick "Enable DNS resolver"
8. Save this page and apply changes if required.
9. Go to "Services/DNS Forwarder"
10. Tick "Enable DNS forwarder"
11. Tick "Query DNS servers sequentially" (ensures Oeck DNS is used before ISP, but will allow fallback if Oeck is down)
12. Optionally, tick "Register DHCP leases in DNS forwarder" and " Register DHCP static mappings in DNS forwarder" to allow local network host lookups.
13. Save this page and apply changes if required.
14. Go to "System/Advanced"
15. Tick " Disable DNS Rebinding Checks" (This is required because Oeck deliver netflix/hulu etc services on a private IP address)
16. Save this page and apply changes if required.
17. Go to "Services/DHCP Server"
18. Ensure "DNS Servers" list is either blank or has your pfsense IP address only
19. Save this page and apply changes if required.
20. You should be all done, check by doing an nslookup on netflix.com from your PC. A private IP address (10.X.X.X) should be returned.
21. If it's not working, try restarting your device to ensure the new DHCP settings are picked up.

 

[Cameron]

Thanks Justin - pretty amazing that a 21 step process is necessary just for DNS!

 

[justinmeryment]

A bunch of the steps could be skipped if your pfsense box is still "stock", but I thought it was best to include anything relevant.
Pfsense is certainly not a router for the faint-hearted!

 

[den]

Hi Wayne,
Any chance we could get screen shots of the settings you have used?

 

[Wayne]

Hi Wayne,
Any chance we could get screen shots of the settings you have used?

Hi den,

I do not yet have pfSense working properly, once it is, I am happy to provide details of settings.

 

[den]

Hi den,

I do not yet have pfSense working properly, once it is, I am happy to provide details of settings.

Awesome, thanks very much Wayne

 

[justinmeryment]

Here are my OpenVPN Client settings that are working for me.
You'll then need to configure an OpenVPN interface and the DNS settings I posted earlier.

 

[Wayne]

Here are my OpenVPN Client settings that are working for me.
You'll then need to configure an OpenVPN interface and the DNS settings I posted earlier.

Hi justinmeryment,

Thank you for posting those pics.

Your setup is similar to mine, other than, based upon advice in this matter from others, I changed tack and went down the TCP:443 path after not luck with UDP:1194.

I am wondering why port 1196 for UDP?

Once I have my setup sorted (with much appreciated help from Cameron/Oeck), I will post up my settings in the hope others will enhance and improve.

Cheers,

 

[justinmeryment]

I went with UDP over TCP as it’s generally going to be faster due to not having as many protocol overheads.
UDP:1196 is because of the encryption algorithm. AES-128-CBC is on port 1196 and AES-256-CBC is on port 1194.
AES-128-CBC is slightly faster and more than secure enough for my needs.

 

[den]

Thanks for all the help.
No luck on my end though, seems to just keep timing out.
Any suggestions?

 

[Cameron]

Hi Den,

Looks a lot like a firewall issue to me. Easiest way to figure it out is by using the TCP/256 .ovpn file, because that uses port 443 (https port).

Cameron.

 

[den]

Thanks Cameron,
Tried TCP with port 443 and this is what I get

 

[Cameron]

Hi Den,

The next thing it should do instead of "Connection reset", is the TLS handshake.
Do you have all the crypto settings right?

ie. TLS Enabled, AES-256-GCM, AUTH-256, the CA and TA-Auth certs, etc.

Cameron.

 

[den]

Thanks Cameron, All matching justinmeryment settings with the matching details from the opvn config file.
All good, I think I will just give up for now, im using connectify on an old laptop to get around it.

 

[justinmeryment]

Did you copy the tls key from your oeck config file? Or just using the auto generated one?
I’d be checking that and reimporting the ssl and CA certificate.

 

[bladesong]

Late to the party perhaps, but I have a question for the OP.
Did you set up the NAT rules correctly in pfSense? When setting up a OpenVPN connection for another unnamed VPN company, one of the steps was to change the setup in Firewall > Nat > Outbound to "Manual Outbound Nat rule generation" and configure a bunch of NAT rules based on the auto generated ones, changing the gateway used tot he OpenVPN gateway you created.

Following justinmeryment's screen shots, and DNS confguration steps, plus the NAT rules has it all running for me.

 

[Wayne]

Thanks Wayne and Cameron, following these notes I've also managed to get Oeck to connect on my Pfsense box.
I've also just figured out the DNS server settings.
What I've done:
1. Go to system/general setup
2. Configure Oeck DNS servers (10.204.2.1, 10.207.0.1) with your VPN interface as the gateway
3. Add your ISP DNS servers with your WAN interface as the gateway, ensuring these are below the Oeck ones
4. Disable "DNS Server Override"
5. Save this page and apply changes if required.
6. Go to "Services/DNS Resolver"
7. Untick "Enable DNS resolver"
8. Save this page and apply changes if required.
9. Go to "Services/DNS Forwarder"
10. Tick "Enable DNS forwarder"
11. Tick "Query DNS servers sequentially" (ensures Oeck DNS is used before ISP, but will allow fallback if Oeck is down)
12. Optionally, tick "Register DHCP leases in DNS forwarder" and " Register DHCP static mappings in DNS forwarder" to allow local network host lookups.
13. Save this page and apply changes if required.
14. Go to "System/Advanced"
15. Tick " Disable DNS Rebinding Checks" (This is required because Oeck deliver netflix/hulu etc services on a private IP address)
16. Save this page and apply changes if required.
17. Go to "Services/DHCP Server"
18. Ensure "DNS Servers" list is either blank or has your pfsense IP address only
19. Save this page and apply changes if required.
20. You should be all done, check by doing an nslookup on netflix.com from your PC. A private IP address (10.X.X.X) should be returned.
21. If it's not working, try restarting your device to ensure the new DHCP settings are picked up.

Hi justinmeryment

Would you mind providing me some more clarity on steps 2 and 3 please?

2. Configure Oeck DNS servers (10.204.2.1, 10.207.0.1) with your VPN interface as the gateway
3. Add your ISP DNS servers with your WAN interface as the gateway, ensuring these are below the Oeck ones

a) Do I need to create a specific gateway for Oeck?
b) ISP DNS servers, are these from ABB which are 'locked' into my ABB Netcomm modem?
c) WAN interface, could you clarify please.

cheers,

Wayne


Thanks