Latest Snapshot screwed
-
There have been a number of OpenVPN fixes recently and it looks like the patch might have broken this.
I will pass this info along and see if we can get it fixed.
-
Hmmm, sounds weired…
Just added an option to chose a dynamic sourceport for the openvpn-client in pfsense (nobind-parameter).
If you do not use nobind it will be set to client id (0 for the first, 1 for the second, ...) plus 1194...Is your port 1194 occupied by pfsense already so that you cannot pass the traffic to the inside ?
so please let me know... i'll have a look if there's something that can be done... -
My VPN server is using port 1194 ..take in my my VPN server is behind the firewall and I am not using the pfsense OpenVPN server. It seems as if the OpenVPN configuration file 0 is binded to the 1194 port and even if I edit the VPN server with it with different port it is keeps the original one and just adds a new entry. the second one uses configurtion file 1 and so on. This seems to be a small bug like Sull was saying. I put the snapshot of 3-15 in and i dont have the bug. I will use that until a new release is done. This one seems to work fine …even the traffic shaper is good on the 3-15 snapshot.
As the bug is binding the 1194 port to the pre entry included with that snapshot my clients try to connect and naturally they get it trying to connect to the pre ovpn entry. I get cert does not match errors which is good proof of this.
I personally feel OpenVPN shoudl be taken out of PfSense. It was attempted in m0n0wall but you can see m0n0wall no longer has it. It doesnt take but 30 minutes to load a OS on and configure and get Ovpn running on its own box. After you get to know it the software is highly simplistic. Also the ovpn is always going to be limited on the routers. No offense to anyone!
Hey guys at PfSense keep up the good work. I will be deploying this router with 3.15 snap tomarrow in a pure Asterisk VoIP environment.
-
So i understand and will have a look after this…
i do not think it should be taken out of pfsense because it can be used really good for endpoint tunneling purposes... -
It seems as if the OpenVPN configuration file 0 is binded to the 1194 port and even if I edit the VPN server with it with different port it is keeps the original one and just adds a new entry. the second one uses configurtion file 1 and so on.
Can you rephrase? I just can't understand what you mean.
When you say that configuration file 0 is bound to port 1194, do you mean that the client configuration for the first tunnel (i.e., openvpn_client0.conf) says "lport 1194"? If that's the case, you probably forgot to set the option "Use dynamic port". If you're talking about a server config, then you obviously have to change the local port if you need to use a different one.
I personally feel OpenVPN shoudl be taken out of PfSense. It was attempted in m0n0wall but you can see m0n0wall no longer has it. It doesnt take but 30 minutes to load a OS on and configure and get Ovpn running on its own box. After you get to know it the software is highly simplistic. Also the ovpn is always going to be limited on the routers. No offense to anyone!
No, not really, it should not be taken out. In almost every support request it's just the user doing something stupid. Either that or enhancement requests (we can not try to support every option OpenVPN supports, so we have to add the most popular options gradually). Only in a few cases we find a real bug.
OpenVPN was removed from m0n0wall for completely different reasons. The OpenVPN implementation there (as well as the initial pfSense implementation) relied on complex logic to make it possible to assign "friendly" interfaces (i.e., OPTx) to the VPN interfaces (so that it's possible to filter the tunnel interface), and we didn't have sufficiently robust logic to handle those dynamic interfaces back then (and I don't think we do now, anyways), and always ended up with a broken pf ruleset.
-
I personally feel OpenVPN shoudl be taken out of PfSense. It was attempted in m0n0wall but you can see m0n0wall no longer has it. It doesnt take but 30 minutes to load a OS on and configure and get Ovpn running on its own box. After you get to know it the software is highly simplistic. Also the ovpn is always going to be limited on the routers. No offense to anyone!
Have you reviewed both their version of OpenVPN and ours? If not then you should before making blanket statements such as this. Fernando rewrote our implementation from SCRATCH.
-
I checked out and reinstalled my systems from scratch and just cannot rebuild this error…
If there is no openvpn config (client or server) available in openvpn-menu in pfsense, openvpn ports are not bound (please crosscheck with "sockstat" in the shell)
Because you said
As the bug is binding the 1194 port to the pre entry included with that snapshot my clients try to connect and naturally they get it trying to connect to the pre ovpn entry. I get cert does not match errors which is good proof of this.
I just asked me what predefined entried you are talking about… there are none by default...
Perhaps you're talking about non editable entries in the openvpn-gui ?
I also had this error, it's a messed up config.xml, you have to clean up this and restore the config on a recent snapshot, then it should work...
with my config-file it was like messed up entries in the openvpn-area...Could you please check this ?
-
I've seen things like this. It's indeed a corrupted config.xml. I have no idea of what it might be, but it's not related to OpenVPN, but rather to the rendering engine (OpenVPN is a XML-based interface). It's hard to reproduce this bug, so any info about tips on how to reproduce it are appreaciated.
If you just want to solve the issue, take a look at your config.xml file. There should be a blank client (or server) configuration tag. Get rid of it, then remove /tmp/config.cache and reboot if you changed it directly, or restore it if you downloaded it from the "Backup/Restore" screen.
-
I've seen things like this. It's indeed a corrupted config.xml. I have no idea of what it might be, but it's not related to OpenVPN, but rather to the rendering engine (OpenVPN is a XML-based interface). It's hard to reproduce this bug, so any info about tips on how to reproduce it are appreaciated.
If you just want to solve the issue, take a look at your config.xml file. There should be a blank client (or server) configuration tag. Get rid of it, then remove /tmp/config.cache and reboot if you changed it directly, or restore it if you downloaded it from the "Backup/Restore" screen.
Fernando, your mixing up two different OpenVPN issues. This is not the blank configuration entry issue.
-
Uh oh heh, nevermind. ;D