After upgrade to 2.1.2 OpenVPN interface don't up

LittleGreenMan

Hi to all.
After upgrade from 2.1 to 2.1.1 and tonight to 2.1.2 i have strange problem:
ovpnc1 interface after reboot or restart always has state DOWN.

ovpnc1: flags=8942 <broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
        options=80000 <linkstate>ether 00:bd:13:55:00:01
        Opened by PID 96032</linkstate></broadcast,running,promisc,simplex,multicast>

if it up from shell or from GUI resave interface (Interfaces->MSKVPN(it assigned interface to ovpnc1)->SAVE) all working as needed till reboot / reconnect OpenVPN.
Strange that i also have ovpnc2 with has up state always

ovpns2: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
        options=80000 <linkstate>inet6 fe80::205:5dff:fe33:f602%ovpns2 prefixlen 64 scopeid 0xb 
        nd6 options=1 <performnud>Opened by PID 11431</performnud></linkstate></up,pointopoint,running,multicast>

My Net config:
WAN
LAN
ovpnc1 (assigned MSKVPN) as client of site to site OpenVPN
Bridge0 members LAN & ovpnc1 (historically it was 1 network 192.168.100.0/24 with was divided between 2 cities)
ovpnc2 as server for Roadwarrior.
Best regards,
Konstantin.
P.S. sorry for my English.

jwsmiths

Same problem here!

ChristOff

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 work

The problem doesn't happen with vpn tun with shared key to another location

It began with 2.1.1

saftig

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

jwsmiths

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.

LittleGreenMan

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.

phil.davis

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.

saftig

@phil.davis:

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.

saftig

After Phil's typo fix this morning I can report that it's running flawlessly so far! https://github.com/pfsense/pfsense/commit/c58dbe2fa836d26e3cf4a2077a4b6d398edc763f

phil.davis

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 ;)

simi8

same problem here, what can i do ?

phil.davis

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_1

For 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?

jimp

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.

quyda

@jimp:

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

jimp

http://doc.pfsense.org/index.php/System_Patches

simi8

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 ?

jimp

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.

bennyc

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...

bennyc

@ 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-whitespace

Hmm... 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?

jimp

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)")

After upgrade to 2.1.2 OpenVPN interface don't up

workaround for openvpn

Hmm... Looks like a unified diff to me... The text leading up to this was:

Hmm... Looks like a unified diff to me...
The text leading up to this was: