What's new

Since upgrading to firmware 386.3_2, my Internet will not stay connected for even a day.

  • 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!

Please remind me, how are you configuring the router/network after doing a full reset? What settings/features and options are you changing past defaults? Are you using scripts? Do you have a USB drive (or other USB devices) plugged into the router?

These are the minimum steps required to reset the router.

[Wireless] ASUS router Hard Factory Reset | Official Support | ASUS Global


These are the suggested defaults after doing the above.

Fully Reset / Best Practice Setup / More


If the above doesn't get your router/network to a good/known state, then I would be following the suggestions below, followed by the best practice link above.

Fully Reset Router and Network

HTH
 
One difference to the other thread you referenced is that I purchased a new router as part of my troubleshooting. So it is impossible that any of my old settings were "not being reset/cleared" because this router never had any of them. I started from scratch. I also purchased a new VPN provider and got a new ISP.

The new router is not defective and it works fine with basic settings. My problem is that I cannot get my current configuration to function as intended.

Please remind me, how are you configuring the router/network after doing a full reset?

I have one VPN client (ExpressVPN) with their "stock" upd ovpn file, and I have the built-in kill switch enabled. I'm using the VPN Director feature. This is the area of configuration I cannot get stable. Other than that, there is nothing unusual about my configuration and nothing important I have changed from default*.

* I will add more details in response to your question about scripts.

What settings/features and options are you changing past defaults?

As described above. All default settings are OK for me except I need to have a working VPN client tunnel and kill switch. I will speak about YazFi in the next section.

Are you using scripts?

No, except for YazFi, which I have determined is not related to this issue. The reasons for that determination are stated earlier in this thread. The problematic behavior existed before I installed YazFi and it is unchanged after installing it. I have removed and re-added YazFi, and it does not impact the issue. My other router which had the same problematic behavior never had YazFi installed.

Do you have a USB drive (or other USB devices) plugged into the router?

No.

Recap:

All wired and wireless clients lose access to the internet after a few days. Initially I tried a lot of haphazard things to solve that problem, including adding more VPN clients. I was advised to simplify my configuration, so I removed all that extra stuff I tried as part of my troubleshooting. I now have a clean and simple configuration with one VPN client and no scripts except for YazFi, as stated above.

What this thread helped me discover is that when the clients lose internet connectivity, the WAN interface and the VPN tunnel are still up!

The clients are connected to the router and the router is connected to the Internet. Between those two points, traffic is blocked. That's the issue.

I can work around the issue with a reboot without changing any settings, and things will work as expected for several days. I also learned in this thread that any action I take to "apply settings" by the router's GUI, even if those settings changes are trivial and don't really change anything, will resolve the problem without a reboot or even without a change in the VPN connection (because that connection never appears to go down, based on testing done earlier in this thread).
 
Last edited:
I will add further that since I have two AC86U's, two ISP's and two VPN providers, I can do certain experiments that help with troubleshooting. I'm open to suggestions.

However, what I personally think might be most helpful is if we can diagnose how / why traffic gets blocked when the WAN interface is up and the VPN tunnel is up. That's where my troubleshooting stalled out, and that's where I would like to continue.

If anyone can help me with suggestions I would love to track that down and to understand it. Thank you -- and thanks for all the help so far. I have learned a lot. I want to learn more.
 
Your answers are a little stingy, with little of the information asked for. :)

If I'm re-reading your first few posts correctly, do you have more than one connection to your ISP?

It seems like you have two others directly connected to your ISP, plus the Asus router.

Are you paying for more than one public IP address?
 
Is your NTP healthy and time correct after you experience issues?
The router maintains a working WAN interface as well as a working VPN tunnel. I am able to complete a traceroute thru the tunnel (see earlier msg in this thread for the output), even while the wired and wireless clients are unable to connect to the internet.

Doesn't the working tunnel with working name resolution rule out a possible clock/time problem? Thank you.
 
Last edited:
Your answers are a little stingy, with little of the information asked for. :)
Not on purpose. But thanks for asking for clarification.

If I'm re-reading your first few posts correctly, do you have more than one connection to your ISP?

I have two ISP's right now: Comcast and a business class AT&T fiber connection. I am only testing with one ISP at a time however. I am not using dual WAN if that's what you are asking.

It seems like you have two others directly connected to your ISP, plus the Asus router.

Yes. With AT&T I have 5 usable IP addresses on the LAN side. I have set up two physically separate LANs.

Are you paying for more than one public IP address?

I have 1 public IP with AT&T and I have another one with Comcast, and yes, I am paying for both, but only until I solve this issue.

Please ask any other questions you have. Thanks for your interest.
 
The router maintains a working WAN interface as well as a working VPN tunnel. I am able to complete a traceroute thru the tunnel (see earlier msg in this thread for the output), even while the wired and wireless clients are unable to connect to the internet.

Well that's the 64k question; how can it be that when your wired and wireless LAN clients lose internet access, the WAN and VPN continue to run normally, verified by doing a traceroute specifically bound to the VPN's network interface. But then, if you reinitialize the WAN, even indirectly as the result of some minor change, voila, it starts working again for those same LAN clients. IOW, testing on the router suggests all is well, but that's contradicted by the behavior of the LAN clients once the WAN (and by extension, the VPN) is reinitialized, suggesting all is NOT well.

I haven't a clue at this point how that could be. And there's only so much that can be done via these forums. We have to rely on your reporting, and our own experiences. And sometimes that's simply not enough.

P.S. That's why I though this might only be a DNS issue. But that proved NOT to be the case.
 
Okay, here is where I'm stuck now. "With AT&T, I have 5 usable IP addresses on the LAN side". Doesn't make much sense to me. :)

Draw us a diagram, please. Label it fully. Give us a single post with all the details, as concise as possible (point form, or in a table).

Looking forward to your next few posts.
 
Thinking some more about this, one thing that could explain why the VPN continues to work when connected to the router, but NOT for LAN clients, is if for some reason the firewall has lost the NAT rule for the OpenVPN client. LAN clients *must* be NAT'd in order to communicate across the tunnel, but NOT the router. And so if something (and I have no idea at this point what that could be) has reinitialized the firewall or otherwise disturbed that NAT rule, that might explain the observed behavior.

Next time this happens, dump the firewall.

Code:
iptables -vnL
iptables -t nat -vnL

And instead of reinitializing the WAN to get things rolling again, restart the OpenVPN client. See if that is sufficient.

Code:
service restart_vpnclient1

If it is, then perhaps installing my OpenVPN watchdog would solve the problem. It won't necessarily explain *why* things stop working, but the point of the watchdog is to NOT be concerned w/ the why (sometimes we're just not going to have a good answer), but just to keep things working, and deal w/ the why later.

 
  • Like
Reactions: DTS
Thinking some more about this, one thing that could explain why the VPN continues to work when connected to the router, but NOT for LAN clients, is if for some reason the firewall has lost the NAT rule for the OpenVPN client. LAN clients *must* be NAT'd in order to communicate across the tunnel, but NOT the router. And so if something (and I have no idea at this point what that could be) has reinitialized the firewall or otherwise disturbed that NAT rule, that might explain the observed behavior.

Next time this happens, dump the firewall.

Code:
iptables -vnL
iptables -t nat -vnL

And instead of reinitializing the WAN to get things rolling again, restart the OpenVPN client. See if that is sufficient.

Code:
service restart_vpnclient1

If it is, then perhaps installing my OpenVPN watchdog would solve the problem. It won't necessarily explain *why* things stop working, but the point of the watchdog is to NOT be concerned w/ the why (sometimes we're just not going to have a good answer), but just to keep things working, and deal w/ the why later.

Thank you. Great suggestions. The last few days I have had my router set to reboot each day and the problem has not occurred. I will stop the automatic reboots, wait a few days, and then try your suggestions.
 
Okay, here is where I'm stuck now. "With AT&T, I have 5 usable IP addresses on the LAN side". Doesn't make much sense to me. :)

Draw us a diagram, please. Label it fully. Give us a single post with all the details, as concise as possible (point form, or in a table).

Looking forward to your next few posts.

OK, here it is in point form.

1. AT&T BGW320-505. Image attached. My AT&T service offers me 5 static IP addresses. For discussion, let's say they are: 175.101.62.181/29.

2. Asus RT-AC86U. WAN port connected to LAN port #3 of BGW320-505. AC86U WAN configured with static IP address 175.101.62.183, subnet mask 255.255.255.248, and gateway 175.101.62.186.

3. Wireless clients connected to AC86U. LAN side of AC86U uses 192.168.x.x address ranges and the built-in DHCP server. I have, during testing only, also connected a laptop directly to one of the LAN ports on the AC86U via Ethernet cable.

4.The other LAN ports on the BGW320-505 are not connected to this subnet. But I can use another AT&T IP address to additionally & independently verify that my AT&T service is up when I am having trouble with the router.

It's really that simple. Just an ISP modem and my router and wireless clients. I guess you might want more details, but I'm not sure what else to add, so please ask.
 

Attachments

  • BGW320.png
    BGW320.png
    640.7 KB · Views: 100
Last edited:
It went a few days longer before the issue occurred this time, but it happened again last night, so I am starting the diagnostics today. I will post updates.
 
Thinking some more about this, one thing that could explain why the VPN continues to work when connected to the router, but NOT for LAN clients, is if for some reason the firewall has lost the NAT rule for the OpenVPN client. LAN clients *must* be NAT'd in order to communicate across the tunnel, but NOT the router. And so if something (and I have no idea at this point what that could be) has reinitialized the firewall or otherwise disturbed that NAT rule, that might explain the observed behavior.

Next time this happens, dump the firewall.

Code:
iptables -vnL
iptables -t nat -vnL

And instead of reinitializing the WAN to get things rolling again, restart the OpenVPN client. See if that is sufficient.

Code:
service restart_vpnclient1

If it is, then perhaps installing my OpenVPN watchdog would solve the problem. It won't necessarily explain *why* things stop working, but the point of the watchdog is to NOT be concerned w/ the why (sometimes we're just not going to have a good answer), but just to keep things working, and deal w/ the why later.

 
Here's all the info you requested.

Code:
ASUSWRT-Merlin RT-AC86U 386.3_2 Fri Aug  6 21:48:26 UTC 2021

admin@AC86U-Merlin:/tmp/home/root# iptables -vnL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 3507  307K INPUT_PING  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
  11M 8283M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 4801  466K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
1747K  338M PTCSRVWAN  all  --  !br0   *       0.0.0.0/0            0.0.0.0/0
 475K   43M PTCSRVLAN  all  --  br0    *       0.0.0.0/0            0.0.0.0/0
 475K   43M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0            state NEW
1664K  330M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0            state NEW
83217 7816K OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 INPUT_ICMP  icmp --  *      *       0.0.0.0/0            0.0.0.0/0
77771 3745K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  11M 7746M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 other2wan  all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0
    1   280 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
 1925 93041 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID
 177K   14M NSFW       all  --  *      *       0.0.0.0/0            0.0.0.0/0
 177K   14M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate DNAT
    0     0 OVPN       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 125M packets, 68G bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain ACCESS_RESTRICTION (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DNSFILTER_DOT (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FUPNP (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT_ICMP (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 13
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0

Chain INPUT_PING (1 references)
 pkts bytes target     prot opt in     out     source               destination
  283 14954 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0

Chain NSFW (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain OVPN (2 references)
 pkts bytes target     prot opt in     out     source               destination
 5446 4071K DROP       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0

Chain PControls (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain PTCSRVLAN (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PTCSRVWAN (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain SECURITY (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02 limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x02
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04 limit: avg 1/sec burst 5
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcpflags: 0x17/0x04
    0     0 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8 limit: avg 1/sec burst 5
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain default_block (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain logaccept (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "ACCEPT "
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain logdrop (0 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW LOG flags 7 level 4 prefix "DROP "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain other2wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
admin@AC86U-Merlin:/tmp/home/root# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 58051 packets, 4502K bytes)
 pkts bytes target     prot opt in     out     source               destination
 3918  196K GAME_VSERVER  all  --  *      *       0.0.0.0/0            175.101.62.183
 3918  196K VSERVER    all  --  *      *       0.0.0.0/0            175.101.62.183

Chain INPUT (policy ACCEPT 19325 packets, 1389K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 39213 packets, 2918K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 64309 packets, 4783K bytes)
 pkts bytes target     prot opt in     out     source               destination
 3357  208K PUPNP      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
    0     0 MASQUERADE  all  --  *      eth0   !175.101.62.183          0.0.0.0/0
  240 78408 MASQUERADE  all  --  *      br0     192.168.100.0/24      192.168.100.0/24

Chain DNSFILTER (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain GAME_VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain LOCALSRV (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PCREDIRECT (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PUPNP (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination
 3918  196K VUPNP      all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain VUPNP (1 references)
 pkts bytes target     prot opt in     out     source               destination

admin@AC86U-Merlin:/tmp/home/root# ip route
default via 175.101.62.186 dev eth0
10.72.1.129 dev tun11 proto kernel scope link src 10.72.1.130
175.101.62.180/29 dev eth0 proto kernel scope link src 175.101.62.183
175.101.62.186 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.1

admin@AC86U-Merlin:/tmp/home/root# ip rule
0:      from all lookup local
10010:  from 192.168.20.0/24 lookup main
10210:  from 192.168.100.0/24 lookup ovpnc1
10211:  from 192.168.1.0/24 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
<succeeds after 7 hops>
 7  8.8.8.8  48.499 ms  49.337 ms  48.050 ms

NOTE: as in prior cases of this problem, the clients do not have Internet access even though the diagnostics indicate that the tunnel is up.

Code:
admin@AC86U-Merlin:/tmp/home/root# pidof vpnclient1
8942

admin@AC86U-Merlin:/tmp/home/root# service restart_vpnclient1

Done.
admin@AC86U-Merlin:/tmp/home/root# pidof vpnclient1
admin@AC86U-Merlin:/tmp/home/root# echo $?
1

NOTE: at this moment clients had Internet access now, but the VPN tunnel is not up. Client IP is my AT&T IP address. So I restarted the vpn client again.

Code:
admin@AC86U-Merlin:/tmp/home/root# service restart_vpnclient1

Done.

admin@AC86U-Merlin:/tmp/home/root# pidof vpnclient1
2872

admin@AC86U-Merlin:/tmp/home/root# traceroute -ni tun11 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
<succeeds after 7 hops>
 7  8.8.8.8  47.714 ms  51.358 ms  216.239.43.63  47.757 ms

Now the clients have proper Internet access through the tunnel. I did not have to make any changes other than to restart vpnclient1 twice.
 
Thanks for the info. I probably should have asked for even more, just to be sure that what I think I'm seeing is the case (ifconfig, ip route show table ovpnc1, maybe even the syslog).

But at least based on those dumps, it appears the tunnel is still up based on the fact that the main routing table still contains a reference to tun11 (that would automatically be pulled by the routing system if it wasn't).

Code:
admin@AC86U-Merlin:/tmp/home/root# ip route
default via 175.101.62.186 dev eth0
10.72.1.129 dev tun11 proto kernel scope link src 10.72.1.130
175.101.62.180/29 dev eth0 proto kernel scope link src 175.101.62.183
175.101.62.186 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.1

And the ip rules are still in place for ovpnc1...

Code:
admin@AC86U-Merlin:/tmp/home/root# ip rule
0:      from all lookup local
10010:  from 192.168.20.0/24 lookup main
10210:  from 192.168.100.0/24 lookup ovpnc1
10211:  from 192.168.1.0/24 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

But as I suspected, the tunnel is no longer being NAT'd (where's the reference to tun11?)!

Code:
Chain POSTROUTING (policy ACCEPT 64309 packets, 4783K bytes)
pkts bytes target     prot opt in     out     source               destination
3357  208K PUPNP      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
    0     0 MASQUERADE  all  --  *      eth0   !175.101.62.183          0.0.0.0/0
  240 78408 MASQUERADE  all  --  *      br0     192.168.100.0/24      192.168.100.0/24

It also seems a bit unusual that there are NO hits on the NAT'ing of the WAN. In all that time since the last failure, not a single client in the 192.168.20.0/24 network (which is bound to the main table and thus the WAN (eth0)) requested internet access?!

Looks to me as if something reinitialized the NAT table, and was done unbeknownst to the OpenVPN client.

Seems a bit unusual as well that the Inbound Tunnel option (which is set to Block) is showing an unusually high level of dropped packets (all coming from the INPUT chain).

Code:
Chain OVPN (2 references)
pkts bytes target     prot opt in     out     source               destination
5446 4071K DROP       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0

I have no particular reason to suspect it's related to the problem, but just mentioning to take note of.

I'm still looking for other anomalies, but that's what strikes me immediately.
 
It also seems a bit unusual that there are NO hits on the NAT'ing of the WAN. In all that time since the last failure, not a single client in the 192.168.20.0/24 network (which is bound to the main table and thus the WAN (eth0)) requested internet access?!

The 192.168.20.0/24 network is the guest network. Apparently nobody has used it in the last 7 days. The clients were all connected to 192.168.100.0/24 and all that traffic goes thru the VPN tunnel.
 
There has to be some explanation as to why the NAT rule for tun11 just disappeared. But I haven't a clue. It can't be the OpenVPN client itself, since if it did, it would have removed everything else as well, including the ip rules. If you dump the NAT table now, while it's running correctly, you should see the tun11 NAT rule to which I'm referring.
 
If you dump the NAT table now, while it's running correctly, you should see the tun11 NAT rule to which I'm referring.

Code:
# iptables -t nat -vnL
Chain PREROUTING (policy ACCEPT 5525 packets, 596K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNSVPN1    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
  721 45344 DNSVPN1    udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
 4726  240K GAME_VSERVER  all  --  *      *       0.0.0.0/0            75.11.56.83
 4726  240K VSERVER    all  --  *      *       0.0.0.0/0            75.11.56.83

Chain INPUT (policy ACCEPT 1824 packets, 265K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 2174 packets, 174K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 2073 packets, 147K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1483  103K MASQUERADE  all  --  *      tun11   0.0.0.0/0            0.0.0.0/0
 4103  254K PUPNP      all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
  183 11196 MASQUERADE  all  --  *      eth0   !75.11.56.83          0.0.0.0/0
  324  106K MASQUERADE  all  --  *      br0     192.168.100.0/24      192.168.100.0/24

Chain DNSFILTER (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain DNSVPN1 (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RETURN     all  --  *      *       192.168.20.0/24      0.0.0.0/0
  720 45286 DNAT       all  --  *      *       192.168.100.0/24      0.0.0.0/0            to:10.72.0.1
    0     0 DNAT       all  --  *      *       192.168.1.0/24       0.0.0.0/0            to:10.72.0.1

Chain GAME_VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain LOCALSRV (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PCREDIRECT (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PUPNP (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination
 4726  240K VUPNP      all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain VUPNP (1 references)
 pkts bytes target     prot opt in     out     source               destination
 

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!
Top