OpenVPN Issues setting static ip for clients
-
I'm having issues setting static ip's for my clients.
I've setup client-specific-overrides and added in ifconfig-push 192.168.2.21 192.168.2.22
Problem is that it keeps assigning 192.168.2.6 instead of 192.168.2.21 like it should.
Any solutions for this?
Is this maybe a bug?
-
Ok well here's a interesting find ….
I am able to create client-specific-overrides and I see the files get created in "/var/etc/openvpn-csc" properly and my clients get there static ip addresses I wanted them to but I'm finding that 24hrs later I come back and my client's ip's are diffrent and the files located in "/var/etc/openvpn-csc" have dissapeared.
Any reason for this and can it be fixed and how ?
P.S.
Also noticed that when the client config is created that it seems to write the advanced options area twice to the config.
-
I am not seeing any doubling of custom options on OpenVPN, and we have a couple customers using CSC entries on 2.0 in the field and if they were "disappearing" we would have had many (loud) complaints.
Was this config updated from 1.2.3?
Can you post the openvpn section of your config here?
-
Ok AGAIN the config files vanished as if there getting deleted by some sorta script that runs nightly and as a result my static ip's all became unassigned again. It's only the client configs from the "/var/etc/openvpn-csc" folder that seem to go missing cause when I go into pfsense admin panel and look at the client overrides there all there but just the files are missing.
This was a FRESH install of 2.0 and I updated to yesterdays latest snapshot and still this issue remains.
How would I post the openvpn section of my config ?
P.S.
What snapshot build are you running BTW ? Maybe mine has a bug?
-
Download a backup from Diagnostics > Backup/Restore and then just copy/paste the openvpn sections into a text file and then paste or attach it here.
I ask again about the doubling part because I am wondering if the "doubling" of the custom options might be related to the disappearances. And since I don't see the doubling happen, I may not see the disappearance either.
What type of WAN do you have? PPPoE or DHCP? Can you check your system log to see if you have a reconnection around the time that the CSC files disappear?
-
Here's the copy and paste from the config of the openvpn section, I've removed the TLS key data and changed any other info in it I found shouldn't be publicly viewed.
<openvpn><openvpn-server><vpnid>1</vpnid> <mode>server_tls</mode> <authmode>Local Database</authmode> <protocol>UDP</protocol> <ipaddr><interface>any</interface> <local_port>1194</local_port> <custom_options><caref>4bfeff58b2468</caref> <certref>4bfeff58cdd57</certref> <dh_length>1024</dh_length> <crypto>BF-CBC</crypto> <tunnel_network>192.168.2.0/24</tunnel_network> <remote_network><gwredir><local_network>192.168.1.0/24</local_network> <maxclients><compression>yes</compression> <passtos><client2client>yes</client2client> <dynamic_ip>yes</dynamic_ip> <pool_enable>yes</pool_enable> <netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></passtos></maxclients></gwredir></remote_network></custom_options></ipaddr></openvpn-server> <openvpn-csc><custom_options>ifconfig-push 192.168.2.21 192.168.2.22</custom_options> <disable><common_name>client1</common_name> <block><description><tunnel_network>192.168.2.21/30</tunnel_network> <gwredir><push_reset><netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></push_reset></gwredir></description></block></disable></openvpn-csc> <openvpn-csc><custom_options>ifconfig-push 192.168.2.13 192.168.2.14</custom_options> <disable><common_name>client2</common_name> <block><description><tunnel_network>192.168.2.13/30</tunnel_network> <gwredir><push_reset><netbios_enable><netbios_ntype>0</netbios_ntype></netbios_enable></push_reset></gwredir></description></block></disable></openvpn-csc> <openvpn-csc><custom_options>ifconfig-push 192.168.2.25 192.168.2.26</custom_options> <disable></disable> <common_name>client3</common_name> <description><tunnel_network>192.168.2.25/30</tunnel_network> <netbios_enable></netbios_enable> <netbios_ntype>0</netbios_ntype></description></openvpn-csc></openvpn>Also I did find in the config this:
<revision><time>1275408890</time> <username>admin</username></revision>I have WAN1 and WAN2 both which are DHCP.
In the system logs I do have see that rc.newwanip was executed on WAN1.
When I say "doubling" for the config directives I mean inside the actual csc files the custom option is being placed in it twice on 2 new lines.
-
Your doubling is because you are saying the same thing twice: You only need to specify the tunnel network there. Your custom option line is doing the exact same thing is as the tunnel network setting.
That shouldn't cause the disappearances, but I'll see if I can reproduce that again.
-
Ok you are correct as I removed the tunneling network setting and the doubling went away.
Now to resolve the vanishing client config files and we set :)
-
It should be fixed now. I never saw it because my IPs never change on the boxes that had OpenVPN CSC entries. The rc.newwanip call made it resync the CSC entries, and the resync function thought they were disabled.
I fixed the code to handle the "disabled" setting consistently, but that also means after your next update/gitsync they will all appear to be disabled. Just edit them all and uncheck disabled, then save, and it will be OK from then on.
-
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 ?
-
If you are on a recent snapshot, you can do a gitsync:
http://doc.pfsense.org/index.php/Updating_pfSense_code_between_snapshots
-
How long does this gitsync usally take cause it's been going for the last 2 hrs?
-
Usually it's only a few minutes, unless it has to download and install the git packages, which can be very large.
-
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 ?
-
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.
-
Hmm, I've not seen that happen before, personally.
There should be a snap out now that has the fixes in.
-
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 ?
-
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.
-
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?
-
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.
-
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 ?
-
Not sure on that one. Are you using a single OpenVPN instance on both WANs or two different ones?
-
One OpenVPN instance on both WAN's yes.
-
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 2And then copy/paste that output here.</openvpn>
-
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.
