The rules get applied when the VPN status is "route-up" and the rules get removed at "route-pre-down" when the VPN is started or stopped. They also get reapplied during a firewall restart or when nat-start is run. This should cover most situations that I am aware of.
Here is how the route-up entry looks in system log:
Code:openvpn-event[4216]: Running /jffs/scripts/x3mRouting/vpnclient2-route-up tun12 1500 1584 10.37.0.6 10.37.0.5
Next time it happens, enter the following command to display the PREROUTING IPTABLES Chains for the mangle table to confirm if the rules exist or not:
Code:iptables -nvL PREROUTING -t mangle --line
Try turning the VPN on/off and use the command above to verify if the rules are being applied properly.
I did have an issue with my private IP one time where I had issues everytime the certificate lease got renewed. I can't recall the fix. I think they gave me a new IP.
I noticed the issue again today and confirmed that vpnclient1-route-up did run from the syslog. I checked the PREROUTING IPTABLES Chains, but the rules appear to be fine:
		Code:
	
	iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 64M packets, 64G bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     161M  187G BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
2      62M   72G BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
3     235K   47M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_US dst MARK or 0x8000
4        0     0 MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set NETFLIX dst MARK or 0x8000
5    1021K  375M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set GOOGLE dst MARK or 0x8000
6    34792 5627K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set FACEBOOK dst MARK or 0x8000
7     105K 9631K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_GLOBAL dst MARK or 0x8000
8     203K   28M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_AS16509 dst MARK or 0x8000
9    1838K  467M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set NETFLIX_CUSTOM dst MARK or 0x8000
10    139K   28M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_AS14618 dst MARK or 0x8000
11    170K   24M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON_CUSTOM dst MARK or 0x8000
	However, when I checked RPDB, I discovered the WAN mask prio 9990 was missing:
		Code:
	
	ip rule
0:    from all lookup local
10001:    from 192.168.1.1 lookup main
10002:    from all to 8.8.8.8 lookup main
10003:    from all to 8.8.4.4 lookup main
10004:    from 192.168.1.138 lookup main
10005:    from 192.168.1.233 lookup main
10006:    from 192.168.1.187 lookup main
10007:    from 192.168.1.10 lookup main
10101:    from 192.168.1.1/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default
	When I reran nat-start, the 9990 prio was added back, and my firetv started playing videos again:
		Code:
	
	ip rule
0:    from all lookup local
9990:    from all fwmark 0x8000/0x8000 lookup main
10001:    from 192.168.1.1 lookup main
10002:    from all to 8.8.8.8 lookup main
10003:    from all to 8.8.4.4 lookup main
10004:    from 192.168.1.138 lookup main
10005:    from 192.168.1.233 lookup main
10006:    from 192.168.1.187 lookup main
10007:    from 192.168.1.10 lookup main
10101:    from 192.168.1.1/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default
	Any ideas why prio 9990 is getting dropped and not added back when my VPN client connection drops and restarts?
Thanks for the help!
	