SomeWhereOverTheRainBow
Part of the Furniture
Great job man! Appears to function well.Thanks. It should be a quick fix. I broke it during an update.
EDIT: Fixed the menu only!
Great job man! Appears to function well.Thanks. It should be a quick fix. I broke it during an update.
EDIT: Fixed the menu only!
Select option 4 to download the updated version of route_all_vpnserver.sh. I fixed the error handling for valid VPN Server and VPN Client instances.Great job man! Appears to function well.
The point of using the dnsmasq method is that hopefully it will always be 'current' for the current locale - meaning any new IPs will always be added, but old/stale entries will not be removed.The Netflix ipset configured via the DNSMASQ method has significantly less IP addresses on the AC3200 than it does on the AC88U.
Thanks for the feedback.@Xentrk great job on the VPN Server to VPN Client routing option! It seems so much easier set it up now.
That said, are you still exploring/working on the IPSET based routing from VPN Server to VPN Client option? That, would, be, game changer for many I believe
While setting up IPSET based routing for local LAN is a breeze, you won't have access to your complex setup when you are not home. If this would be possible it would be a breeze to keep your routing policies with you when you travel
I would be personally even willing to contribute in form of donation and I'm sure many others as well could display their appreciation with small donations to support the development
Thanks for the feedback.
I did code a script to implement the routing rules though. Unfortunately, I haven't been able to get the IPSET based routing from VPN Server to VPN Client to work. You can see the details in the post here. I have tried some different things with no success. Once I implement the rules, I can't access websites from a browser over the VPN Server connection. What I find strange is that I see pkts being passed to the iptables rule even though I can't access Pandora website in a browser. It just spins and eventually times out.
Thanks for the feedback.
I did code a script to implement the routing rules though. Unfortunately, I haven't been able to get the IPSET based routing from VPN Server to VPN Client to work. You can see the details in the post here. I have tried some different things with no success. Once I implement the rules, I can't access websites from a browser over the VPN Server connection. What I find strange is that I see pkts being passed to the iptables rule even though I can't access Pandora website in a browser. It just spins and eventually times out.
What did you try?Unfortunately, I haven't been able to get the IPSET based routing from VPN Server to VPN Client to work.
I have tried some different things with no success.
./VPN_Client_Switch.sh 3 on
(VPN_Client_Switch.sh): 1736 v1.09 Request..... [3 on]
(VPN_Client_Switch.sh): 1736 No VPN ACTIVE - Starting VPN Client 3
Waiting for VPN Client 3 (VPNBook USA1) to connect.....
VPN Client 3 (VPNBook USA1) connect'd in 28 secs
VPN Client Status:
13:26:49 VPN end-point=unknown; Checking STUN servers (may take 10-30 seconds!)..... 13:26:59
Client 3 Connected via 10.10.0.154 (VPNBook USA1) VPN STUN tunnel end-point I/P: unknown
Checking response (max 5secs) from 'http://ipecho.net/plain' to verify VPN tunnel end-point I/P: unknown
VPN tunnel end-point I/P: 198.7.62.204
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
tun13: 3640778 3254 0 0 0 0 0 0 296193 3496 0 0 0 0 0 0
NOTE: OpenVPN Statistics logged to Syslog
ip rule
0: from all lookup local
9990: from all fwmark 0x8000/0x8000 lookup main
9995: from all fwmark 0x4000/0x4000 lookup ovpnc3
32766: from all lookup main
32767: from all lookup default
ip route show table 113
10.10.0.153 dev tun13 proto kernel scope link src 10.10.0.154
10.16.0.0/24 dev tun22 scope link
10.8.0.0/24 dev tun21 scope link
192.168.1.0/24 via 10.88.8.254 dev br0 metric 2
10.88.8.0/24 dev br0 proto kernel scope link src 10.88.8.1
10.0.0.0/8 dev br0 proto kernel scope link src 10.88.8.3
default via 10.10.0.153 dev tun13
iptables --line -t nat -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 9059 packets, 623K bytes)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE all -- * tun13 10.88.8.0/24 0.0.0.0/0
2 0 0 MASQUERADE all -- * tun1+ 10.16.0.0/24 0.0.0.0/0
3 56 2912 MASQUERADE all -- * tun1+ 10.8.0.0/24 0.0.0.0/0
<snip>
./OpenVPNServerStatus.sh list
There are 1 clients connected to OpenVPN Server 1 (Port xxxxx, IP Pool:10.8.0.0)
10.8.0.2 (xxx.xxx.xxx.xxx.xxx:50306) since Wed-Nov-20-14:41:27-2019
There are 0 clients connected to OpenVPN Server 2
iptables -t mangle -I PREROUTING -i tun21 -s 10.8.0.2 -m set --match-set pandora dst -j MARK --set-xmark 0x4000/0x4000
iptables -nvL PREROUTING -t mangle --line
Chain PREROUTING (policy ACCEPT 258 packets, 61181 bytes)
num pkts bytes target prot opt in out source destination
1 208 17320 MARK all -- tun21 * 10.8.0.2 0.0.0.0/0 match-set pandora dst MARK or 0x4000
What did you try?
Current configuration
Code:./VPN_Client_Switch.sh 3 on (VPN_Client_Switch.sh): 1736 v1.09 Request..... [3 on] (VPN_Client_Switch.sh): 1736 No VPN ACTIVE - Starting VPN Client 3 Waiting for VPN Client 3 (VPNBook USA1) to connect..... VPN Client 3 (VPNBook USA1) connect'd in 28 secs VPN Client Status: 13:26:49 VPN end-point=unknown; Checking STUN servers (may take 10-30 seconds!)..... 13:26:59 Client 3 Connected via 10.10.0.154 (VPNBook USA1) VPN STUN tunnel end-point I/P: unknown Checking response (max 5secs) from 'http://ipecho.net/plain' to verify VPN tunnel end-point I/P: unknown VPN tunnel end-point I/P: 198.7.62.204 Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed tun13: 3640778 3254 0 0 0 0 0 0 296193 3496 0 0 0 0 0 0 NOTE: OpenVPN Statistics logged to Syslog
Code:ip rule 0: from all lookup local 9990: from all fwmark 0x8000/0x8000 lookup main 9995: from all fwmark 0x4000/0x4000 lookup ovpnc3 32766: from all lookup main 32767: from all lookup default
Code:ip route show table 113 10.10.0.153 dev tun13 proto kernel scope link src 10.10.0.154 10.16.0.0/24 dev tun22 scope link 10.8.0.0/24 dev tun21 scope link 192.168.1.0/24 via 10.88.8.254 dev br0 metric 2 10.88.8.0/24 dev br0 proto kernel scope link src 10.88.8.1 10.0.0.0/8 dev br0 proto kernel scope link src 10.88.8.3 default via 10.10.0.153 dev tun13
Code:iptables --line -t nat -nvL POSTROUTING Chain POSTROUTING (policy ACCEPT 9059 packets, 623K bytes) num pkts bytes target prot opt in out source destination 1 0 0 MASQUERADE all -- * tun13 10.88.8.0/24 0.0.0.0/0 2 0 0 MASQUERADE all -- * tun1+ 10.16.0.0/24 0.0.0.0/0 3 56 2912 MASQUERADE all -- * tun1+ 10.8.0.0/24 0.0.0.0/0 <snip>
Code:./OpenVPNServerStatus.sh list There are 1 clients connected to OpenVPN Server 1 (Port xxxxx, IP Pool:10.8.0.0) 10.8.0.2 (xxx.xxx.xxx.xxx.xxx:50306) since Wed-Nov-20-14:41:27-2019 There are 0 clients connected to OpenVPN Server 2
Attempt to open 'www.pandora.com' on remote OpenVPN device 10.8.0.2
View attachment 19945
Add IPSET fwmark rule for the remote OpenVPN device 10.8.0.2
Attempt to open 'www.pandora.com' on remote OpenVPN device 10.8.0.2Code:iptables -t mangle -I PREROUTING -i tun21 -s 10.8.0.2 -m set --match-set pandora dst -j MARK --set-xmark 0x4000/0x4000
View attachment 19946
Code:iptables -nvL PREROUTING -t mangle --line Chain PREROUTING (policy ACCEPT 258 packets, 61181 bytes) num pkts bytes target prot opt in out source destination 1 208 17320 MARK all -- tun21 * 10.8.0.2 0.0.0.0/0 match-set pandora dst MARK or 0x4000
I wrote them.Where do you get these scripts:
OpenVPNServerStatus.sh
VPN_Client_Switch.sh
These are not part of X3mRouting,
The Selective Routing fwmark rules need to be added using a nat-start script or similarGUI initiated VPNC1 connection won't be displayed when issuing the following commands:
Code:ip rule (no fwmark rules)
My example shows I routed the IPSET via VPN Client 3.(empty response)Code:ip route show table 113
The one item that jumps out at me when I compare my results with your's is the routing table output. I only show one entry whereas you have more than one entry.What did you try?
Current configuration
Code:./VPN_Client_Switch.sh 3 on (VPN_Client_Switch.sh): 1736 v1.09 Request..... [3 on] (VPN_Client_Switch.sh): 1736 No VPN ACTIVE - Starting VPN Client 3 Waiting for VPN Client 3 (VPNBook USA1) to connect..... VPN Client 3 (VPNBook USA1) connect'd in 28 secs VPN Client Status: 13:26:49 VPN end-point=unknown; Checking STUN servers (may take 10-30 seconds!)..... 13:26:59 Client 3 Connected via 10.10.0.154 (VPNBook USA1) VPN STUN tunnel end-point I/P: unknown Checking response (max 5secs) from 'http://ipecho.net/plain' to verify VPN tunnel end-point I/P: unknown VPN tunnel end-point I/P: 198.7.62.204 Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed tun13: 3640778 3254 0 0 0 0 0 0 296193 3496 0 0 0 0 0 0 NOTE: OpenVPN Statistics logged to Syslog
Code:ip rule 0: from all lookup local 9990: from all fwmark 0x8000/0x8000 lookup main 9995: from all fwmark 0x4000/0x4000 lookup ovpnc3 32766: from all lookup main 32767: from all lookup default
Code:ip route show table 113 10.10.0.153 dev tun13 proto kernel scope link src 10.10.0.154 10.16.0.0/24 dev tun22 scope link 10.8.0.0/24 dev tun21 scope link 192.168.1.0/24 via 10.88.8.254 dev br0 metric 2 10.88.8.0/24 dev br0 proto kernel scope link src 10.88.8.1 10.0.0.0/8 dev br0 proto kernel scope link src 10.88.8.3 default via 10.10.0.153 dev tun13
Code:iptables --line -t nat -nvL POSTROUTING Chain POSTROUTING (policy ACCEPT 9059 packets, 623K bytes) num pkts bytes target prot opt in out source destination 1 0 0 MASQUERADE all -- * tun13 10.88.8.0/24 0.0.0.0/0 2 0 0 MASQUERADE all -- * tun1+ 10.16.0.0/24 0.0.0.0/0 3 56 2912 MASQUERADE all -- * tun1+ 10.8.0.0/24 0.0.0.0/0 <snip>
Code:./OpenVPNServerStatus.sh list There are 1 clients connected to OpenVPN Server 1 (Port xxxxx, IP Pool:10.8.0.0) 10.8.0.2 (xxx.xxx.xxx.xxx.xxx:50306) since Wed-Nov-20-14:41:27-2019 There are 0 clients connected to OpenVPN Server 2
Attempt to open 'www.pandora.com' on remote OpenVPN device 10.8.0.2
View attachment 19945
Add IPSET fwmark rule for the remote OpenVPN device 10.8.0.2
Attempt to open 'www.pandora.com' on remote OpenVPN device 10.8.0.2Code:iptables -t mangle -I PREROUTING -i tun21 -s 10.8.0.2 -m set --match-set pandora dst -j MARK --set-xmark 0x4000/0x4000
View attachment 19946
Code:iptables -nvL PREROUTING -t mangle --line Chain PREROUTING (policy ACCEPT 258 packets, 61181 bytes) num pkts bytes target prot opt in out source destination 1 208 17320 MARK all -- tun21 * 10.8.0.2 0.0.0.0/0 match-set pandora dst MARK or 0x4000
ip route show table 115
default via 10.35.0.25 dev tun15
ip route
1xx.xx.xxx.xx dev ppp0 proto kernel scope link
10.31.0.9 dev tun13 proto kernel scope link src 10.31.0.10
10.24.0.17 dev tun11 proto kernel scope link src 10.24.0.18
10.35.0.25 dev tun15 proto kernel scope link src 10.35.0.26
10.37.0.5 dev tun12 proto kernel scope link src 10.37.0.6
192.168.22.0/24 dev br0 proto kernel scope link src 192.168.22.1
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
123.254.0.0/16 dev eth0 proto kernel scope link src 123.254.81.53
127.0.0.0/8 dev lo scope link
default via 1xx.xx.xxx.xx dev ppp0
NO, but even if you did, and created the resulting entry in the RPDB table, the VPN RPDB fwmark rule (if matched) would pre-empt it anyway.Do you also need to add the 10.8.0.0/24 entry to the Policy Routing section in the VPN Client Screen and route it to the VPN like I do for all traffic?
PS C:\Users\Martineau> Test-NetConnection www.pandora.com -TraceRoute
WARNING: Ping to 208.85.40.20 failed with status: TimedOut
WARNING: Trace route to destination 208.85.40.20 did not complete. Trace terminated :: 0.0.0.0
ComputerName : www.pandora.com
RemoteAddress : 208.85.40.20
InterfaceAlias : Ethernet
SourceAddress : 10.8.0.2
PingSucceeded : False
PingReplyDetails (RTT) : 0 ms
TraceRoute : 10.8.0.1
10.10.0.1
0.0.0.0
<snip>
Thanks @Martineau,NO, but even if you did, and created the resulting entry in the RPDB table, the VPN RPDB fwmark rule (if matched) would pre-empt it anyway.
Remember, Policy Routing will work for all processes running on the router itself, and for the local network, if it is masqueraded - hence we must manually masquerade the OpenVPN Servers (tun2+) subnet pool(s).
FYI, a crude confirmation method - on my remote OpenVPN device (Win10 laptop) you can use either tracert or the more informative (but slower! if target doesn't support PING) Powershell command:
e.g. Ignore the multiple consecutive 0.0.0.0 entries i.e. 'www.pandora.com' doesn't respond to PING ( try 'www.microsoft.com' to see a 'proper response!')
and confirms that 10.8.0.2 is routing 'www.pandora.com' through my remote router (10.8.0.1 - hosting the OpenVPN Server) and 10.10.0.1 which is the VPN Client 3 (tun13) subnet.Code:PS C:\Users\Martineau> Test-NetConnection www.pandora.com -TraceRoute WARNING: Ping to 208.85.40.20 failed with status: TimedOut WARNING: Trace route to destination 208.85.40.20 did not complete. Trace terminated :: 0.0.0.0 ComputerName : www.pandora.com RemoteAddress : 208.85.40.20 InterfaceAlias : Ethernet SourceAddress : 10.8.0.2 PingSucceeded : False PingReplyDetails (RTT) : 0 ms TraceRoute : 10.8.0.1 10.10.0.1 0.0.0.0 <snip>
iptables -A POSTROUTING -t nat -s 10.8.0.0/24 -o tun15 -j MASQUERADE
iptables -t mangle -A PREROUTING -i tun21 -m set --match-set PANDORA dst -j MARK --set-xmark 0x3000/0x3000
Thanks @Martineau,
It works now! Your comment on the MASQUERADE rule was the key. I added the MASQUERADE POSTROUTING rule in combination with the PREROUTING RULE for PANDORA as follows:
I'll work on finishing the script.Code:iptables -A POSTROUTING -t nat -s 10.8.0.0/24 -o tun15 -j MASQUERADE iptables -t mangle -A PREROUTING -i tun21 -m set --match-set PANDORA dst -j MARK --set-xmark 0x3000/0x3000
"Tell me and I'll forget; Show me and I may remember; Involve me and I'll understand"Thanks @Martineau,
It works now! Your comment on the MASQUERADE rule was the key.
Don't issue the script until you see the money!I'll work on finishing the script.
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!