OpenVPN and 1.0-BETA1
-
Okay, I need to clarify a few things, as I've seriously muddied the waters here. My config is as follows:
Stock 1.0-BETA1, now installed to hard disk.
Modified util.inc to allow tun interfaces to be detected.
Modified filter.inc, again, to allow tun interfaces not to filtered from aliases generation.Created /usr/local/etc/rc.d/openvpn.sh, then when run from rc with "start" appended (as with normal freebsd rc.d stuff) starts all of my tunnels (all one of them at this point).
Everything seems to be humming along fine. I haven't attempted to apply the patches that were posted to this thread yet. I was just doing an independent dig-through of what was required to get openvpn to run from the console, hoping that my conclusions would help.
(After going back and reading the recent posting barrage….)
Do I need to make an additional modification to prevent the tunnel from going down upon a reload? It seems you adjusted an rc script to do this....
It appears we all more or less wound up in the same place, albeit that he's starting openvpn the "right" way, and I'm not. ;)
So the next step is for me to use his patch and set it up the right way. Won't happen today, perhaps later this week though?
-
I'm debating as to whether I have time to mess with this tonight or not. I have an extra net4501 laying here that's taunting me.
What issues are left after all of the patches are applied in this thread? Is it stable enough to make 1.0 final (without the developer tag)?
-
Do I need to make an additional modification to prevent the tunnel from going down upon a reload? It seems you adjusted an rc script to do this….
Hi,
I had to modify the rc.reload_interfaces.inc script to restart openvpn:
In certain cases (I don't remember now), when pf needs to restart (and reload all interfaces) the openvpn and the tun0 interface would still be running, but no connections are being accepted any more. The system log also doesn't reveal any openvpn activity at this point.
It seems reasonable to reload the tun interface (thus restart openvpn) when pfsense needs to reload all other interfaces, so I would have come to this point either way. ;)You said, that openvpn would also reload on changing of firewall rules on the tun0 interface.
I'll check this the next few days and keep you informed!Marc
-
I'm debating as to whether I have time to mess with this tonight or not. I have an extra net4501 laying here that's taunting me.
What issues are left after all of the patches are applied in this thread? Is it stable enough to make 1.0 final (without the developer tag)?
About stability:
Since I only did some modifications to some scripts in order to get openvpn up and running without using the shell, it is as stable as it would be when you configure openvpn on pfsense manually.
I've got it running for about 1 month on a WRAP box, which has already suffered from several power losses, but always came up cleanly without any problems. I also cannot tell much about how many users it will get along with, as I am the only user. :)My configuration uses certificates, the tun interface type and TCP on port 443. Never had any problems, never tried anything else.
If you'd like to know my TODO-list, here it goes:
Fixes:
- check out the "restart-problem" you've told me.
- check out the "interface renumbering" bug and maybe look at the interface renumbering code in HEAD (thx @sullrich for the hint!), then decide whether to live with it or change it.
- find out the reason why TUN0 does not show up in the "Interfaces" menu.
Features (seem to be just webinterface issues):
- get OpenVPN in client mode working.
- get the "Client-specific configuration" working.
- get CRL lists working.
One thing I've learnt for now: I'll do all future changes inside a VM ;)
Anything else left?
Marc
-
Oh, and one feature I'd like which I forgot: get the syslog messages regarding openvpn into a separate tab!
just a side note: would you believe me that I did most of the coding on a VT420 terminal? ;D
-
I got it to work after using ecca's patches.
The only thing I had to fix manually is that $d_ovpnsrvdirty_path is defined nowhere. So, I just added an entry for it on guiconfig.inc (where we usually put those definitions to dirty files). The problem in doing so is that guiconfig.inc can't be included from openvpn.inc, since it's on /usr/local/www, and that makes you need authorization to include it, apparently. So, temporarily, I just defined $d_ovpnsrvdirty_path in openvpn.inc. I wonder if there's a more elegant way to do that?
Now on to the client…
-
Oh, and one feature I'd like which I forgot: get the syslog messages regarding openvpn into a separate tab!
just a side note: would you believe me that I did most of the coding on a VT420 terminal? ;D
Not a problem. I'll work on this.
-
The only thing I had to fix manually is that $d_ovpnsrvdirty_path is defined nowhere.
See /etc/inc/globals.inc…it should be there. I know - maybe it's not at the right place there, but it worked.
-
I moved it to guiconfig.inc which houses all of the other dirty file locations.
-
_If you'd like to know my TODO-list, here it goes:
Fixes:
- check out the "restart-problem" you've told me._
Was addressed earlier in this thread, and in the patch.
- check out the "interface renumbering" bug and maybe look at the interface renumbering code in HEAD (thx @sullrich for the hint!), then decide whether to live with it or change it.
Still pending?
- find out the reason why TUN0 does not show up in the "Interfaces" menu.
This was addressed. There were modifications required for get_interface_list().
_Features (seem to be just webinterface issues):
- get OpenVPN in client mode working.
- get the "Client-specific configuration" working.
- get CRL lists working._
All of these are still outstanding as far as I know.
-
I moved it to guiconfig.inc which houses all of the other dirty file locations.
But this definition is needed by openvpn.inc. If openvpn.inc includes guiconfig.inc, wouldn't that make openvpn.inc require the user to authenticate? Cause openvpn.inc shouldn't require authentication, since it won't be called solely by the web interface, but also by the boot scripts.
-
Try it out and let me know. Thats how the rest of pfSense works.
-
WOW ;D
on 1.0-BETA1-TESTING-SNAPSHOT-2-5-06 the openvpn acting as a client is working for me. Thank you very much.kind regards,
-
So that leaves, what the interface renumbering bug in HEAD, right?
Looks like we may have OpenVPN in 1.0 yet. ;)
-
Yep let me backport it and post a testing image. Can you guys help me test this? It will involve deleting and recreating interfaces and ensuring that the rules and such follow the interfaces.
-
I'm game. I have a net4501 sitting here waiting to be abused, along with a WRAP coming in the mail, and a production box I bought from Hacom (good reference from around here!) with 3 gigabit interfaces. All of which I can do some testing on.
Bring it. ;)
-
on 1.0-BETA1-TESTING-SNAPSHOT-2-5-06 the openvpn acting as a client is working for me
No, it isn't. :S
Did you patch it? I tested it in an unpatched BETA1 and it screwed up the interfaces' configuration.
-
on 1.0-BETA1-TESTING-SNAPSHOT-2-5-06 the openvpn acting as a client is working for me
No, it isn't. :S
Did you patch it? I tested it in an unpatched BETA1 and it screwed up the interfaces' configuration.
Yep, thats the thing we are speaking of that needs to be backported. When you mess with the optional interfaces and move them around then the rules end up on the wrong optional interfaces, etc.
-
WRAP showed up today, so I have two embedded's to play around with. The hard drive-based production box should be here any day now. Just waiting. :)
-
Sounds good. I'll get the code merged over tomorrow sometime in preperation for some serious weekend testing.