Simple VPN Server

Bert 0

@viragomann Thanks for the explanation. I have removed my NetGate from my network for now but I may try your suggestion another time. I thought I had run the wizard already, though.

Bert

stephenw10

Adding an OpenVPN server using the Wizard is really not that hard at all.

The only prerequisite is that you have a public IP on the WAN interface. And I'm pretty sure you do have that since you said you were port forwarding stuff currently.

See: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-ra.html

There's even a video walk through: https://www.youtube.com/watch?v=jQHqPq7ftz4

And, yeah, nobody should be using PPTP on anything in 2022!

Steve

Bert 0

@stephenw10 Thanks again, Steve.

As I mentioned above, I have removed the device from my network. I won't be in my office tomorrow but sometime over the next couple of days I will go through the setup of my OpenVPN again.

Thanks for the links.

Bert

Cool_Corona

@stephenw10 It depends on what you want from it...

A basic and very easy tunnel to somewhere else not handling any defcon 5 stuff.

I use to watch danish TV from Switzerland. Its easy and much faster than OpenVPN.

Much easier to setup and get running and its running via the router itself so no intervention from any clients.

So its maybe insecure, but so are your frontdoor to the house if I drive a bulldozer straight through it.

Only the strongest doors will survive hense my comments about defcon 5.

And a PPTP running straight HTTPS surfing traffic is more secure than straight and open internet HTTPS traffic.

So I just dont get that PPTP is insecure.... its theoretical and needs some things in place to be hacked....

aGeekhere

If you want OpenVPN with TAP/Bridging follow this https://hardforum.com/threads/pfsense-2-0-1-openvpn-configuration-guide.1663797/

jimp

DO NOT USE OR RECOMMEND PPTP UNDER ANY CIRCUMSTANCES IN 2022

It's been completely broken and proven to be broken for 10 years

https://isc.sans.edu/diary/End+of+Days+for+MS-CHAPv2/13807

Not theoretically. Practically. There are utilities to decrypt captures. All an attacker needs to do is capture the packets, nothing special.

Stop the insanity.

OpenVPN is easy with the wizard. If you need speed, use WireGuard, which is also not difficult. If you don't care about encryption and only about circumventing geographical blocks then you can still use OpenVPN without encryption.

Cool_Corona

@jimp I hear you....

A tool for parsing and decrypting MS-CHAPv2 network handshakes.

The first thing you'll need to do is obtain the network traffic for the MS-CHAPv2 handshake you'd like to crack.

For PPTP VPN connections, simply use a tool such as tcpdump or wireshark in order to obtain a network capture. For WPA2 Enterprise wireless handshakes, simply use a tool like FreeRADIUS-WPE in order to obtain 'challenge' and 'response' parameters.

Next you'll use chapcrack in order to parse and extract the MS-CHAPv2 handshake from your packet capture or FreeRADIUS interception.
    For a PPTP handshake, run: chapcrack.py parse -i /path/to/capture.cap
    For a WPA2 handshake, run chapcrack.py radius -C <challenge> -R <response>, where challenge and response are what you intercepted with FreeRADIUS-WPE

Submit the CloudCracker token chapcrack gives you to https://www.cloudcracker.com

When you get your results, you can decrypt a PPTP packet capture: chapcrack.py decrypt -i </path/to/capture.cap> -o output.cap -n <result>

Wouldnt you need to be on the same network and GW to do that?

You cant do it in the wild...on somebody elses internet connection.

Bert 0

Well, I setup the server and tried to connect a client but I get the error:

Fri May 06 12:25:32 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri May 06 12:25:32 2022 TLS Error: TLS handshake failed

I get this on two different windows 10 boxes - one on my internal network and on I created in the cloud to test connectivity.

Ant suggestions? I find the client to be less than intuitive :-(

Bert

viragomann

@bert-0
This error mostly indicates that the client cannot reach the server.
You can sniff the packets on WAN interface using Diagnostic > Packet capture to investigate if the packets arrive properly on the WAN interface of pfSense.

Bert 0

@viragomann That's what I thought but a tracert from the machine on my office network reaches the outside of my firewall in a single hop.

Bert

jimp

@cool_corona said in Simple VPN Server:

Wouldnt you need to be on the same network and GW to do that?
You cant do it in the wild...on somebody elses internet connection.

The entire purpose of a VPN (and other encrypted protocols) is to protect against someone else being able to decode traffic intercepted between you and a peer.

You have no idea if you can trust every single hop between you and your VPN peer(s). Once the traffic leaves your premises any link and router is untrustable from a security standpoint. Routers could be hacked, redirected or inspected by state actors, data mined, etc. Good luck telling anyone that owns those links or hacks them "you can't do that".

If you aren't worried about someone intercepting your traffic then go back to using HTTP and telnet.

viragomann

@bert-0
The issue is here the access from a remote client to the firewall. A tracert from inside your LAN is no proof that packets can reach your WAN interface from the internet.

Bert 0

@viragomann But, that's why I set up the client on two machines: One in the cloud for internet access and one from my local network to test without internet. Tracert on the cloud machine fails but I assumed that that was because the provider was dropping most ICMP traffic.

Bert

viragomann

@bert-0 said in Simple VPN Server:

But, that's why I set up the client on two machines: One in the cloud for internet access and one from my local network to test without internet. Tracert on the cloud machine fails but I assumed that that was because the provider was dropping most ICMP traffic.

Much effort for someone who want's to set up a simple VPN server.
The access from an internal network might not have been respected by the wizard.

If you're unsure that your cloud client is allowed to go out on the stated port, simply use a port checker in the internet, enter your WAN IP and OpenVPN port and trigger a check, while you sniff the traffic on your WAN.
If your VPN server is configured for UDP protocol ignore the result of the port checker, since it might only send TCP packets.

stephenw10

That's the error you get when the client can't reach the server at all so it just times out. Or the server can not reply.

Where are you testing from? How the client trying to connect? By IP address or FQDN?
When you use the client export utility it uses the interface address the server is running on by default. That means if the pfSense WAN is using a private IP right now the imported client config will only be able to connect from something that can access it.

Steve

Bert 0

@viragomann Yeah, it is far more effort than I expected and it still isn't working. I did a port check and it said that 1194 is closed. I double checked the OpenVPN server to make sure that it was using the default port and it is.

Bert

Bert 0

@stephenw10 Now my comments are being flagged as spam...

Bert 0

Well, I guess if you poke something often enough, it will respond. VPN up and operating across the internet :-)

Bert

stephenw10

OpenVPN is UDP by default so port tests against it will fail.

I upvoted enough of you posts to get your 'rep' above 5. You should avoid the spam filter now.

Anyway, glad you're up and running.