What's new

ASUS Merlin iptables rule not applying.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

mygothamster

New Around Here
I am setting up a VPN on my router so I can work remotely from another country without working knowing. I have setup a home VPN and have my ASUS RT-AC86U router as the client. If the VPN drops my computer will connect to the work network and the overseas IP will be logged in Splunk and an alert will be auto generated for someone to investigate. Due to this I need to implement a firewall rule to block connections in case the VPN drops. When applying the following rules my connection is not being blocked though...

iptables -I FORWARD -o eth0 -j REJECT

I have also tried


iptables -I FORWARD -i br0 -s 10.0.0.2 -o $(nvram get wan0_ifname) -j DROP
iptables -I FORWARD -o $(nvram get wan0_ifname) -j REJECT
iptables -I FORWARD -o eth0 -j REJECT
iptables -I FORWARD -o eth1 -j REJECT
iptables -I INPUT -i eth1 -j REJECT
iptables -I INPUT -i eth0 -j REJECT

however I am still able to connect to the internet from my PC????


Currently using an ASUS RT-AC86U with the latest Merlin firmware RT-AC86U_386.5_2.
nvram get wan0_ifname = eth0


Code:
#!/bin/sh

iptables -I FORWARD -i br0 -s 10.0.0.2 -o $(nvram get wan0_ifname) -j DROP
iptables -I FORWARD -o $(nvram get wan0_ifname) -j REJECT
iptables -I FORWARD -o eth0 -j REJECT
iptables -I FORWARD -o eth1 -j REJECT
iptables -I INPUT -i eth1 -j REJECT
iptables -I INPUT -i eth0 -j REJECT
iptables -I FORWARD -s 10.0.0.2 -o eth0 -j REJECT

echo hello > /jffs/scripts/log.txt


*am I missing a step or configuration on the router to enable the rules?



user@RT-AC86U-3640:/jffs/scripts# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N INPUT_PING
-N NSFW
-N OUTPUT_DNS
-N OUTPUT_IP
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N WGNPControls
-N default_block
-N logaccept
-N logdrop
-N logdrop_dns
-N logdrop_ip
-N other2wan
-A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i eth1 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT ! -i lo -p tcp -m tcp --dport 5152 -j DROP
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j DROP
-A FORWARD -o eth1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o eth0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o eth0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 10.0.0.2/32 -i br0 -o eth0 -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o ppp0 -j other2wan
-A FORWARD ! -i br0 -o eth0 -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -j NSFW
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -j DROP
-A OUTPUT -p udp -m udp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -p tcp -m tcp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -j OUTPUT_IP
-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT
-A INPUT_PING -i ppp0 -p icmp -j DROP
-A INPUT_PING -i eth0 -p icmp -j DROP
-A OUTPUT_DNS -m string --hex-string "|10706f697579747975696f706b6a666e6603636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d72666a656a6e666a6e65666a6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1131306166646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f376d667364666173646d6b676d726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d386d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f3966646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|086861636b7563647403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|076c696e77756469056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f6c6b6a68676664736174727975696f03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0b6d6e627663787a7a7a313203636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077131313133333303746f7000|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|057371353230056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077563746b6f6e6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0e7a786376626d6e6e666a6a66777103636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0a65756d6d6167766e627003636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_IP -d 193.201.224.0/24 -j logdrop_ip
-A OUTPUT_IP -d 51.15.120.245/32 -j logdrop_ip
-A OUTPUT_IP -d 45.33.73.134/32 -j logdrop_ip
-A OUTPUT_IP -d 190.115.18.28/32 -j logdrop_ip
-A OUTPUT_IP -d 51.159.52.250/32 -j logdrop_ip
-A OUTPUT_IP -d 190.115.18.86/32 -j logdrop_ip
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j DROP
-A SECURITY -j RETURN
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP
-A logdrop_dns -j LOG --log-prefix "DROP_DNS " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_dns -j DROP
-A logdrop_ip -j LOG --log-prefix "DROP_IP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_ip -j DROP
-A other2wan -i tun+ -j RETURN
-A other2wan -j DROP
 
Last edited:
So it looks like eth0 is not my wan interface? it is ppp0.

After running

>iptables -I FORWARD -o ppp0 -j REJECT

My PC no longer can ping 8.8.8.8 when connected/disconnected to the VPN, however the web browser on the same PC is still able to access internet on the vpn?!. When accessing whatismyip it shows the vpn servers ip address.
It can also ping the vpn server on 192.168.1.1, although I cant see how from the route table.


Any idea why this happens?

user@RT-AC86U-3640:/tmp/home/root# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 203.134.4.182 0.0.0.0 UG 0 0 0 ppp0
8.8.4.4 203.134.4.182 255.255.255.255 UGH 1 0 0 ppp0
8.8.8.8 203.134.4.182 255.255.255.255 UGH 1 0 0 ppp0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
10.100.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun11
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
203.134.4.182 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
 
This is a mess to say the least.

Code:
-P INPUT ACCEPT #change to DROP
-P FORWARD DROP
-P OUTPUT ACCEPT #change to DROP

-N ACCESS_RESTRICTION
-N DNSFILTER_DOT
-N FUPNP
-N INPUT_ICMP
-N INPUT_PING
-N NSFW
-N OUTPUT_DNS
-N OUTPUT_IP
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N WGNPControls
-N default_block
-N logaccept
-N logdrop
-N logdrop_dns
-N logdrop_ip
-N other2wan

-A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i eth1 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -m icmp --icmp-type 8 -j INPUT_PING
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT ! -i br0 -j PTCSRVWAN
-A INPUT -i br0 -j PTCSRVLAN
-A INPUT ! -i lo -p tcp -m tcp --dport 5152 -j DROP
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -p icmp -j INPUT_ICMP
-A INPUT -j DROP


-A FORWARD -o eth1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o eth0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -o eth0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -s 10.0.0.2/32 -i br0 -o eth0 -j DROP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o ppp0 -j other2wan
-A FORWARD ! -i br0 -o eth0 -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -j NSFW
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -m state --state NEW -j OVPN
-A FORWARD -j DROP

-A OUTPUT -p udp -m udp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -p tcp -m tcp --dport 53 -m u32 --u32 "0x0>>0x16&0x3c@0xc>>0x1a&0x3c@0x8>>0xf&0x1=0x0" -j OUTPUT_DNS
-A OUTPUT -j OUTPUT_IP

-A INPUT_ICMP -p icmp -m icmp --icmp-type 8 -j RETURN
-A INPUT_ICMP -p icmp -m icmp --icmp-type 13 -j RETURN
-A INPUT_ICMP -p icmp -j ACCEPT

-A INPUT_PING -i ppp0 -p icmp -j DROP
-A INPUT_PING -i eth0 -p icmp -j DROP

-A OUTPUT_DNS -m string --hex-string "|10706f697579747975696f706b6a666e6603636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d72666a656a6e666a6e65666a6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1131306166646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f376d667364666173646d6b676d726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0d386d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f3966646d617361787373736171726b03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|1265666274686d6f6975796b6d6b6a6b6a677403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|086861636b7563647403636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|076c696e77756469056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0f6c6b6a68676664736174727975696f03636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0b6d6e627663787a7a7a313203636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077131313133333303746f7000|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|057371353230056633333232036e657400|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|077563746b6f6e6503636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0e7a786376626d6e6e666a6a66777103636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns
-A OUTPUT_DNS -m string --hex-string "|0a65756d6d6167766e627003636f6d00|" --algo bm --to 65535 --icase -j logdrop_dns

-A OUTPUT_IP -d 193.201.224.0/24 -j logdrop_ip
-A OUTPUT_IP -d 51.15.120.245/32 -j logdrop_ip
-A OUTPUT_IP -d 45.33.73.134/32 -j logdrop_ip
-A OUTPUT_IP -d 190.115.18.28/32 -j logdrop_ip
-A OUTPUT_IP -d 51.159.52.250/32 -j logdrop_ip
-A OUTPUT_IP -d 190.115.18.86/32 -j logdrop_ip

-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j DROP
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -j DROP
-A SECURITY -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j RETURN
-A SECURITY -p icmp -m icmp --icmp-type 8 -j DROP
-A SECURITY -j RETURN

-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT

-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP

-A logdrop_dns -j LOG --log-prefix "DROP_DNS " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_dns -j DROP

-A logdrop_ip -j LOG --log-prefix "DROP_IP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop_ip -j DROP

-A other2wan -i tun+ -j RETURN
-A other2wan -j DROP

DROP - should be the default for the -P options which will reject all packets unless there's a rule. This secures the router unless permitted.

Do you really need all of the logging? Getting rid of all of that condenses things to be more manageable.

Your rules are all out of order because you keep using the -I vs -A or take the config and put it into notepad and actually reorder it properly.

Code:
-A INPUT -j PERMIT-IN
-A FORWARD -j PERMIT-FWD
-A OUTPUT -j PERMIT-OUT
-A PERMIT-FWD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-FWD -m conntrack --ctstate NEW -j ACCEPT
-A PERMIT-FWD -j DROP
-A PERMIT-IN -i lo -j ACCEPT
-A PERMIT-IN -i br0 -j ACCEPT
-A PERMIT-IN -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-IN -j DROP
-A PERMIT-OUT -o lo -j ACCEPT
-A PERMIT-OUT -o br0 -j ACCEPT
-A PERMIT-OUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A PERMIT-OUT -m conntrack --ctstate NEW -j ACCEPT
-A PERMIT-OUT -j DROP

*nat
-A POSTROUTING -o nordlynx -j MASQUERADE
-A POSTROUTING -o bo0 -j MASQUERADE

This is my config that I've been using for quite awhile w/o any issues. This blocks everything and only permits anything that originates from the LAN > WAN and only return traffic from the outside > in. Going from this to permitting your VPN connection should be simple. There's no need to have all of the random bits and ends currently living in yours. DROP is more effective for speed / processing packets than all the the rejects / jumps you're doing.

I would start over with this.... the only thing that doesn't make sense is you have a rule for OVPN but, nothing in the rules for that.

Code:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP


-N OVPN


-A INPUT -i lo  -j ACCEPT
-A INPUT -i br0  -j ACCEPT
-A INPUT -m state --state NEW -j OVPN
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j DROP


-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -j ACCEPT
-A FORWARD -j DROP

-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o br0 -j ACCEPT
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -j DROP

*nat
-A POSTROUTING -o ppp0 -j MASQUERADE

I suppose most of the clutter is from using the scripts within the router to add / remove rules instead of doing it by hand. I would figure out which rules get implemented by setting the OVPN profile and then clean it up and import it rather than rely on the router to do it for you. If you keep it simple then it's easier to manage and with this setup it should make more logical sense when changing things. If you group things into IN/OUT/FWD like I do it's easier to add / move rules within each zone. Using notepad also is a lot easier than doing it all from CLI when trying to keep things in the right order of application and not end up with the mess you have currently.

If you look in the flash there should be a "rules.v4" possibly related to the iptables and you should be able to SCP the file to / from the router or copy it over as a test file you can edit from within the router and then simply issue a cp command to replace the existing rules when you want to change something. I use a DIT linux box as my router and edit the config on Windows in notepad and then run a series of commands to import / backup the FW. I've played around with some of the rules you have from I'm guessing reading the same blogs and such but, they're useless and just take up CPU cycles and slow things down.
 
The only rules I added were the ones above. I really only wanted to add 1 rule which blocks the any LAN host from accessing WAN in case the vpn goes down. I am hesitant to start deleting other rules as everything else in there is default with the firmware and will be added back after a restart unless i modify other scripts.

After REJECTING interface ppp0 it is looking more like a routing issue now... With not all traffic going through the vpn tunnel or if it is im not able to see the route. From testing, CMD line is going through ppp0 and browser is going over tun11? how do I get everything to go via the tunnel on the LAN host, while the firewall blocks WAN interface.
 
 
Well, then there's a simple solution. Change the MASQUERADE to only include the VPN interface for NAT and it will kill traffic outbound until VPN is restored.
 
Well, then there's a simple solution. Change the MASQUERADE to only include the VPN interface for NAT and it will kill traffic outbound until VPN is restored.

Relying on a misconfiguration (i.e., disabling NAT for the WAN, if that's what you meant) is NOT a good idea imo. The traffic will still be routed over the WAN, but become unroutable once it reaches the upstream router. Minimally, this reveals the presence of your private network to that router, and may even cause issues w/ your ISP if they happen to maintain the same private IP network. I've seen ISPs complain to customers about this in the past. The proper way to kill the traffic is to use the FORWARD chain to NOT allow the routing, AT ALL.

NOTE: In some cases, routers will automatically configure the firewall to block bogons across the WAN for this very reason. I'm assuming this is NOT the case here.
 
Well, if you push the NAT to exclusively use the "tun" interface all LAN traffic is forced to use the VPN and not allowed to pass to the WAN if the IF is down.

The WAN can still allow the app/VPN to connect to bring the TUN up and allow LAN to pass again.

FWD is just allowing traffic to pass from the outside to the inside / vice versa if it's not in the IP R / IP A tables.

To restrict things on the OUTPUT side you would bind the VPN IF in the rule regarding conntrack statements above. and add a POSTROUTING to *nat to supplement using ppp0 as well.

It can get a bit over complicated though and will require some testing to confirm on each specific network as to how it will perform but, the OP rules are excessive and mostly just taking up space / resources.
 
Thanks @eibgrad, the script works great. Your a legend!

I realised I was testing with ping from CMD which is blocked by something somewhere along the line.. not sure where though as im able to ping the internal network on the server side from my PC, but not 8.8.8.8 from my PC while connected to the vpn.
 
Figured out pinging 8.8.8.8 was no working because the ovpnc1 route table was routing 8.8.8.8 traffic to WAN as the DNS server

Code:
user@RT-AC86U-3640:/tmp/home/root# ip rule
0:      from all lookup local
10001:  from all lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

user@RT-AC86U-3640:/tmp/home/root# ip route show table ovpnc1
default via 10.100.0.5 dev tun11
8.8.4.4 via 203.134.4.181 dev ppp0 metric 1
8.8.8.8 via 203.134.4.181 dev ppp0 metric 1
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
10.100.0.1 via 10.100.0.5 dev tun11
10.100.0.5 dev tun11 proto kernel scope link src 10.100.0.6
58.107.160.72 via 203.134.4.181 dev ppp0
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.36.213
192.168.1.0/24 via 10.100.0.5 dev tun11 metric 500
192.168.1.1 via 10.100.0.5 dev tun11
203.134.4.181 dev ppp0 proto kernel scope link
 
As I've mentioned many times in other threads, starting w/ 386.4, ASUS now statically binds the DNS servers defined on the WAN, to the WAN, presumably for the benefit of the WAN connectivity check. Users needs to keep this change in mind when dealing w/ the DNS configuration of their routers. Things that worked in the past might not now work as expected.
 
So it looks like eth0 is not my wan interface? it is ppp0.

After running

>iptables -I FORWARD -o ppp0 -j REJECT

My PC no longer can ping 8.8.8.8 when connected/disconnected to the VPN, however the web browser on the same PC is still able to access internet on the vpn?!. When accessing whatismyip it shows the vpn servers ip address.
It can also ping the vpn server on 192.168.1.1, although I cant see how from the route table.


Any idea why this happens?

user@RT-AC86U-3640:/tmp/home/root# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 203.134.4.182 0.0.0.0 UG 0 0 0 ppp0
8.8.4.4 203.134.4.182 255.255.255.255 UGH 1 0 0 ppp0
8.8.8.8 203.134.4.182 255.255.255.255 UGH 1 0 0 ppp0
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
10.100.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun11
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
203.134.4.182 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

To get the interface name correctly you need to use nvram get wan0_gw_ifname. That will return ppp0 in your case.
 

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