Padavan FW , Routing Specific devices through PPTP

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Skywalker1726

New Around Here
hi everyone , i recently started using padavan firmware , and ran into some problems and after a lot of googling , hoped that u guys would be able to help.
what i wanted to do is to make 2 of the devices connected to the router , use the connected PPTP connection and for the other devices to ignore it .
so here are the settings that I'm currently using :

1- PPTP connection ( PPP5 )
2- Restrict Access from VPN Server Site: YES BUT FOLLOW FIREWALL AND PORTFWD Rules
3-DNS From VPN Server : add to the list
4-route everything through the connection : NO

5- FUNC IPUP Script :

ip route flush table 200
ip route flush cache
ip rule add from 192.168.1.10 lookup 200 ( device n1 )
ip rule add from 192.168.1.11 lookup 200 ( device n2 )
VPN_GW=`ifconfig ppp5 | awk '/inet addr/ {split ($2,A,":"); print A[2]}'`
ip route add table 200 default via $VPN_GW dev ppp5
return 0

6-script after Firewall rules restarted

iptables -t nat -A POSTROUTING -o ppp5 -j MASQUERADE

also tried with :

iptables -I FORWARD -i br0 -o ppp5 -j ACCEPT
iptables -I FORWARD -i ppp5 -o br0 -j ACCEPT
iptables -I INPUT -i ppp5 -j REJECT

sometimes ,in best case scenario websites like Youtube do not fully load , i mean it does open the website , but the movies always fail to load .
I have tried tracert command which shows that I'm not on my default gateway and also that my public ip address has changed but the pages still fail to load .

is it a dns problem ?

and also if i set the ""Route All Traffic through the VPN interface?"" setting to YES , then every webpages loads just fine , but that's not what i want to do , i only want to restrict the usage of the PPTP connection to 2 specific device

any help would be appreciated
Thanks
 

eibgrad

Very Senior Member
I'm NOT familiar w/ the Padavan firmware, so keep that in mind. But when it comes to configuration of the PPTP client, most firmware is similar enough it probably doesn't matter.

In general, you seem to be on the right track (although I could probably recommend a few minor changes, which I'll get to later), but I suspect the major problem is indeed DNS.

If everything works correctly when you have "Route All Traffic through the VPN interface" set to Yes/Enabled, then all your routing and firewall rules should be fine. There's no need to add/remove or otherwise alter anything in this regard.

But you have to be careful w/ PBR (policy based routing), because depending on how DNS gets (re)configured wrt the PPTP client, you can end up w/ DNS queries being resolved over the WAN/ISP, and clients attempting to access those public IPs over the VPN. And sometimes content providers won't allow it!

Or to put it another way, your DNS results and the point of access based on those results are out of sync. Ideally, what you want for smooth operation is for any DNS results over the WAN/VPN to subsequently result in access over the same network interface.

That's why PBR can be tricky. In the process of configuring it, you're also removing the router itself from the VPN. And if that router is serving as your network DNS proxy (DNSMasq), which is normally the default, you now face the possibility of it accessing DNS over the WAN, while the VPN clients are accessing their content over the VPN! It all depends on how the proxy ends up getting (re)configured in response to getting connected to the PPTP server. If that's with the PPTP's DNS server over tunnel, it should all be copacetic (at least for clients of the VPN). But if it's NOT, and it's something like Google (8.8.8.8), Cloudflare (1.1.1.1), or whatever, it will be accessed over the WAN. And now you might have issues.

Frankly, the same problem can occur w/ those clients NOT assigned to the VPN. They might have problems if their DNS queries are resolved over the VPN, but those public IPs are accessed over the WAN/ISP. The problem tends to be worse when the VPN server is located in some other country, rather than simply across town or a few states over. It all stems from trying to have the *one* DNS proxy (DNSMasq) serve the WAN and VPN. Sometimes it works just fine, sometimes you run into these issues.

I'm particularly suspicious this is the problem since all things work normally when NOT using PBR, which makes sense, since in that scenario, you never end up w/ this synchronization problem.

One thing you could try, just to see if this is the problem, is configure DNS servers directly on the client (e.g., 1.1.1.1, 1.0.0.1). That will bypass DNSMasq on the router and force all the client's DNS and website/content access over the VPN. Or else determine the DNS server(s) the PPTP provider requires and use them instead.
 

eibgrad

Very Senior Member
As I mentioned, you could probably do w/ a few other changes.

For one thing, you need to flush the cache *after* making all your changes. That's what forces the routing system to recognize them, rather than possibly relying on old, cached information.

Also, it's not a good practice to simply plug the VPN's default gateway into the alternate routing table. In some instances, it'll work. But you can get into problems when you have other networks besides just the private one (br0), such as other VPNs (server and/or clients), guest or IoT networks, etc. If you leave those routes out of the alternate routing table, then those clients bound to the VPN will no longer be able to communicate w/ them! They simply don't have the routing information anymore.

Also, I hope those references to the clients n1 and n2 are commented out in the actual script (I assume you added them to the post for clarity's sake).

Here's a slightly improved version of your script.

Code:
#!/bin/sh
TID='10'
VPN_IF='ppp5'
VPN_GW="$(ifconfig $VPN_IF | awk '/inet addr/ {split ($2,A,":"); print A[2]}')"

# cleanup from possible prior execution
{
while ip rule del from 0/0 table $TID; do :; done
ip route flush table $TID
ip route flush cache
} 2>/dev/null

# copy main routing table to alternate (exclude any default gateways)
ip route | grep -Ev '^default |^0.0.0.0/1 |^128.0.0.0/1 ' \
  | while read route; do
        ip route add $route table $TID
    done

# add VPN as default gateway
ip route add default via $VPN_GW dev $VPN_IF table $TID

# start split tunnel
ip rule add from 192.168.1.10 table $TID # device n1
ip rule add from 192.168.1.11 table $TID # device n2

# force system to recognize changes
ip route flush cache

I added comments mostly for YOUR benefit.

I also changed the table ID from 200 to 10 because on some ASUS routers (particularly w/ Merlin firmware), table 200 is already in use (specifically for the WAN)! So be careful in your choice of tables and verify it's NOT in use.

Code:
ip route show table 200

For all I know, any of these other things might be part of the problem as well.

And once the PPTP client is connected, use ssh to verify your data structures were updated as expected. Don't just assume they were.

Code:
ip route show table main
ip route show table 10
ip rule show
 
Last edited:

Skywalker1726

New Around Here
First of all , thank you , for your time and also for sharing ur experience and knowledge , couldn't have asked for a much more detailed explanation .
I'll try ur recommendation and report back .

also something that i forgot to mention in my previous post is that those website ( Youtube ) are blocked on my WAN , so that's why I'm trying to use that vpn connection for these devices .
and also i read that i could use an alternate method via FLAG ing the packet that comes from those ip ( source ) and routing the flagged ones to the table .
would u recommend that as a better way of doing what I'm trying to accomplish ?
Thanks again .
 

eibgrad

Very Senior Member
First of all , thank you , for your time and also for sharing ur experience and knowledge , couldn't have asked for a much more detailed explanation .
I'll try ur recommendation and report back .

also something that i forgot to mention in my previous post is that those website ( Youtube ) are blocked on my WAN , so that's why I'm trying to use that vpn connection for these devices .
and also i read that i could use an alternate method via FLAG ing the packet that comes from those ip ( source ) and routing the flagged ones to the table .
would u recommend that as a better way of doing what I'm trying to accomplish ?
Thanks again .

Marking (flagging) packets is indeed another technique for implementing PBR. What you typically do is mark specific packets in the PREROUTING chain of the mangle table based on your choice of criteria (source/destination IP, protocol (tcp/udp), source/destination port, etc.), then create *one* rule in the ip rules database (RPDB) that routes anything w/ that mark to your alternate routing table (the one pointing to the VPN).

The primary benefit of marking packets is that unlike your present technique, you're NOT limited to just the source IP. Using your present technique, it's all or nothing for a given device when it comes to whether it uses the WAN or VPN. And marking packets can be useful if you would like to route specific traffic from a given device over one network interface, but let all the rest use another (i.e., w/ more granularity).

But marking packets has some other drawbacks that ppl don't often mention. Because you're working w/ an existing router/system that may already be marking packets for its own reasons (e.g., QoS), and there's only *one* field to be shared by all processes to manage all marks, it means you have to be careful NOT to stomp on some other processes marks, or have those processes stomp on yours!

In a crude effort to protect their own marks, what you'll sometimes see is users flush the PREROUTING chain of the mangle table prior to adding their own rule(s), effectively disabling the feature for all other processes! IOW, they break the system for the benefit of their own needs. Sometimes intentionally, sometimes naively, because they were told to do so in some article or blog post. Not exactly a great idea in my opinion.

For the most part, using strictly IP rules as you currently are just avoids these kinds of complications, and is preferred if it meets your needs. It's just simpler and less problematic.
 

eibgrad

Very Senior Member
Since you brought up this issue of marking packets, I should provide a bit more clarity about your present technique.

Using strictly ip rules, it is *possible* to use more than just the source IP for qualifying your rules. However, most embedded systems use something called BusyBox to implement the most common and useful Linux utilities, including the ip command. But in order to comply w/ the limited resources of these embedded devices, BusyBox often strips out many features of these same commands. So while you can go to the man page for the ip command and find all sorts of other options (sport, dport, etc.), most of the time these have been stripped out to save space. Sometimes you'll find other less common options like iif (input interface), oif (output interface), to (destination), etc., implemented, but they're often less useful. And in most cases, when used by the GUI for PBR purposes, these are not made available regardless, but only source IP (and perhaps destination IP as well, as w/ Merlin).

So when writing your own PBR scripts, you can always use any of these other options *if* they are available. If not, any attempt to use them should return an error.

Merlin:
Code:
[email protected]:/tmp/home/root# ip rule add from 192.168.1.100 sport 80 table main
Error: argument "sport" is wrong: Failed to parse rule type

DD-WRT:
Code:
[email protected]:~# ip rule add from 192.168.1.100 sport 80 table main
[email protected]:~# ip rule show
0:      from all lookup local
32765:  from 192.168.1.100 sport 80 lookup main
32766:  from all lookup main
32767:  from all lookup default

Yes, sport works w/ dd-wrt, but that capability was only added a couple months ago and required some trickery by the developer to make it happen.
 
Last edited:

Skywalker1726

New Around Here
hello again and thanks for the extra info .

tried the suggested solution , but unfortunately didn't solve the problem.
double checked with

ip route show table main
ip route show table 10
ip rule show

and everything was as it should ( at least as far as i could tell )

but now i am SURE that it is indeed a DNS problem .
cause when i switched from DHCP to manual IP on one of the devices ( clients ) and did set 8.8.8.8 as the primary dns , it solved the problem . but when i changed it to the routers ip ( 192.168.1.1 as dns ) the problem came back . (everything worked except YouTube.)
but the question is still if there is a way to solve this via the router config ? cause the devices are using DHCP .
thanks again.
 

eibgrad

Very Senior Member
Using the third-party firmware I'm most familiar with (Merlin, FreshTomato, dd-wrt), you can reconfigure DHCP to return different settings for specific devices.

Code:
dhcp-option=tag:alt_dns,6,1.1.1.1,1.0.0.1
dhcp-mac=set:alt_dns,1b:b9:f9:88:5f:63
dhcp-mac=set:alt_dns,f0:af:40:84:0e:4a
dhcp-mac=set:alt_dns,3e:c7:7e:ea:6a:ef

In the above example, three devices based on their MAC addresses are reconfigured to use Cloudflare DNS rather than the default (usually the router's own DNS server, DNSMasq). Of course, those same devices lose *local* name resolution as a result.

Each firmware has its own way of adding such modifications. I don't know if or how Padavan is capable of supporting DHCP modifications of this kind. That's something you'd have to investigate.
 

eibgrad

Very Senior Member
P.S. Came up w/ alternative way for you to configure any client w/ an alternate DNS server w/o having to change DHCP (which is often problematic). Esp. since I know you have access to the firewall.

Code:
iptables -t nat -I PREROUTING -s 192.168.1.100 -p tcp --dport 53 -j DNAT --to 1.1.1.1
iptables -t nat -I PREROUTING -s 192.168.1.100 -p udp --dport 53 -j DNAT --to 1.1.1.1

What the above does is intercept any DNS calls from 192.168.1.100 and redirects them to Cloudflare (1.1.1.1). Pretty simple. One minor downside compared to using DHCP is that you can only redirect DNS to a single server.

One other thing. Realize that many browsers today are accessing their own preferred DNS servers, usually w/ secure protocols like DoT/DoH, thus bypassing DNSMasq or any other locally configured DNS servers. And they often do this by default! The only way around the problem is to disable that "feature" in the browser settings.
 
Last edited:

Skywalker1726

New Around Here
Will try both options to see which one works better.
But what i do not get is why everything works flawlessly when the option " everything through vpn " is set to yes , but when i want to do it manually ( 2 devices only ) the dns doesnt get configured correctly ...
 

eibgrad

Very Senior Member
Will try both options to see which one works better.
But what i do not get is why everything works flawlessly when the option " everything through vpn " is set to yes , but when i want to do it manually ( 2 devices only ) the dns doesnt get configured correctly ...

The problem stems from the way you've implemented PBR. By NOT allowing the default gateway to be changed to the VPN, it has removed the router itself (and by extension, all its internal processes, like DNSMasq) from the VPN. And since your clients are depending upon DNSMasq as their local DNS proxy, the public DNS servers it's accessing on their behalf risk being accessed over the WAN!

I say "risk" rather than definitely because there are many other factors that determine if the WAN or VPN will be used to access the DNS servers w/ your current PBR configuration.

That's why changing the client's DNS servers within DHCP, or by redirecting its DNS queries w/ DNAT, works. You're bypassing the router's DNS proxy. So whether the router is or isn't bound to the VPN becomes irrelevant, at least for this particular issue. And now DNS queries for clients in PBR are routed over the VPN, just like all the other traffic for those same clients.

That's not to say you couldn't reconfigure DNS on the router to make sure its public DNS servers were forced back over the VPN. But that would require knowing a lot more about your config, something that's probably not practical (esp. since I know nothing about Padavan). The easiest solution is to just use one of the methods I've already mentioned.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top