Chain DNSVPN1 (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN all -- * * 192.168.1.1 0.0.0.0/0
2 0 0 DNAT all -- * * 10.8.0.0/24 0.0.0.0/0 to:10.9.0.1
3 0 0 DNAT all -- * * 172.16.0.1 0.0.0.0/0 to:10.9.0.1
4 0 0 DNAT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 match-set AMAZON_GLOBAL src tcp dpt:53 to:10.9.0.1
5 0 0 DNAT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 match-set AMAZON_GLOBAL src udp dpt:53 to:10.9.0.1
6 0 0 DNAT tcp -- br0 * 0.0.0.0/0 0.0.0.0/0 match-set HULU_WEB src tcp dpt:53 to:10.9.0.1
7 0 0 DNAT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 match-set HULU_WEB src udp dpt:53 to:10.9.0.1/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/Xentrk/x3mRouting/x3mRouting-384.19/vpnrouting.sh" -o "/jffs/addons/x3mRouting/vpnrouting.sh" && chmod 755 "/jffs/addons/x3mRouting/vpnrouting.sh"
/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/Xentrk/x3mRouting/x3mRouting-384.19/updown-client.sh" -o "/jffs/addons/x3mRouting/updown-client.sh" && chmod 755 "/jffs/addons/x3mRouting/updown-client.sh"I don't foresee any issues. The location and structure of some of the files in /etc/openvpn are changing. So updown-client.sh refernces in x3mRouting had to change to match the updates made in 384.19 test builds.
The issue exists in the prior versions as well. The other impact is the routing rules for IPSET lists get wiped for those that use the modified x3mRouting OpenVPN Client screen for routing of IPSET lists. I think the way I will patch is to add a line to /jfffs/scripts/firewall-start to call the script below that will bounce any active VPN Clients, which will reinstate the DNS and PREROUTING rules for IPSET lists.
for VPN_CLIENT in 1 2 3 4 5; do
CLIENT_STATE=$(nvram get vpn_client${VPN_CLIENT}_state)
case "$CLIENT_STATE" in
2) service restart_vpnclient${VPN_CLIENT}
logger -st "($(basename "$0"))" $$ Restarted VPN Client "$VPN_CLIENT" ;;
esac
donesh -c "$(curl -sL https://raw.githubusercontent.com/Xentrk/x3mRouting/x3mRouting-384.19/Install_x3mRouting.sh)"Option ==> 2
Invalid firmware version detected - 384.18. This option of x3mRouting requires version 384.19 and above.
You can force update x3mRouting by typing the word 'force' after the option number to force update (e.g. 1 force)
To override the warning, you must force the update by supplying the "force" parameter at the option line "1 force" or "2 force"
Press enter to continueOption ==> 2 forcesh -c "$(curl -sL https://raw.githubusercontent.com/Xentrk/x3mRouting/x3mRouting-384.19/Install_x3mRouting.sh)"andresmorago@RT-AC3100-0548:/tmp/home/root# sh /jffs/scripts/x3mRouting/x3mRouting.sh ALL 1 aws1
(x3mRouting.sh): 32211 Starting Script Execution ALL 1 aws1
(x3mRouting.sh): 32211 IPSET created: aws1
ipset v6.32: Error in line 1: Syntax error: cannot parse create: resolving to IPv4 address failed
(x3mRouting.sh): 32211 Selective Routing Rule via VPN Client 1 created for aws1 fwmark 0x1000/0x1000
(x3mRouting.sh): 32211 iptables -t mangle -D PREROUTING -i br0 -m set --match-set aws1 dst -j MARK --set-mark 0x1000/0x1000 2>/dev/null added to /jffs/scripts/x3mRouting/vpnclient1-route-up
(x3mRouting.sh): 32211 iptables -t mangle -A PREROUTING -i br0 -m set --match-set aws1 dst -j MARK --set-mark 0x1000/0x1000 added to /jffs/scripts/x3mRouting/vpnclient1-route-up
(x3mRouting.sh): 32211 iptables -t mangle -D PREROUTING -i br0 -m set --match-set aws1 dst -j MARK --set-mark 0x1000/0x1000 2>/dev/null added to /jffs/scripts/x3mRouting/vpnclient1-route-pre-down
(x3mRouting.sh): 32211 sh /jffs/scripts/x3mRouting/x3mRouting.sh ALL 1 aws1 added to /jffs/scripts/nat-start
(x3mRouting.sh): 32211 Completed Script Execution
andresmorago@RT-AC3100-0548:/tmp/home/root#I suspect you have a mismatch in format of the save/restore file location in /opt/tmp/aws1. Please see the posts below.
I’m really sorry
. Indeed you had helped me before with this and I ended up forgetting about it. I will take a look again tomorrow and come back with results.
No worries. I did something similar myself recently. I did update the x3mRouting-384.19 test branch to trap the error, along with preventing the IPSET list to get created if the save/restore file does not exist.I’m really sorry
The old usage syntax no longer works. How did you switch over? Did you use the Version 2.0.0 Update Process and run the conversion file that got generated or did you uninstall the prior version then install the new version? For testing purposes, I am currently using the GUI to route the IPSET lists that don't have an interface specified. But also have some IPSET lists for Netflix where I specify the src and dst interface. The two are able to coexist.
iptables -nvL PREROUTING -t mangle --lineNo. I looked for that procedure but could not find it in either the 1st post of this thread or on the github text, so I thought I'd figure it out myself. After a few stumbles, including not getting the Policy Rules to work, I rebooted, and now all is OK. One issue I still have is that the nat-start file contains the new rules, but after the reboot, x3mRouting did not pick up all the rules. When I manually executed them from the ssh session, I ended up with duplicate lines of the same rules in nat-start. But I'm not sure x3m will pick up on them the next time I do a reboot. BTW, I initially did an uninstall then an install from amtm. That sequence did not produce a conversion file.
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!
