After upgrade to 2.1.2 OpenVPN interface don't up
-
Yes, I discovered that fat-fingers typo when playing with 2.2.
Anyway, good to know that the functional side of ermal's fixes is working, once the fat fingers are removed from the equation ;) -
same problem here, what can i do ?
-
Look at the changes on 2.1 branch from (and including) 10 April 2014. Those are things that have been done since 2.1.2-RELEASE came out:
https://github.com/pfsense/pfsense/commits/RELENG_2_1For this OpenVPN with bridges… problem, I think you need to make the changes from 3 commits:
- Take care of the loops reported for OpenVPN in tap mode https://github.com/pfsense/pfsense/commit/f96b9a1830ee2b08c142207ebfa4f695d0628853
- Forgot to remove the problematic part from previous OpenVPN loop fix https://github.com/pfsense/pfsense/commit/1f43ccf5539126254efa509e087133b522ee264f
- Fix typo https://github.com/pfsense/pfsense/commit/c58dbe2fa836d26e3cf4a2077a4b6d398edc763f
Maybe you can use the System Patches package to apply all 3?
-
I rolled the relevant commits into one patch file here:
http://files.pfsense.org/jimp/patches/openvpn-tapbridgefix-2.1.x.diff
You can use that with the system patches package.
-
I rolled the relevant commits into one patch file here:
http://files.pfsense.org/jimp/patches/openvpn-tapbridgefix-2.1.x.diff
You can use that with the system patches package.
Hello
Im newbie here, How do I update with this file?
Thanks
Q -
http://doc.pfsense.org/index.php/System_Patches
-
thank for the support, I have simply copy the new version of rc.newwanip and now everything works.
I would like to ask a more general question about the organization of update in an open source project like pfsense.
For example, now there is this bug on openVPN files, and in github it is fixed but officially I don't receive any patch until the next release right ? what are the criteria commonly use to consider a release stable ? is "release management" the right word to describe this process ? -
It's not quite so complex. A release … has been released. That's really its only distinction. It's been tested fairly thoroughly for common issues and configurations but not all corner cases -- yet.
There aren't really any concrete qualifications for it to be called "stable" -- There is a bug, yes, but it impacts a very low number of users. If it were a huge bug that affected many users, it may warrant another release.
-
Also encountered the issue… took me a while before I figured out what was going on (updating multiple systems at once (not only pfSense) adds a lot of variables... lessons learned here ::) )
I installed the code changes by hand, but for sure going to try the system patches next time (another something learned)Tnx all...
-
@ Jimp
I know this is almost hijacking the thread, but as it is related… I tried to apply it as a system patch, feching works but the test gave me these results:Output of full patch apply test:
/usr/bin/patch –directory=/ -t -p1 -i /var/patches/534e74ea334a2.patch --check --forward --ignore-whitespaceHmm... Looks like a unified diff to me...
The text leading up to this was:|diff --git a/etc/rc.linkup b/etc/rc.linkup
|index 1994336..b39f876 100755
|--- a/etc/rc.linkup+++ b/etc/rc.linkup Patching file etc/rc.linkup using Plan A... Hunk #1 succeeded at 60. Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/etc/rc.newwanip b/etc/rc.newwanip
|index 2fa450c..201f085 100755
|--- a/etc/rc.newwanip+++ b/etc/rc.newwanip Patching file etc/rc.newwanip using Plan A... Hunk #1 succeeded at 62. Hunk #2 succeeded at 70. Hunk #3 succeeded at 113. Hunk #4 succeeded at 184. Hmm... The next patch looks like a unified diff to me... The text leading up to this was:
|diff --git a/etc/rc.newwanipv6 b/etc/rc.newwanipv6
|index 92fe5ea..177e645 100755
|--- a/etc/rc.newwanipv6+++ b/etc/rc.newwanipv6 Patching file etc/rc.newwanipv6 using Plan A... Hunk #1 succeeded at 59. Hunk #2 succeeded at 69. Hunk #3 succeeded at 81. Hunk #4 succeeded at 106. Hunk #5 succeeded at 147. done As it also states this:
Patch can be applied cleanly (detail)
Patch can NOT be reverted cleanly (detail)and I am unfamiliar with patches (for now, learning here ;) ) it seemed a better idea to ask if that is ok & safe to apply?
-
If the "apply" button shows, it can be applied safely.
The test shows that the apply action would work. ("Patch can be applied cleanly (detail)")
-
Right. (I was already afraid it was a noob question ???)
Applied & so far it doesn't complain. Tnx once more… -
I rolled the relevant commits into one patch file here:
http://files.pfsense.org/jimp/patches/openvpn-tapbridgefix-2.1.x.diff
You can use that with the system patches package.
This fixed it for me. Thanks a lot. Anyone know if this fix will be rolled into a later version?
-
The fix is already in for 2.2
IFF there is another security issue that necessitates another 2.1.x release it will be in there also, but unless something like that comes up the next release will be 2.2.
-
Just a quick +1
I upgraded my pfSense boxens to 2.1.2 and encountered this bug. Applied Jim's patch with System Patches package, and is working flawlessly.
Thank you, thank you, thank you.
-
Can anyone confirm if this fix is included in the latest 2.1.3 security release? I didn't see specific mention of this in the changelog.
Thanks to the hard work of the whole pfSense team.
-
It should be there in 2.1.3, yes. In the release notes it's actually mentioned but as a fix for OpenVPN and other interfaces looping.
-
It should be there in 2.1.3, yes. In the release notes it's actually mentioned but as a fix for OpenVPN and other interfaces looping.
I had this issue (but just worked around it a different way) and I can confirm that when we upgraded all 3 of our boxes to 2.1.3 it has been resolved.
-
Is there fix for 2.1.3 ? I've made TUN bridge but vpn gateway is down.
