iptables -t nat -A POSTROUTING -o $(nvram get wan_iface) -j MASQUERADE
This will NAT out the WAN, not using the VPN Client.
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
Check that the VPN Client is on tun1.
PS. It's better to use -I instead of -A, so the rules get first in chain and not last.
Okay quote another user & also asking EGC as I am using their script.
1. ERC quick question I notice in another persons ref to your earlier script you had:
TID="11"
VPN_GW_OLD="old"
vs (no quotes) in the latest v5.05.sh
TID=11
VPN_GW_OLD=old
Is this correct or doesnt matter?]
Also my ClientVPN-paid is TUN1, ServerVPN TUN2, is the script correct in that regard?
2. Is the script made, from CLI do: cat /tmp/simple-br.sh (small spelling error but had me going in circles testing), should be from CLI do: cat /tmp/simple-pbr.sh
3. Usage for me, I think in general I want MOST of the LAN devices to go via my VPN-client (paid), with exclusions such as CCTV which will sit behind the router, with no port fowards but my mobile devices (clients) connected to my VPN-server can only see through the tunnel.
3.a So I went with NOT entering this pull-filter ignore "redirect-gateway" in addConfig of VPN-client, as if I read this line of your guide correct:-
• Decide which should be your standard route, if this is the WAN then enter: pull-filter ignore "redirect-gateway" in the additional config of the OVPN client.
And I dont I want the standard route (assuming out) to be via the VPN-client (paid).
3.b But I couldnt get the client to connect at all with this one line in the script rules:-
add_rule from 10.8.0.2 #ChrisMOB
Which was effectively lifted/removed from the PBR rules entered as simply 10.8.0.2/32
Am I incorrectly reading point 3.a above, as when I added the "redirect-gateway" command I could connect to the VPN-server as a client? But surely my traffic is via the WAN, my WAN IP on the mobile is the ISP WAN not the VPN-paid one so it seems so.
On the FIREWALL part quoting "Per Yngve Berg"
I had:
iptables -t nat -A POSTROUTING -o $(nvram get wan_iface) -j MASQUERADE
But should this be (in my scenario) as most traffic out through VPN, not WAN-ISP:-
iptables -t nat -I POSTROUTING -o tun1 -j MASQUERADE
Please note the -I
Also I need to connect a telephone server which wants a UDP port forward in to my network, as I cannot add the provider to be a "client" on my VPN-server, is there a port forward rule I should use OR does it not really matter as an open port is an open port?
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Thu Mar 14, 2019 16:33 Post subject:
1. Script changes now and then in v5.05 I was tidying up a bit, so it should be correct (as said earlier it is somewhat experimental )
2. Thanks for catching the typo I have corrected it.
3. Your assumption is correct. BUT you are using also an OVPN server that is needing the default route go out via the WAN so in your case you have to use pull-filter ignore "redirect-gateway"
When pull-filter ignore"redirect-gateway" is in place your outside clients connected to your OVPN server will have internet access via the WAN, if you place the ip's like 10.8.0.2 and 10.8.0.3 in the PBR script you will then have internet access via your out going VPN client to your commercial VPN provider
If you want your outside OVPN client have internet access when connected via you VPN server then you have to use
Code:
iptables -t nat -A POSTROUTING -o $(nvram get wan_iface) -j MASQUERADE
I would always add this rule
This has nothing to do with the OVPN client on your router (tun1) of course this client also needs a NAT rule otherwise you could never connect to the internet via tun1.
That is why in the DDWRT GUI of the OVPN client you always have to enable NAT (for TUN), when enabling this the rule will be put in place by DDWRT _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
3. Your assumption is correct. BUT you are using also an OVPN server that is needing the default route go out via the WAN so in your case you have to use pull-filter ignore "redirect-gateway"
When pull-filter ignore"redirect-gateway" is in place your outside clients connected to your OVPN server will have internet access via the WAN, if you place the ip's like 10.8.0.2 and 10.8.0.3 in the PBR script you will then have internet access via your out going VPN client to your commercial VPN provider
Okay thanks for response mate.
They "" differences in script okay then?
Firewall = put the command as instructed, in fact I hadn't tried the sample I posted (with the -I)...
Redirect = I added the filter ignore "redirect-gateway" as instructed.
This does allow me to client connect like I said earlier.
Quick DNSMasq question as it may be relevant, I did ask it before, but I asked a lot of silly Q's!
interface=tun2 AS PER YOUR oVPN GUIDE
interface=tun1 AS PER EXPRESSVPN GUIDE
I ask as it may be relevant.
Anyway keeping it simple, client Android Mobile connected and WAN IP is returned as the real WRT ISP IP.
Added my SurfacePC in the PBR script rule and WAN IP is returned as the real WRT ISP IP.
Like this:-
# --------------- BEGIN RULES ---------#
add_rule from 10.8.0.2 #ChrisMOB
add_rule from 192.168.49.75
# --------------- END RULES -----------#
Reading your post I have quoted above why is neither going out via the VPN, I assume they arent as wouldnt I get the virtualWAN-IP from the paid VPN?
Changed DNSMasq to interface=tun1 (BUT just see you recommend I make it TUN1? shall I change it?)
Ammended rules AND done a reboot (I reckon was BIGGEST issue which I know you state to do!) and from my client Android mobile (10.8.0.2) I can see my local CCTV VMS, in fact any LAN device regardless of being in the DHCP range listed below OR outside of it (static LAN devices):-
Also I can ping the external serverVPN-clients namely for example 10.8.0.2 below from both the listed DHCP range listed below OR outside of it (static LAN devices):-
# --------------- BEGIN RULES ---------#
add_rule from 10.8.0.2 #ChrisMob
add_rule from 10.8.0.3 #LeeMob
add_rule from 192.168.49.1/32 #DHCP range start
add_rule from 192.168.49.2/31
add_rule from 192.168.49.4/30
add_rule from 192.168.49.8/29
add_rule from 192.168.49.16/28
add_rule from 192.168.49.32/27
add_rule from 192.168.49.64/27
add_rule from 192.168.49.96/30
add_rule from 192.168.49.100/31 #DHCP range end
# --------------- END RULES -----------#
Devices in the rules list above get the fake paidVPN WAN-IP.
Those NOT listed get the real WAN-ISP one.
So perfect, so far, should I change the TUN1 to TUN2?
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Thu Mar 14, 2019 19:03 Post subject:
Great you got it working
If you want DNS pushed to your clients then yes you have to follow the rules in the advanced section. So specify tun2 in additional config of DNSMasq and push the DNS to your clients
I decided to have a play with my AsteriskPBX(raspbx).
First I have set up a new duckdnsDDNS running in the Pi as a cron task, this is because I wanted it to resolve the non WAN-ISP-IP and it to instead resolve the fake-IP from paid VPN, sorted works perfect.
My theory initial HOPE was to have the route both in AND out over the paidVPN, but its never going to happen as I dont think I can open any ports (back to original CCTV square1).
Please tell me if I am wrong?
Anyway failing that this is my step 2 solution:-
Achieve the registration to my SIP-trunk provider OUT of the serverVPN by adding it to your script rules.
This TAGs the real WAN-ISP-IP in the sip registration to them but the data would come back via the WAN (as this is where I told them to find me!), where I have already set up a small UDP range forward.
At the moment I have had enough, and tried my HOPE step 1, all in the paidVPN and although it successfully registered on their end, there was no call ability as data didnt make its was back (although I did turn off all port forwards).
So currently I have removed the RULE for that address from your script and it is all out/in via the WAN, this works but is less secure.
1. So initially am I correct, step1 HOPE is a non-starter?
2. If I do the step 2, should I use one of your scripts routing rules (suggested in guide), or is there something i am missing?
Thanks for the prompt response, always appreciated
I did have a good chat last week with expressVPN and they 100% dont support any port forwarding I actually had 2 different support members, TBH half the answers are "canned" rubbish, but they actually did say when I can cancel upto as I pre-paid for a year, so its fairly conclusive if they say you can get your money back, they must know the cannot do it!
So I am going to look at your provider, and funnily enough I am just looking at your other guide ref SFE, as I noticed last night my VPN speeds are shocking when using eVPN, I mean under 10M, versus 100M when disabled!
I dont think the issue is the SFE, on a v.good R7000 router, I like SFE but also like QOS for my PBX traffic shaping, but my Kodis also suddenly struggling with HD streams so its obviously the eVPN.
I think I may look at your provider.
Do you think SFE is worth messing with on my DD-WRT v3.0-r37015M kongac (09/23/1, I may be able to shape off the telephone system with another option perhaps VLAN the only two PBX devices (i.e. Im not a heavy SIP user).
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Fri Mar 15, 2019 10:40 Post subject:
From what I saw express VPN indeed does not do port forwarding.
Private internet Access is difficult with port forwarding, there are VPN providers which make it really easy, you can just set/ask a port in your VPN account.
SFE does not do much for VPN. VPN is very CPU intensive.
I get around 37 Mb/s on VPN, SFE does not do much on this.
Without SFE 250 Mb/s with SFE 550 Mb/s.
This is on an R6400v2 which has a comparable CPU as an R7000.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Sat Apr 20, 2019 7:45 Post subject:
Good news for everyone who can use some extra throughput while using Policy Based routing.
All builds after build 39556 have the patched SFE module made by @Quarkysg.
This patched SFE module is compatible with Policy Based Routing.
This means that you can keep Shortcut Forwading Engine enabled (at Setup page) while using Policy Based Routing!
I just did a quick speedtest with my Linksys E2000 using build 39572 and speeds improved from 45 Mb/s without SFE to 130 Mb/s with SFE (YMMV)
Hiya egc, I'm a DR-WRT newbie. I recently signed up with a VPN provider and was forcing all traffic through it. I have DD-WRT on a dedicated router behind a Fritzbox modem. One major issue I encountered was that remote access was no longer possible because the fritzbox would not route external ports when it no longer handled DHCP.
So I'm looking at PBR which I thought may resolve this issue and also give me more advanced internal management like destination mapping.
Can you suggest if your script would be the best tool for a newbie like me?
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Mon Apr 29, 2019 10:31 Post subject:
Well I would go back one step
What we first have to answer is how you are going to connect the routers.
You have the Fritzbox as ISP modem, and the DDWRT router as secondary router (Please always state your router model and build number)
You can daisy chain the routers i.e. have both routers on a different subnet and connect LAN<>WAN, that is the easiest but although you can have traffic between subnets by setting a static route on the Frizbox (which I assume is possible) and opening up the firewall, you will loose things like windows discovery and DLNA
because there is no broadcasting between subnets. Plus you have to use some form of PBR, my script or scripts from @eibgrad or even the built in PBR whith its limitations.
But this setup is the easiest to get it working, just reset the router make sure it is on a different IP subnet than the Fritzbox and connect LAN<>WAN.
The alternative setup is using the DDWRT router as a WAP: https://wiki.dd-wrt.com/wiki/index.php/Wireless_Access_Point .
You can run your VPN client on the WAP but you have to set the gateway of each client you want to use the VPN to the WAP as gateway address.
You can do that manually per client, and that will work and if you can live with this, I would use this configuration.
Maybe it is even possible that you can have the Fritzbox to hand out different gateways for different clients, DDWRT can do this with DNSMasq.
The beauty of this setup is that you do not have to use any form of PBR on the router and you have one subnet.
The choice is yours I (and others ) can assist you in both setups, although I do not have any experience with Fritzbox.