1u-shenanigans build using FireEye NX900

Hardware

Build List:

pfsense OS Configuration

I followed @JDM_WAAAT’s suggestion for OpenVPN suggestion, but can’t seem to get TLS auth working on OSX + Tunnelblick. Does anyone have any suggestions on how to get this working?

I followed that configuration ^^ to the letter, but used Google Domain DyDNS instead of no-ip.org. I keep getting the following errors on the client:

Here’s my .ovpn file:

dev tun
persist-tun
persist-key
cipher AES-128-CBC
ncp-ciphers AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote <redacted-dydns-url> 1194 udp4
lport 0
verify-x509-name "<redacted-dydns-url>" name
auth-user-pass
remote-cert-tls server

<ca>
-----BEGIN CERTIFICATE-----
<redacted>
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
<redacted>
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
<redacted>
-----END PRIVATE KEY-----
</key>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
<redacted>
-----END OpenVPN Static key V1-----
</tls-auth>

Logs from tunnelblick

2020-07-22 01:58:25.457277 MANAGEMENT: CMD 'username "Auth" "vpn"'
2020-07-22 01:58:25.457327 MANAGEMENT: CMD 'password [...]'
2020-07-22 01:58:25.457488 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-07-22 01:58:25.492773 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2020-07-22 01:58:25.492814 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2020-07-22 01:58:25.493463 MANAGEMENT: >STATE:1595408305,RESOLVE,,,,,,
2020-07-22 01:58:28.643976 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.30.75:1194
2020-07-22 01:58:28.644079 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-07-22 01:58:28.644112 UDPv4 link local (bound): [AF_INET][undef]:0
2020-07-22 01:58:28.644124 UDPv4 link remote: [AF_INET]192.168.30.75:1194
2020-07-22 01:58:28.644178 MANAGEMENT: >STATE:1595408308,WAIT,,,,,,
2020-07-22 01:58:28.649123 MANAGEMENT: >STATE:1595408308,AUTH,,,,,,
2020-07-22 01:58:28.652131 TLS: Initial packet from [AF_INET]192.168.30.75:1194, sid=201007c0 2c73098a
2020-07-22 01:58:28.652156 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]192.168.30.75:1194
2020-07-22 01:58:31.025433 MANAGEMENT: >STATE:1595408311,AUTH,,,,,,
2020-07-22 01:58:31.025517 TLS: Initial packet from [AF_INET]192.168.30.75:1194, sid=201007c0 2c73098a
2020-07-22 01:58:31.025542 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]192.168.30.75:1194
2020-07-22 01:58:35.924539 MANAGEMENT: >STATE:1595408315,AUTH,,,,,,
2020-07-22 01:58:35.924619 TLS: Initial packet from [AF_INET]192.168.30.75:1194, sid=201007c0 2c73098a
2020-07-22 01:58:35.924655 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]192.168.30.75:1194
2020-07-22 01:58:37.803473 *Tunnelblick: Disconnecting; VPN Details… window disconnect button pressed
2020-07-22 01:58:37.948486 *Tunnelblick: Disconnecting using 'kill'

I have verified that the firewall has WAN rules for 1194 and repeated all the steps in the installation guide from scratch. Any help would be much appreciated!

https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/openvpn-remote-access-server.html

I re-checked all the settings and things look right.

Do you see any issues with my .ovpn configuration? The only thing I am thinking is that the Allowed NCP is AES-128-GCM. Do I need to add any more?

Do you know how to fix this?

TLS Error: cannot locate HMAC in incoming packet

I added:

tls-auth [inline]

and moved the key-direction 1 down to the bottom. No difference.

I also changed the order of ncp-ciphers and cipher, no differences there as well.

Your logs show you trying to connect to 192.168.30.75, which is a non-routable IP. Are you trying to test the server from within your network? That won’t work unless you explicitly configure the OpenVPN server to listen on the LAN network instead of WAN. You’ll need to test it from another network, like a mobile tether or a neighbor’s house or Starbucks WiFi or whatever.

192.168.30.75 is the IP address of my laptop. Interesting… How did that happen?

Unclear, maybe your dynamic dns address was set to your internal IP instead of your public IP somehow? Check the ip of your address using nslookup, try it from your laptop as well as another device. If it’s showing as your internal IP, pfSense has a built-in dynamic DNS updater that works with Google Domains, set that up if you haven’t already done so.

Ah, I didn’t even think about this until now. There’s a 192.168.30.0/24 network interface defined on pfsense… I wonder if that might have something to do with it…

Looks like I made sure to avoid that. Hrm. Still stuck…

Screen Shot 2020-07-22 at 2.37.02 PM

Just to be clear, VL20_VPN is for client VPN configuration.

ping yourhostname.dyndns.org

It looks like you just accidentally selected the wrong monitor interface in your dynamic DNS config on the pfsense machine.

1 Like

Where do I check that? If you mean this: Services/Dynamic DNS/Dynamic DNS Clients, then I have that set to WAN, and am using other port forwards that works just fine.

Did you try the ping or nslookup tests on the device you were using to test the VPN, as well as on another device inside your network, and if so did they both return your public IP or your laptop’s IP? My theory is just a guess based on the information you’ve provided, so it may not be the actual source of the problem, but the results of these tests can hopefully lead us down the correct path.

1 Like

Oh man, you guys rock! I was so focused on configuration issues, I didn’t even think to see if the DNS entry was incorrect.

I manually set the public IP address of the pfsense box in the tunnelblick config, and it connected almost right away… sigh. So yeah, somehow my laptop is not resolving that address correctly.

Thank you guys so much for the help!

Always DNS

2 Likes

It might have also been the NCP Algorithms allowed list. Originally there was only AES-128-GCM listed. I added AES-128-CBC to the list when I was troubleshooting things.

I removed it to go back to what the wizard generated, and was unable to connect. So it was likely just DNS or BOTH.

Appreciate all the prompt responses. Was on a tight timeline and needed to get this sorted before tomorrow.

How would the 16GB SSD’s attached to the case?

I just zip-tied them together and zipped them up to the chassis. I might 3d-print a case, but, it works just fine. As long as they don’t short out against the metal, should be fine.

Cool, Thank you