I'm running latest 386.1, need to update my signature. I'm checking thru mobile and laptop/tablet mainly wireless devices.
I tried a wired laptop as well. No luck. It happens with IE, Chrome and edge.
Hi, I am not sure if I understand this correctly. I think the first code below for whatsmyip.com will always route the traffic to WAN port and hence it will show your real WAN IP. For the second code, whatismyip.com will always show your VPN IP?
x3mRouting 1 0 VPN_IP dnsmasq=whatsmyip.com
x3mRouting ALL 1 WAN_IP dnsmasq=whatismyip.com
If I remember correctly I had you set up whatsmyip.com as the bypass check (i.e. check to make sure x3mRouting is bypassing the vpn for packets marked with 0x8000 so those packets should be getting connected directly through WAN) and dnsleak test is to make sure x3mRouting is forcing packets marked with 0x1000 through vpn client 1
“x3mRouting 1 0 WAN_IP dnsmasq=whatsmyip.com” —> force whatsmyip.com to connect through your wan
“x3mRouting ALL 1 VPN_IP dnsmasq=whatismyip.com”—> force whatismyip.com to connect through your vpn cli
You can see all the rules you have created in /jffs/scripts/nat-start
NOTE: “VPN_IP” and “WAN_IP” are just names. You can put any valid string in that position and that will be the name of the IP Set
i.e.
Code:
x3mRouting 1 0 WIP dnsmasq=whatsmyip.com <--> x3mRouting 1 0 WAN_IP dnsmasq=whatsmyip.comthese two commands do the exact same time the first names the set “WIP” and the second names the set “WAN_IP” but functionally they are the same.
Last edited:
“x3mRouting 1 0 VPN_IP dnsmasq=whatsmyip.com” —> force whatsmyip.com to connect through your vpn
I thought it means source interface 1(OVPNC1) to destination interface 0 (WAN)?
Src and Dst combination 1 0 matches no 2) VPN bypass routing. Meaning it bypass VPN client 1 and routes to WAN. Does this mean I should see my WAN IP when i visit whatsmyip.com?
x3mRouting {src iface} (ALL|1|2|3|4|5)
{dst iface} (0|1|2|3|4|5)
**START: src/dst usage notes**
Valid SRC and DST Combinations
1) VPN Client Routing
- Use this SRC and DST combination to route all IPSET list traffic to a VPN Client:
ALL 1, ALL 2, ALL 3, ALL 4, ALL 5
2) VPN Bypass Routing
- Use this SRC and DST combination to bypass the VPN Client for an IPSET list and route to the WAN interface:
1 0, 2 0, 3 0, 4 0, 5 0
**END: src/dst usage notes**
...snipped...########################################################
# Assign the interface for each LAN client by entering #
# the appropriate interface number in the first column #
# 0 = WAN #
# 1 = OVPNC1 #
# 2 = OVPNC2 #
# 3 = OVPNC3 #
# 4 = OVPNC4 #
# 5 = OVPNC5 #
#########################################################
Last edited:
I think I figured out why I was leaking. In the past, when I had comcast cable, I used to use xfinity @ home app to allow streaming on my devices, however it would detect a VPN was being used and I had a rule (asnum=AS7016,AS7922 running thru the x3mRouting script) for comcast related stuff to go thru WAN. I have removed the rule and everything is working as intended, so far & after a few reboots!!!
Browserleaks was pointing my network to "AS7922" Comcast Cable Communications.
I'm not sure it's related but this seems to be working now.
Browserleaks was pointing my network to "AS7922" Comcast Cable Communications.
I'm not sure it's related but this seems to be working now.
Did switching the rules from -A (append) to -I (insert) fix the issue that comes up when you change your wan dns?
I’m still really not happy with that solution as it doesn’t remove the outdated rules but I can’t get this stupid comment thing to work and I’m wary of removing rules based on their rule number because of the potential to remove the wrong rules. I have not seen anyone else using the mangle table in the output chain but I would like to get an exact rule match so I know those are the only rules that can possibly be removed.
You are correct I got those backwards. “0 1” looks for traffic pointed at the vpn and redirects it to the Wan interface. ALL 1 looks for traffic at all interfaces and redirects it to the vpn client 1 interface.
I’ll edit that post to reflect the correction. Sorry for any confusion that may have caused.
It still does the same. I kept the rules with the change ( -I versus - A) and I have not seen anything hiccups running it this way. Should I switch back to -A (append)? Did you see @Martineau post earlier...not sure if this would help?
http://www.snbforums.com/threads/unbound-dns-vpn-client-w-policy-rules.67370/post-658109
Martineau
Part of the Furniture
Brief tutorial..copy and paste for testing on command line
Tag multiple devices (e.g. two) that are to be 'categorised' as "KIDS" with a single rule request
Code:
modprobe xt_comment
iptables -A FORWARD -s 172.16.55.2,172.16.55.43 -d 123.45.6.7 -j DROP -m comment --comment "KIDS"
Code:
iptables -A FORWARD -s 172.16.55.99 -d 123.45.6.99 -j DROP -m comment --comment "KIDS"Perform the mass delete of the "KIDS" 'category' (without knowing the actual detail/number of rules etc.)
Code:
iptables-save | grep "KIDS" | sed 's/^-A/iptables -D/' | while read CMD;do $CMD;doneTL;DR
If you want to see the "KIDS" 'category' rules BEFORE the mass delete, this should help in understanding how it works
Generic list of rules
Code:
iptables --line -t filter -nvL FORWARD
<snip>
10 0 0 DROP all -- * * 172.16.55.2 123.45.6.7 /* KIDS */
11 0 0 DROP all -- * * 172.16.55.43 123.45.6.7 /* KIDS */
12 0 0 DROP all -- * * 172.16.55.99 123.45.6.99 /* KIDS */Now explicitly list ALL rules by 'category' (without knowing the actual number of rules etc.)
Code:
iptables-save | grep "KIDS"
-A FORWARD -s 172.16.55.2/32 -d 123.45.6.7/32 -m comment --comment KIDS -j DROP
-A FORWARD -s 172.16.55.43/32 -d 123.45.6.7/32 -m comment --comment KIDS -j DROP
-A FORWARD -s 172.16.55.99/32 -d 123.45.6.99/32 -m comment --comment KIDS -j DROPPrepare for mass delete by 'category' (without knowing the actual number of rules etc.)
Code:
iptables-save | grep "KIDS" | sed 's/^-A/iptables -D/'
iptables -D FORWARD -s 172.16.55.2/32 -d 123.45.6.7/32 -m comment --comment KIDS -j DROP
iptables -D FORWARD -s 172.16.55.43/32 -d 123.45.6.7/32 -m comment --comment KIDS -j DROP
iptables -D FORWARD -s 172.16.55.99/32 -d 123.45.6.99/32 -m comment --comment KIDS -j DROPYeah I did see that yesterday. I haven’t really looked at what was posted but I made a note to look at that first when I get a second to pull this back up. This week has just been crazy and I haven’t had any extra time between school and work.
as far as switching between -A and -I I would just leave it if things are working right now. The only difference is where the rules go when they are created. Since the mangle table in the output isn’t being used for anything else (at least in my case) you don’t need to worry about making sure the rules get checked in a particular order.
I feel like that was really poorly worded but if you look up a brief overview of how iptables works I think it will be clear. Basically order matters in iptables but my rules are already in order and aren’t other rules to worry about right now.
Fantastic! This is exactly what I’m trying to do. As I stated in a previous post I haven’t really had time to dig into this. I briefly tried to add “-m comment --comment “xxx”” to the rule creation but it got rejected with “no matching rule” or something like that so I’m not sure if I just made a syntax error or if there is some conflict but either way I need to dig in a bit more
Martineau
Part of the Furniture
Perhaps you needed the
modprobe xt_comment ?I have not done that so that seems likely lol. Thanks for your input I really appreciate it. I’m trying to wrap my head around everything but Linux/bash is such a beast. Just too many ways to same tasks. I feel like such a script kiddie right now but I’m glad to have a community that can push me in the right direction.
I made some time today to work on this. A real quick question do modprobe directives persist after reboots? Should I put this in a setup function that only runs on initial setup?
Modprobe directive did allow me to add comments so the rules are now created with the comment “unbound_rule”. The delete command isn’t matching right now but all the rules with the specified comment are now produced so this will definitely work once I figure out what’s wrong with the output rule format. Hopefully I’ll have an update this evening. I’m planning on modifying the rule add/remove functions and adding a function to do the set up stuff like automatically creating the x3mRouting commands/modprobe
Martineau
Part of the Furniture
Yes I use
init-start rather than include/execute modprobe xt_comment in the individual scripts.Similar threads
Similar threads
Similar threads
-
-
-
-
-
-
Solved Latest entware update borked up Unbound- Started by Viktor Jaep
- Replies: 25
-
-
-
-