After upgrade to 2.1.2 OpenVPN interface don't up
-
Same problem here!
-
Same problem too (vpn tap with certificate + bridge)
The vpn connects correctly (from logs either client and server side), but no traffic passes through it as interface is down.
Going to the interface properties hitting save makes it workThe problem doesn't happen with vpn tun with shared key to another location
It began with 2.1.1
-
If I recall correctly it has something to do with a timing issue at bootup. The bridge is applied before the interfaces are started when the bridge needs to be applied after the interfaces have been initialized. Someone on the forums have already found a temporary work-around but not having the issue in the first place would be preferable. https://forum.pfsense.org/index.php?topic=74625.0
-
I think this has to do with an error in the tap driver - that's my guess b/c I haven't restarted my pfsense box. The openvpn tap interface was created and then a bridge was added and after I tried to connect from my MacBook via my iPhone over LTE the interface went down and won't come up again w/o restart - but then once it does I try to connect and it crashes again.
-
Hi.
I don't know what caused problem.
at this time i'm using workaround with sh script which check every minute if ovpnc1 interface is up/down then check working connections to other side and then doing up OpenVPN interface.cat /usr/local/bin/openvpn_autoup.sh```
#!/bin/sh
workaround for openvpn
#check if it already up
if /sbin/ifconfig ovpnc1 | grep UP > /dev/null 2>&1 ; then#nothing to do
else
#check inernet is up
if /sbin/ping -c2 -t5 XXXXX.linkpc.net >/dev/null 2>&1 ; then
/sbin/ifconfig ovpnc1 up
fi
fi+ add cron rule: cat /etc/crontab``` cat /etc/crontab SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin HOME=/var/log #minute hour mday month wday who command # # # pfSense specific crontab entries # Created: April 12, 2014, 5:36 pm # 1,31 0-5 * * * root /usr/bin/nice -n20 adjkerntz -a 1 3 1 * * root /usr/bin/nice -n20 /etc/rc.update_bogons.sh */60 * * * * root /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 sshlockout 1 1 * * * root /usr/bin/nice -n20 /etc/rc.dyndns.update */60 * * * * root /usr/bin/nice -n20 /usr/local/sbin/expiretable -v -t 3600 virusprot 30 12 * * * root /usr/bin/nice -n20 /etc/rc.update_urltables #my rule to check openvpn */1 * * * * root /usr/local/bin/openvpn_autoup.sh # # If possible do not add items to this file manually. # If you do so, this file must be terminated with a blank line (e.g. new line) #Best regards,
Konstantin.
P.S. sorry for my english. -
Maybe ermal has had a go at fixing this by the commits on 12 April 2014 - https://github.com/pfsense/pfsense/commits/RELENG_2_1
Those are since the 2.1.2 release.
Someone could try applying those changes and report if their system is happy. -
Maybe ermal has had a go at fixing this by the commits on 12 April 2014 - https://github.com/pfsense/pfsense/commits/RELENG_2_1
Those are since the 2.1.2 release.
Someone could try applying those changes and report if their system is happy.Applied and still not working, I made sure to check twice that everything was in order. Saving either the OpenVPN-interface or the bridge gets the interface up and running again, just like before.
-
After Phil's typo fix this morning I can report that it's running flawlessly so far! https://github.com/pfsense/pfsense/commit/c58dbe2fa836d26e3cf4a2077a4b6d398edc763f
-
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…
