Menu
What's new
By:
Filters Better Search

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!

M

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.
 
www.snbforums.com

Kill switch doesn't work

It seems to me kill switch stopped working for me. I had 386.1.x FW and noticed after router reboot that my OpenVPN client is down and despite I had setting to prevent client access to Internet when VPN is down, client still had access to Internet. I could not make kill switch work so updated to...
www.snbforums.com www.snbforums.com
 
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.
 
Tech Junky said:
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.
Click to expand...

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.
 
eibgrad said:
www.snbforums.com

Kill switch doesn't work

It seems to me kill switch stopped working for me. I had 386.1.x FW and noticed after router reboot that my OpenVPN client is down and despite I had setting to prevent client access to Internet when VPN is down, client still had access to Internet. I could not make kill switch work so updated to...
www.snbforums.com www.snbforums.com
Click to expand...
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.
 
mygothamster said:
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
Click to expand...

To get the interface name correctly you need to use nvram get wan0_gw_ifname. That will return ppp0 in your case.
 
You must log in or register to reply here.

Similar threads

NoBenefit
Does my iptables looks normal?
Replies
1
Views
1K
ColinTaylor
C
Nick B
Allowing Incoming WAN Connections for WireGuard Client Listed in Director
Replies
7
Views
2K
arkywein
A
T
Internet connection via ISP despite existing VPN connection in the Asus RT-AC 86U
Replies
5
Views
374
tom
T
L
merlin default iptables. why are there strange logdrops for specific pattens and ips?
Replies
3
Views
1K
ColinTaylor
C
P
How would you check or change the router's http or https webinterface port via telnet (only)?
Replies
2
Views
306
powersupply
P
Similar threads
Thread starter Title Forum Replies Date
SkierInAvon Asus Merlin - iptables command (not working?) Asuswrt-Merlin 8
A Duckdns on Asus merlin router Asuswrt-Merlin 1
P Accessing remotly Server While Using VPN on Asus Router with Merlin Firmware Asuswrt-Merlin 9
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1
H Asus RT-AX58U v2 Merlin: Route all traffic to Pi-hole (running directly on router itself) Asuswrt-Merlin 12
K How to block LAN access for a wired device on ASUS Merlin (Firmware 3004.388.8_2)? Asuswrt-Merlin 12
N AiMesh, router stock asus, wired AP merlin. Cant connect to AP 5ghz Asuswrt-Merlin 4
D Comcast email - RT-AX86U Pro - ASUS 3.0.0.6.102_34314 works, Merlin 3004_388.8_2 doesn't Asuswrt-Merlin 16
J Asus GT-BE98 Pro and Merlin, no internet when VPN disabled Asuswrt-Merlin 4
K GT-BE98 Asus Merlin Asuswrt-Merlin 2

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Members online

Total: 918 (members: 46, guests: 872)
Top