OpenVPN Issues setting static ip for clients

echel0n

How do I apply this fix ?
Do I download another snapshot and if so which one ?

Is there a way that I can manually execute the resync ?

jimp

If you are on a recent snapshot, you can do a gitsync:

http://doc.pfsense.org/index.php/Updating_pfSense_code_between_snapshots

echel0n

How long does this gitsync usally take cause it's been going for the last 2 hrs?

jimp

Usually it's only a few minutes, unless it has to download and install the git packages, which can be very large.

echel0n

Maybe I'll wait for a snapshot release cause this either is taking forever to download what it needs (i've already done pkg_add -r git) or something is broken.

Any idea when a snapshot including this fix would come out ?

echel0n

Ok seems to be a problem with the gitSync, here's a copy and paste from my session with my pfsense box.


# pfSsh.php playback gitsync master

Starting the pfSense shell system................

===> Checking out master
Executing cd /root/pfsense//pfSenseGITREPO && git clone http://gitweb.pfsense.org/pfsense/mainline.git pfSenseGITREPO
error: Unable to get pack index http://gitweb.pfsense.org/pfsense/mainline.git/objects/pack/pack-6976d8687110e84632479ab82ceb69f93b40851e.idx

error: Unable to find 7d7992cd5b725e801e8979a4284a103b1803d5dc under http://gitweb.pfsense.org/pfsense/mainline.git
Cannot obtain needed object 7d7992cd5b725e801e8979a4284a103b1803d5dc
error: Fetch failed.
cd: can't cd to /root/pfsense//pfSenseGITREPO/pfSenseGITREPO
cd: can't cd to /root/pfsense//pfSenseGITREPO/pfSenseGITREPO
cd: can't cd to /root/pfsense//pfSenseGITREPO/pfSenseGITREPO
===> Installing new files...
cd: can't cd to /root/pfsense//pfSenseGITREPO/pfSenseGITREPO
===> Removing FAST-CGI temporary files...
===> Upgrading configuration (if needed)...
===> Restarting check_reload_status...
===> Configuring filter...
===> Running /etc/rc.php_ini_setup...
===> Locking down the console if needed...
===> Signaling PHP and Lighty restart...

Warning: Invalid argument supplied for foreach() in /usr/local/sbin/pfSsh.php(334) : eval()'d code on line 293
===> Checkout complete.

Your system is now sync'd and PHP and Lighty will be restarted in 5 seconds.

jimp

Hmm, I've not seen that happen before, personally.

There should be a snap out now that has the fixes in.

echel0n

Ok well I edited the file that you updated by hand and your right when I checked the client overrides they showed disabled so I re-enabled them and all seemed fine till I woke up this morning and found the client overrides AGAIN disabled.

Is there still a bug ?

jimp

I'd wait until you get a snapshot that has the fixes in it before passing judgment, to avoid the possibility of an error in applying the fixes by hand.

echel0n

ok I've applied the snapshot and will wait it out to see whats going to happen but I've run across a new issue now.

my vpn clients appear connected in but their common names show "UNDEF" and they don't show a virtual address, any reason this would happen?

jimp

Nothing I can see. It's possible the status format of openvpn changed recently, I believe the binary was updated to a new version in the last week or so.

echel0n

Actually this seems to ONLY happen when the client tries to connect using the ip address of WAN2 but if they use the ip address of WAN1 it's fine.
So is this a bug ?

jimp

Not sure on that one. Are you using a single OpenVPN instance on both WANs or two different ones?

echel0n

One OpenVPN instance on both WAN's yes.

jimp

If you are using UDP, that won't work without some NAT trickery (run it on LAN, port forward OpenVPN from both WANs to LAN IP)

It should work with TCP, but I've never tried it. It's possible that OpenVPN's internal status format shows differently for that, but I'd need to see its raw output to know for sure. If you have someone on both WAN and WAN2, try this:

From a shell:
#telnet localhost <openvpn port="" #="">And once that connects, put in:
status 2

And then copy/paste that output here.</openvpn>

echel0n

Ok I switched from UDP to TCP and all seems to be working perfectly now.
Sorry I did the switch before I read this post so I was unable to get the status like you wanted.