OpenVPN remote users

jimp

The wizard should be fixed in the next new snapshot.

There's not enough information to say for sure why the route might not be happening. We'd need to see your server config (screenshot of the GUI) and client config file to really say for sure.

Here's a guess, though: The route to LAN would be controlled by what you have in the "local subnet" box of the server. If that IP/CIDR combination is set properly, the right route should be pushed to the client if you are using PKI.

If you are using shared key, you'll need a route statement in the client config file.

ReddogTech

Thanks for your reply jimp!

I am upgrading to the newest snapshot.

I am using PKI (SSL/TSL) and I have put the correct CIDR range (192.168.253.0/24) which is my lan subnet. What you have confirmed never worked in 1.2.3, we always had to use an advanced push statement.

The server CIDR range is 10.0.8.0/24.

The only thing different between the sticky instructions and my setup is the LAN CIDR range. Maybe I have this incorrect.

I am going to see if I can get it working on the latest version and report back.

ReddogTech

On a completely different note:

It would be great to see a little more information on where the upgrade is at on the firmware autoupgrade screen. I am no coder but it would be great to see some kind of response when the image is being expanded (and a progress indicator), when the MD5 has been verified, a response when it has been expanded and something saying it has been successful and the box is being rebooted.

ReddogTech

I updated to the latest snapshot and the wizard still does not work, see screenshot.

![Screen shot 2010-09-01 at 9.00.06 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 9.00.06 AM.png)
![Screen shot 2010-09-01 at 9.00.06 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 9.00.06 AM.png_thumb)

jimp

I don't think a new snapshot run has fully completed since the fix to the wizard went in.

As for the firmware progress, it's already stated where it's at, but the md5 happens so fast you don't see it. I don't think there's a way to do a progress indicator for the expansion, but feel free to open a feature request for that (but the target should be "Future" and not 2.0)

Can't really say much else about the routing issue without seeing the exact configs.

ReddogTech

Thanks heaps again jimp, please see attached screenshots.

![Screen shot 2010-09-01 at 10.55.57 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 10.55.57 AM.png_thumb)
![Screen shot 2010-09-01 at 10.55.57 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 10.55.57 AM.png)
![Screen shot 2010-09-01 at 10.55.46 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 10.55.46 AM.png)
![Screen shot 2010-09-01 at 10.55.46 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 10.55.46 AM.png_thumb)

jimp

What about the client config file? What's in it?

And do you have any client-specific-config setting defined for the client you're testing with?

And what about firewall rules? (Firewall > Rules, OpenVPN tab)

ReddogTech

Please see attached screenshots

![Screen shot 2010-09-01 at 11.02.21 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.21 AM.png)
![Screen shot 2010-09-01 at 11.02.21 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.21 AM.png_thumb)
![Screen shot 2010-09-01 at 11.04.07 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.04.07 AM.png)
![Screen shot 2010-09-01 at 11.04.07 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.04.07 AM.png_thumb)

ReddogTech

Please see attached screenshots. I have removed the IP from the OpenVPN client configuration.

![Screen shot 2010-09-01 at 11.02.43 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.43 AM.png)
![Screen shot 2010-09-01 at 11.02.43 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.43 AM.png_thumb)
![Screen shot 2010-09-01 at 11.02.48 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.48 AM.png)
![Screen shot 2010-09-01 at 11.02.48 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.48 AM.png_thumb)
![Screen shot 2010-09-01 at 11.02.53 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.53 AM.png)
![Screen shot 2010-09-01 at 11.02.53 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.02.53 AM.png_thumb)

ReddogTech

Please see attached screenshots

![Screen shot 2010-09-01 at 11.03.00 AM.png](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.03.00 AM.png)
![Screen shot 2010-09-01 at 11.03.00 AM.png_thumb](/public/imported_attachments/1/Screen shot 2010-09-01 at 11.03.00 AM.png_thumb)

jimp

The only two things that jump out at me are:

On the client, use a tun device, not tap.
On the client, uncheck enable DNS support unless you also enter an IP address for a DNS server (e.g. pfSense LAN IP.)

ReddogTech

Thank you very much!

I used the DNS support and the Tap interface because this is what we used on 1.2.3. We were advised to use this configuration by pfSense support. We continue to pay for support but would rather use the forums if we can get a quick answer, so others can see how to do it also.

Are there any issues with using the Tun device (instead of Tap) and not enabling DNS support?

jimp

It seems you may have been told to use tap so that multicast would function on the tunnel, but that can cause other issues.

If the server is also set for tap, it may work, but there isn't a selector for tap in the server GUI (yet).

ReddogTech

Thanks heaps again jimp!

We do use Apple Remote Desktop a bit so that is probably why they said to use tap instead of tun. Saying this, apple remote desktop does work over the connection I just setup based on your instructions. Thank You again!