AntonK
Very Senior Member
?This has to be a joke. Garbage in garbage out.
?This has to be a joke. Garbage in garbage out.
Yes. This current thread is the thread I was referring to in that post.Hi Merlin as you've mentioned in http://www.snbforums.com/threads/vp...r-client-versus-centralized.72907/post-694570
Are we still on that schedule ?
Thank you.
AF_INET is not a variable, it's just the protocol type used internally.What I remeber is this variable don't get set:
UDP link remote: [AF_INET]217.64.148.60:1194
Yes, I have tested and I get variables and openvpn-event get triggered but that not calling my script.AF_INET is not a variable, it's just the protocol type used internally.
I just created an openvpn-event script that dumped the env vars to a file, and it was working fine for me, the OpenVPN env vars were defined.
The problem is most likely with your script itself.
This looks more like an issue in how you have your scripts setup than an issue with VPN Director. How do you have your scripts configured? What do your scripts contain? We'll need more info about your specific setup.Yes, I have tested and I get variables and openvpn-event get triggered but that not calling my script.
I have them under /jffs/script/myscript.sh I don't know why at the moment.
A (maybe) stupid question: VPN Director has a business only with OpenVPN client, isn't it? Or also messes with OpenVPN Server?
d516f7b904 webui: renamed "Policy Rules" for "VPN Director" on OpenVPN client dropdown; updated help popup
0a55e79998 libovpn: handle DNS exclusive iptable rules separately, and refresh them on vpnrouting events
Thanks.This looks more like an issue in how you have your scripts setup than an issue with VPN Director. How do you have your scripts configured? What do your scripts contain? We'll need more info about your specific setup.
seems openvpn-event is working and the error is in my script, but I can't find why.#!/bin/sh
/usr/bin/logger -st "Started openvpn-event script "$@""
/usr/bin/logger -st "environment" "${script_type}" "${common_name}" "${trusted_ip}" "${trusted_port}"
scr_name="$(basename "$0")[$$]"
# Determine caller
case "$1" in
"tun11") vpn_name="client1";;
"tun12") vpn_name="client2";;
"tun13") vpn_name="client3";;
"tun14") vpn_name="client4";;
"tun15") vpn_name="client5";;
"tun21") vpn_name="server1";;
"tun22") vpn_name="server2";;
*) vpn_name="";;
esac
# Call appropriate script based on script_type
vpn_script_name="vpn$vpn_name-$script_type"
vpn_script_log="/tmp/vpn${vpn_name}_state"
# Check script state
vpn_script_state=$(cat $vpn_script_log 2>/dev/null)
if [ "$vpn_script_name" = "$vpn_script_state" ]; then
echo " ***VPN script" $vpn_script_name "already run" | logger -t "$scr_name"
exit 0
fi
# Execute and log script state
if [[ -f "/jffs/scripts/$vpn_script_name" ]]; then
echo " Script executing.. for VPN event: "$vpn_script_name | logger -t $scr_name
echo "$vpn_script_name" > $vpn_script_log
logger -t "$scr_name" "Running $vpn_script_name $*"
/bin/sh /jffs/scripts/$vpn_script_name $* # I don't use this, but I have them in /jffs/scripts
/bin/sh /jffs/scripts/vpnc.sh & # This trigger my script and use environment variables from clients.
else
logger -t "$scr_name" "No scripts found to run for openvpn-event: $vpn_script_name"
echo " Script not defined for VPN event: "$vpn_script_name | logger -t $scr_name
echo "${vpn_script_name}-NOSCRIPT" > $vpn_script_log
exit 0
fi
exit 0
/jffs/scripts/vpnc.sh: line 139: syntax error: unexpected "("
+ basename /jffs/scripts/openvpn-event
+ scr_name=openvpn-event[25040]
+ vpn_name=client3
+ vpn_script_name=vpnclient3-route-up
+ vpn_script_log=/tmp/vpnclient3_state
+ cat /tmp/vpnclient3_state
+ vpn_script_state=vpnclient3-up
+ [ vpnclient3-route-up = vpnclient3-up ]
+ [ -f /jffs/scripts/vpnclient3-route-up ]
+ logger -t openvpn-event[25040]
+ echo Script executing.. for VPN event: vpnclient3-route-up
+ echo vpnclient3-route-up
+ logger -t openvpn-event[25040] Running vpnclient3-route-up tun13 1500 1538 10.129.3.251
+ /bin/sh /jffs/scripts/vpnclient3-route-up tun13 1500 1538 10.129.3.251
+ exit 0
Either you have the wrong IP, or you haven't set both clients to Policy Rules. Check the rule list at the kernel level:The Manchester device will be routed through OVPN5.
ip rule show
Routing and DNS are two totally separate things. Routing will always obey the order I established in my previous posts. However DNS is handled separately (it's done at the firewall level rather than the routing level), and at this time I'm unable to give them any predictable priority, short of erasing and re-configuring the firewall on every rule changes, which would be very disruptive to the whole network. I haven't found any solution to this problem yet.With my limited knowledge i think this is not how it was supposed to work according to Merlin or the vpn clients are struggling with who comes first and set the rule?
Thanks, I can reproduce the issue with my own setup I'll have to investigate. The odd thing is if I run a traceroute from the router itself, then it does properly go through the tunnelif I change to the "new" "Yes (all)" redirect option - it still does not work [partial connect since it gets new Local ip address - but claims Public: Unknown
Must be something which crept in with 386 code ... I can clearly remember using Redirect = "Yes" in 384 code for a simple "protect all via VPN" trial period.Thanks, I can reproduce the issue with my own setup I'll have to investigate. The odd thing is if I run a traceroute from the router itself, then it does properly go through the tunnel
Unless there are two different separate issues here, I see one issue that's related to DNS handling whenever you have at least one client with DNS set to "Exclusive" mode, causing any other clients with redirection set to "Yes" to end up not having any DNS To use. That will require a major redesign of the DNS handling, I suspect that some of the very old legacy DNS handling is not compatible with the slightly newer exclusive mode that was added latter on. And since probably nobody ever used redirection set to "Yes", this old bug went unnoticed until now.Must be something which crept in with 386 code ... I can clearly remember using Redirect = "Yes" in 384 code for a simple "protect all via VPN" trial period.
Sadly throughput on all the VPN's I have tested here down South mess badly with speeds
Don't expect bufferbloat tests to give any reliable results here. VPN add encapsulation and encryption, so they aren't great for that. UDP should do quite better than TCP in this particular scenario (I've heard some reports from colleagues how VoIP requires OpenVPN to run in UDP mode to be usable through a tunnel).nd buffer-bloat so are largely unusable.
I have no idea how his script works, so I cannot answer that. But VPN Director (and the previous Policy Routing) both allow to route traffic per destination, not just per source. The Remote IP field is right there on the VPN Director UI.Will your new VPN Director remain compatible with x3mRouting from @Xentrk
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!