OpenVPN for road warrier

[defaultuserfoo]

Hi,

I'm following the guide[1] to set up a road warrier.  Unfortunately, the example in the guide uses a private IP address, which makes it utterly confusing.  Road warriers are obviously not on some internal network with a private IP but somewhere remote, and they connect via some internet connection if they can get one at the remote place.  That's why they are called 'roadwarriers' in the first place.  If they were on the local network with a private IP, they wouldn't need to use a VPN to connect.

So I need to use one of the public IPs the OPNsense machine has for roadwarriers to connect to.  Let's assume the public IP is 123.123.123.1.  That would mean that I'd have to use 123.123.123.1 in place of the 10.10.8.1 in the example for the bind address.  That would also mean that I would have to use 123.123.123.0/24 as the server address.  Obviously, that doesn't make any sense.

Is there a guide that shows how to set up an OpenVPN connection for roadwarriors at remote sites to connect over the internet and via the OPNsense router to a server on the LAN?

I'd rather use wireguard, but the device that needs to connect via the internet only supports OpenVPN.

[1]: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html

[viragomann]

So I need to use one of the public IPs the OPNsense machine has for roadwarriers to connect to. That would mean that I'd have to use 123.123.123.1 in place of the 10.10.8.1 in the example for the bind address.

Yes.
The guide in the docs assumes that the OpenVPN traffic is forwarded from the public IP. This could be done on a router in front of OPNsense, but also on OPNsense itself. But no need, if you have a public IP assigned to OPNsense, you can bind the VPN server to it.

That would also mean that I would have to use 123.123.123.0/24 as the server address.

No. The servers address is VPN tunnel subnet.
The docs are correct here. The server IP is a separate private subnet. The bind address doesn't belong to it.

[Monviech (Cedrik)]

I prefer binding to 127.0.0.1 and then use port forward rules. Especially useful for Multi WAN scenarios too.

[defaultuserfoo]

The guide in the docs assumes that the OpenVPN traffic is forwarded from the public IP.

Hm, I don't see that in the guide.  Why is the example in the documentation so obfuscating?  It would make a lot more sense if the public IP of OPNsense would be used because that's what users would actually do.

This could be done on a router in front of OPNsense, but also on OPNsense itself. But no need, if you have a public IP assigned to OPNsense, you can bind the VPN server to it.

If you put a router in front, you get double NAT.  That's usually not desirable.  Would that even work?

That would also mean that I would have to use 123.123.123.0/24 as the server address.

No. The servers address is VPN tunnel subnet.
The docs are correct here. The server IP is a separate private subnet. The bind address doesn't belong to it.

The server is the router.  The router has some public IPs.  How are clients supposed to connect to it if not via its public IPs?

[defaultuserfoo]

I prefer binding to 127.0.0.1 and then use port forward rules. Especially useful for Multi WAN scenarios too.

Then how do you get any clients to connect?

[viragomann]

Hm, I don't see that in the guide.

The private binding IP implies this though.

I prefer binding to 127.0.0.1 and then use port forward rules. Especially useful for Multi WAN scenarios too.

Then how do you get any clients to connect?

You just add a port forwarding rule on the WAN to forward e.g. port 1194 UDP to 127.0.0.1.

[defaultuserfoo]

Hm, I don't see that in the guide.

The private binding IP implies this though.

Guides shouldn't assume that we know about what they might imply or not; they should be explicit so we can follow them and get the desired results.

I prefer binding to 127.0.0.1 and then use port forward rules. Especially useful for Multi WAN scenarios too.

Then how do you get any clients to connect?

You just add a port forwarding rule on the WAN to forward e.g. port 1194 UDP to 127.0.0.1.

Clients aren't going to connect to 127.0.0.1 or any other private address because they are somewhere remote and are trying to connect through the router to the network(s) behind it.  This guide is misleading.

Anyway, it doesn't work.  I'm trying to have a Grandstream WP816 phone connect to the PBX via the VPN, and it's not working.  I got no logging output and no further information that could help to find out what the problem might be.  They should have used wireguard on these phones instead, that would be so much easier, and they should have made it possible to find out why it doesn't work.  So if you're considering to use the WiFi phones from Grandsteam remotely assume that it's not possible.

[viragomann]

Clients aren't going to connect to 127.0.0.1 or any other private address because they are somewhere remote and are trying to connect through the router to the network(s) behind it.  This guide is misleading.

No, but the suggestion is to forward the traffic from the interface, the client can connect.

So your client probably can reach your WAN, then forward OpenVPN port from the WAN IP to the localhost.

If you export the client config, you have to state your public IP or FQDN in at "Hostname" if the VPN server is listening on any other IP.

[defaultuserfoo]

I didn't notice anything in the guide about making firewall or NAT rules.

The openVPN log shows error messages with unrelated IP addresses but no messages about the phone trying to connect.  This is an entirely black box, and the only thing I can tell is that it doesn't work.

[viragomann]

Without any idea of what you did and what's in server and client log, nobody will be able to help you.

[defaultuserfoo]

Well, I followed a guide[1] to set up the openVPN connection on the router, exported a configuration file and uploaded it to the phone.

I don't have a client log.  The phone only shows a message that it couldn't connect.  The log file on the router only has entries like:


TLS Error: cannot locate HMAC in incoming packet from [AF_INET]47.237.115.221:49386
TLS Error: incoming packet authentication failed from [AF_INET]47.237.115.221:45287


Those are not from IP addresses used by the place the phone was taken to for testing, and from times when the phone wasn't tested.  There is no indication at all that the phone tried to connect, and I don't know if there should be any.  This is all I got.

For all I know the firmware of the phones is buggy.  Or maybe it's not.  It's totally flawed because it doesn't give any information, and there is no documentation about the openVPN feature of the phone.


[1]: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html

[viragomann]

I don't have a client log.  The phone only shows a message that it couldn't connect. 

I used the OpenVPN connect app on iPhone and Android as many others and it writes a log, which you can inspect and share.

The log file on the router only has entries like:


TLS Error: cannot locate HMAC in incoming packet from [AF_INET]47.237.115.221:49386
TLS Error: incoming packet authentication failed from [AF_INET]47.237.115.221:45287


Those are not from IP addresses used by the place the phone was taken to for testing, and from times when the phone wasn't tested.  There is no indication at all that the phone tried to connect, and I don't know if there should be any.  This is all I got.

At least this prooves that the VPN server is accessible from outside.

So we have to assume, that the problem is on the client side.
Was the phone connected to the internet and outside of your local network / wifi, while you tried to connect?
Did it connect to your public IP?

[Monviech (Cedrik)]

I think it's a VOIP Desk Phone that is talked about.

I once a few years back used a Yealink T46 as OpenVPN client, but the firmware was buggy and the Yealink support gave me custom firmwares to try but it always sucked.

A VOIP phone shouldn't need VPN, it should just use SIP/RTP directly, or encrypt it via SIP(S) and RTP(S) if required. Or use H.323 which also supports encryption.

[defaultuserfoo]

I don't have a client log.  The phone only shows a message that it couldn't connect.

I used the OpenVPN connect app on iPhone and Android as many others and it writes a log, which you can inspect and share.

That I don't have.

The log file on the router only has entries like:


TLS Error: cannot locate HMAC in incoming packet from [AF_INET]47.237.115.221:49386
TLS Error: incoming packet authentication failed from [AF_INET]47.237.115.221:45287


Those are not from IP addresses used by the place the phone was taken to for testing, and from times when the phone wasn't tested.  There is no indication at all that the phone tried to connect, and I don't know if there should be any.  This is all I got.

At least this prooves that the VPN server is accessible from outside.

So we have to assume, that the problem is on the client side.
Was the phone connected to the internet and outside of your local network / wifi, while you tried to connect?
Did it connect to your public IP?

Yes, the phone was taken to another place to make sure it would connect via an unlreated internet connection to avoid possible interferences from trying it behind the very router that the phone is supposed to connect to.  It got a different private IPv4, and I don't think the port was blocked by the foreign router, but I can't be 100% sure.

I can't tell if it connected to the public IP or not.  I have no indication as to wether it did or didn't.  If it did connect successfully, that might not create log entries.

[defaultuserfoo]

I think it's a VOIP Desk Phone that is talked about.

It's a WIFI phone.  It has a little charging station you can it plug into.  For normal use you carry it around.  It works fine when connected via WIFI to a local vlan.

I once a few years back used a Yealink T46 as OpenVPN client, but the firmware was buggy and the Yealink support gave me custom firmwares to try but it always sucked.

A VOIP phone shouldn't need VPN, it should just use SIP/RTP directly, or encrypt it via SIP(S) and RTP(S) if required. Or use H.323 which also supports encryption.

I don't want to make the asterisk instance publicly available over the internet for everyone.

Maybe not many customers use the VPN option and the firmware is buggy.