Rilo Ravestein
Neophyte Sage
- Joined
- Mar 6, 2014
- Messages
- 685
Patience i have. Check my occupation.Shell scripting is coolawesome but doing it well takes lots of patience.
Patience i have. Check my occupation.Shell scripting is coolawesome but doing it well takes lots of patience.
echo "This is a test" > /temp.txt
openvpn_enable="YES" openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf" firewall_enable="YES" firewall_script="/mnt/media/ipfw.rules"
The usual reason is a poorly written script, often something like the environment. For example, ipfw is in /sbin/, so if you aren't setting up your PATH explicitly in the script or calling it by fully qualified path, it's a crapshoot as to whether or not your command ends up in that sometimes-omitted directory.When the jail start, the script gets called in /etc/rc.conf:
Code:openvpn_enable="YES" openvpn_configfile="/usr/local/etc/openvpn/openvpn.conf" firewall_enable="YES" firewall_script="/mnt/media/ipfw.rules"
When i start the firewall manually, i use /etc/rc.d/ipfw (re)start
What happens, is what i described in my previous post. I really don't get why the script is handled differently.
#! /bin/sh - PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin; export PATH set -e
( your-stuff-in-here ) >> /tmp/myscript.out 2>> /tmp/myscript.err
By the way, what happens if there are two devices matching "vpn"? Use "grep -m 1" and maybe a better ifconfig incantation to help more precisely aim your data acquisition.I think i get it:
Code:IP1="ifconfig | grep 'vpn' | cut -d" " -f4" add 05000 allow ip from ${IP1} to any
Going to test some stuff when i get home :)
EDIT: Not sure if that will work, seeing all the " marks in the first line....
I can only have 1 VPN connection, just connection to 1 server / 1 IP at a time as far as i know, but i'll be sure to try out what you suggestedBy the way, what happens if there are two devices matching "vpn"? Use "grep -m 1" and maybe a better ifconfig incantation to help more precisely aim your data acquisition.
As you can see, i only use complete paths in my script, so i don't think that's the problem. Here is my script so far:... often something like the environment. For example, ipfw is in /sbin/, so if you aren't setting up your PATH explicitly in the script or calling it by fully qualified path, it's a crapshoot as to whether or not your command ends up in that sometimes-omitted directory.
#!/bin/sh fwcmd="/sbin/ipfw" ${fwcmd} -f flush IP2="$(/sbin/ifconfig | grep 'inet 10' | cut -d" " -f4)" n=0 echo "${n}" + "${IP2}" > /mnt/media/ipfwscript.log until [ "$IP2" != "" ] || [ $n -ge 10 ] do sleep 5 IP2="$(/sbin/ifconfig | grep 'inet 10' | cut -d" " -f4)" let n=$n+1 echo "${n}" + "${IP2}" >> /mnt/media/ipfwscript.log done IP1="$(/sbin/ifconfig | grep 'inet 10' | cut -d" " -f2)" echo "${n}" + "${IP1}" >> /mnt/media/ipfwscript.log ${fwcmd} add 01000 allow log udp from 192.168.2.0/24 to xxx.xxx.xxx.xxx dst-port 53 keep-state ${fwcmd} add 01002 allow log udp from 192.168.2.0/24 to xxx.xxx.xxx.xxx dst-port 53 keep-state ${fwcmd} add 01006 allow ip from 192.168.2.0/24 to 192.168.2.0/24 keep-state ${fwcmd} add 02000 allow ip from 192.168.2.0/24 to xxx.xxx.xxx.xxx keep-state ${fwcmd} add 04000 allow ip from 127.0.0.1 to any ${fwcmd} add 05000 allow ip from "${IP1}" to any ${fwcmd} add 05002 allow ip from any to "${IP1}" ${fwcmd} add 05004 allow ip from "${IP2}" to any ${fwcmd} add 05006 allow ip from any to "${IP2}" ${fwcmd} add 65534 deny ip from any to any
0 + 1 + 2 + 3 + xxx.xxx.xx1 3 + xxx.xxx.xx2
0 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 10 +
#!/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin; export PATH set -e ( #set -x fwcmd="/sbin/ipfw" ${fwcmd} -f flush IP2="$(/sbin/ifconfig | grep 'inet 10.' | cut -d" " -f4)" n=0 until [ "$IP2" != "" ] || [ $n -ge 5 ] do sleep 5 IP2="$(/sbin/ifconfig | grep 'inet 10.' | cut -d" " -f4)" let n=$n+1 done IP1="$(/sbin/ifconfig | grep 'inet 10.' | cut -d" " -f2)" ${fwcmd} add 01000 allow log udp from 192.168.2.0/24 to xxx.xxx.xxx.xxx dst-port 53 keep-state ${fwcmd} add 01002 allow log udp from 192.168.2.0/24 to xxx.xxx.xxx.xxx dst-port 53 keep-state ${fwcmd} add 01006 allow ip from 192.168.2.0/24 to 192.168.2.0/24 keep-state ${fwcmd} add 02000 allow ip from 192.168.2.0/24 to xxx.xxx.xxx.xxx keep-state ${fwcmd} add 04000 allow ip from 127.0.0.1 to any if [ "$IP2" != "" ]; then ${fwcmd} add 05000 allow ip from "${IP1}" to any fi if [ "$IP2" != "" ]; then ${fwcmd} add 05002 allow ip from any to "${IP1}" fi if [ "$IP2" != "" ]; then ${fwcmd} add 05004 allow ip from "${IP2}" to any fi if [ "$IP2" != "" ]; then ${fwcmd} add 05006 allow ip from any to "${IP2}" fi ${fwcmd} add 65534 deny ip from any to any #set +x ) > /mnt/media/script.out 2> /mnt/media/script.err
Flushed all rules. 1 2 3 4 5 01000 allow log udp from 192.168.2.0/24 to xxx.xxx.xxx.xxx dst-port 53 keep-state 01002 allow log udp from 192.168.2.0/24 to xxx.xxx.xxx.xxx dst-port 53 keep-state 01006 allow ip from 192.168.2.0/24 to 192.168.2.0/24 keep-state 02000 allow ip from 192.168.2.0/24 to xxx.xxx.xxx.xxx keep-state 04000 allow ip from 127.0.0.1 to any 65534 deny ip from any to any
rc.conf doesn't kick off applications. It is technically a shell script but its role in life is to be a place to set variables for the rc subsystem.rc.conf will kick off your applications but it doesn't wait for one to complete before starting another one. I believe the issue is OpenVPN isn't started when your kicking off your firewall rules script.
See immediately preceding comment.Strange... If you look at the lines, OpenVPN is started before the firewall, or at least this comes first in rc.conf.
OpenVPN is certainly able to allow a hook for a shell script when various important things happen, such as a session coming up or going down. This is managed within the OpenVPN configuration.Maybe i should be looking into scheduling a cron job. I have no idea on how OpenVPN could be the trigger somehow. If there is a way however, OpenVPN might also be a trigger i could use to run a script when the config (IP) would change.
Did a little reading on the rc subsystem. Found somthing interesting here.rc.conf doesn't kick off applications. It is technically a shell script but its role in life is to be a place to set variables for the rc subsystem.
I don't think you're on a good track, no. Part of the problem is that the rc system is part of the base system and therefore changes made to it are not persistent across upgrades/updates. However, another aspect is that the rc system would not guarantee that OpenVPN is actually up and had actually plumbed the interfaces at the point that the next dependent rc script boots; it merely guarantees that it has been kicked off.Did a little reading on the rc subsystem. Found somthing interesting here.
If i find out which conditions the VPN startup script provides in rc.d (or add them myself), i could use those to require them in the firewall startup script in rc.d to make sure it is kicked. The loop and sleep in my firewall rules script (the one above) will then take care to wait for the vpn tunnel to come up.
Am i on the right track here?
I don't understand. The OpenVPN installation survives an upgrade/update, so if i change something on the OpenVPN startup script, why wouldn't this survive?I don't think you're on a good track, no. Part of the problem is that the rc system is part of the base system and therefore changes made to it are not persistent across upgrades/updates.
If i can kick the OpenVPN service before the firewall is kicked, the firewall rules script takes care of waiting until the tunnel is actually up.However, another aspect is that the rc system would not guarantee that OpenVPN is actually up and had actually plumbed the interfaces at the point that the next dependent rc script boots; it merely guarantees that it has been kicked off.
I think you are on the right track, find out what OpenVPN can provide you in order to trigger the firewall rules script. You won't even need to have the firewall script in the rc.conf file which is actually nice. It would be ideal if OpenVPN set out an event each time the IP address changes or is valid/not valid. I have no idea what OpenVPN can do but good luck!
Wow, that's really helpful! Seems like the best solution here actually. Only problem is, that when the VPN connection does'nt come up, the firewall doesn't start. Alhough, i could start the firewall blocking all but the VPN service IP (which is fixed) and have a script change the rules after OpenVPN starts. I can now even let OpenVPN run a script if the IP changes, like you guys suggested earlier (which i thought would still maybe a bit too difficult for me to handle) :)What you're actually best pursuing is one of the OpenVPN script hooks, such as "up" or "down". A Linux-oriented discussion of that is http://askubuntu.com/questions/28733/how-do-i-run-a-script-after-openvpn-has-connected-successfully but is largely relevant on FreeBSD. I can't really help you a ton more than that, because while we make extensive use of OpenVPN and scripts here, pretty much every other aspect here is different ... we don't run it on FreeNAS, we don't run tun devices, etc.
I have no idea how OpenVPN is implemented on FreeNAS. However, I do know that the architecture of the system is such that the base system is treated as a firmware image. If OpenVPN has been stuck inside a jail or something similar, that would survive firmware updates, but then introduces other complications, such as that I don't believe ipfw is supported from within jails, which means you'd need to ssh to the host system. Basically I know less about OpenVPN on FreeNAS than you do. Take that for whatever it is worth.Not to question your knowledge at all jgreco, but i do have some concerns/questions (or maybe i just don't understand correctly):
I don't understand. The OpenVPN installation survives an upgrade/update, so if i change something on the OpenVPN startup script, why wouldn't this survive?
Bearing in mind that we very much frown upon placing a FreeNAS in any environment where it is visible to a situation where a firewall is required, I will note that you can set up a hook in FreeNAS to call a script upon system startup. It's somewhere under the system menu, I believe. You can put general stuff in there and then have a set of up/down scripts for OpenVPN that add/subtract specific functionality. Do not forget the down script; you do not want a hundred sequential OpenVPN sessions adding a hundred firewall rules ;-)If i can kick the OpenVPN service before the firewall is kicked, the firewall rules script takes care of waiting until the tunnel is actually up.
Wow, that's really helpful! Seems like the best solution here actually. Only problem is, that when the VPN connection does'nt come up, the firewall doesn't start. Alhough, i could start the firewall blocking all but the VPN service IP (which is fixed) and have a script change the rules after OpenVPN starts. I can now even let OpenVPN run a script if the IP changes, like you guys suggested earlier (which i thought would still maybe a bit too difficult for me to handle) :)