RT-AC86U - Firewall problem WAN

[bhk20]

The asus router (192.168.1.1) is connected via the WAN interface with my other network (FritzBox; 192.168.178.1). The configured VPN tunnel will be established on my ASUS and all devices use the VPN provider for surfing and streaming. Everything is working except the access to my FritzBox network. I have to switch off the ASUS Firewall to have access to my other network (192.168.178.1). That's so annoying and I don't understand why.
It's the WAN interface and the ASUS firewall should not block the WAN port.

Do you have any idea how to prevent the block of my other internal network? Can I add any rule for that?

Thanks!

 

[john9527]

I don't understand why.

That's because it's trying to connect to the FritzBox over the VPN tunnel (it's an external network to the ASUS LAN). Simpliest fix is to enable policy routing and add a rule to direct the Fritz network to WAN.

 

[bhk20]

That's interesting. BUt when i deacitcate the firewall, everthing works even when the VPN tunnel is still active.
Anyway, can you please describe me the steps how to enable policiy routing to the other network?
Thank you!

 

[eibgrad]

There's no reason the upstream *private* IP network defined on the WAN of the ASUS (192.168.178.0/24) isn't always accessible, regardless whether the OpenVPN client is or isn't connected. At least NOT in terms of the routing. That IP network is known to the router and therefore does NOT rely on the default gateway of the ASUS. There has to be an issue wrt the firewall to explain it. But this isn't normal. I have a Merlin router in the lab w/ an active OpenVPN client, w/ its WAN connected to the upstream private network, and have no such issues. There has to be some other issue at play here, but I have no idea what it may be. The best we can do at this point is to dump the relevant data structures and see what we find. Once w/ the OpenVPN client disabled, the other w/ the OpenVPN client active (so we can compare).

ifconfig
ip route
ip route show table ovpnc1 # assuming this is OpenVPN client #1, if not, adjust accordingly
ip rule
iptables -vnL
iptables -t nat -vnL

Might be best to post the output on PasteBin.

 

[john9527]

There's no reason the upstream *private* IP network defined on the WAN of the ASUS (192.168.178.0/24) isn't always accessible, regardless whether the OpenVPN client is or isn't connected.

Not true for me.....I always have to define either a VPN WAN rule or set up another interface to reach my modem (192.168.100.1 with router at 192.168.1.1) when the VPN is active.

 

[eibgrad]

Not true for me.....I always have to define either a VPN WAN rule or set up another interface to reach my modem (192.168.100.1 with router at 192.168.1.1) when the VPN is active.

I believe you're describing something different. What you're talking about is the "hidden" IP network of a bridged modem+router (192.168.100.0/24). I'm talking about daisy-chained routers, where the IP network of the upstream router is necessarily defined on the WAN of the downstream router. It has to be. The downstream router's WAN ip is part of that upstream network.

 

[bhk20]

Hi, thanks eibgrad for your comment. I also had the feeling that a WAN port (outgoing) should be able to access, even it is your own home network with the IP range of 192.168.178.0.

Yesterday, I downgraded my AC86-U to firmware 386.2.6 and now it is working again. But with a strange workaround (I did it since years). It's getting crazy now
- Once I restart my ASUS (VPN is still not active) the connection to my FritzBox network (192.168.178.0) is not working.
- Then, I deactivate the Firewall. After that I have access to my FirtzNetwork and I establish some connections to various clients in the network of 192.168.178.0
- Then I activate the Firewall again and the access is still working. Please don't ask me why
- This workaround works until I restart the Asus router again, but as I restart the router rarely, I can live with that.

But after I did the flash to the new firmware RT-AX86U_386.3_2., the "workaround" is not working anymore. After I activate the firewall again, the access to the network is gone. Also a ping from my notebook is not working.

I can only ping my FritzNetwork via the ASUS router ( I guess because of the function: Respond to ping requests over WAN in the Firewall settings)

Thats all soooo crazy

 

[eibgrad]

I can only ping my FritzNetwork via the ASUS router ( I guess because of the function: Respond to ping requests over WAN in the Firewall settings)

That setting has nothing to d/ w the Fritz network. That determines if something on the Fritz network (or internet) has the ability to ping the WAN of the ASUS.

So apparently this failure is only from the perspective of the LAN clients behind the ASUS router, and NOT the ASUS router itself. Another clue.

As I said, your best bet at this point is to provide dumps of when it is and isn't working, and compare them. There has to be some difference to account for it. Given its quirkiness, trying to guess what that is is next to impossible.

 

[bhk20]

Ok, how can I create the dumps you need? Where should I enter the commands to test each combination?

 

[eibgrad]

Open an ssh session on the router and copy/paste the list of commands into the terminal window. Then copy/paste the output to PasteBin.

P.S. Feel free to redact your *public* IP from the dumps. Just do so consistently and make it obvious (e.g., x.x.x.x). May not even be an issue given the ASUS is a secondary router, but just in case.

 

[bhk20]

Ok, I did it two times.
The 1) first is with the workaround when the access is working.
The 2) second is after a restart when the access to the network is not worling.

Unfortunately, the code is to long for posting. I attached both files.

Thanks in advance!

 

[eibgrad]

This is exactly why it's vital to see these dumps, because just a quick look shows the problem. And some of the other details NOT mentioned in previous posts.

What I'm seeing is that the firewall rules in each instance are vastly different. In the case of 192.168.178.0/24 being unreachable, I see the OpenVPN client (tun11) doesn't even have the necessary call to the OVPN chain in either the INPUT or FORWARD chains (that's *always* supposed to be present). There's also missing DROP rules at the end of the INPUT and FORWARD chains. Plus, I see a specific rule denying access from br0 to vlan1. But I'm not sure at this point if vlan1 is supposed to be the WAN. On top of all that, I can see you've implemented port forwarding over the VPN.

What I suspect is happening is that you've made the mistake (or something else you're depending on for it) of including your FORWARDing rules for this port forwarding over the VPN in the nat-start script, rather than its own firewall-start script. That is likely to lead to corruption of the firewall, as described in the following link.

T-mobile gateway, ASUS Merlin, trust.zone, OpenVPN, - need to get RDP forwarded!

I am switching to T-Mobile home internet, and have run into a snag. I previously had used port forwarding on the router to publish RDP onto the internet on a non-standard port (let’s call it 1234). So, if you hit , a port forwarding rule would route that to 192.168.1.2:3389. Worked great...

www.snbforums.com

And as I said in that link, you don't even need the FORWARD rules anyway, since there's already a rule in the FORWARD chain that allows DNAT'd connections to be forwarded.

That would explain why it's so quirky. The corruption is intermittent. It may occur sometimes and NOT other times. It's just a matter of the timing by the router of when it configures the NAT and FILTER tables, and any calls to the nat-start and firewall-start scripts.

So that's the first thing I would correct. There may be other issues as well, particularly when using any of these AddOn scripts. Sometimes they can create conflicts of their own, since they are developed and managed independently of the firmware.

 

[bhk20]

Wow, thanks so much for so a fast issue finding!!

Honestly, I am a bit overstrained how to solve the problem, even with your link.

I am using nat-stat for my portforwading ports via VPN. Thats correct and I still need it . How can I prevent the conflict?

One more info: With the old firmware (after the downgrade) its most of the time working when i stop VPN, then deactivate and activate the firewall and after that start the VPN again. In this case, the access to 192.168.178.0 is working.

Thank you!

 

[eibgrad]

I am using nat-stat for my portforwading ports via VPN. Thats correct and I still need it . How can I prevent the conflict?

What is nat-stat?? Please provide some references.

One more info: With the old firmware (after the downgrade) its most of the time working when i stop VPN, then deactivate and activate the firewall and after that start the VPN again. In this case, the access to 192.168.178.0 is working.

It may in fact be working from time to time, since it's a timing issue (if my theory is correct). But its clearly corrupting the firewall from time to time, and so there's no way the current configuration can be allowed to stand.

 

[bhk20]

With the jffs/script/nat-stat I make the port forwarding via vpn into my asus network.

Here the content of nat-stat

#!/bin/sh

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport xxxxx -j DNAT --to-destin                                                                                                             >
iptables -t nat -I PREROUTING -i tun11 -p udp --dport xxxxx -j DNAT --to-destin                                                                                                             >

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport xxxx -j DNAT --to-destina                                                                                                             >
iptables -t nat -I PREROUTING -i tun11 -p udp --dport xxxx -j DNAT --to-destina                                                                                                             >

 

[eibgrad]

Oh, you meant nat-start.

As I said, you don't need any of the FORWARD rules. And you don't need that INPUT rule either since the "Inbound Firewall" setting, when set to Block (the default), prevents connections from being initiated inbound over the tunnel to either the router itself, or forwarded to the LAN, unless you create the necessary DNAT rules (which you've already done). You don't need to NAT the tunnel either since that's any option already available on the OpenVPN client GUI.

Basically, all you need are the DNAT rules. All the rest of it is completely unnecessary.

 

[octopus]

With the jffs/script/nat-stat I make the port forwarding via vpn into my asus network.

Here the content of nat-stat

#!/bin/sh

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport xxxxx -j DNAT --to-destin                                                                                                             >
iptables -t nat -I PREROUTING -i tun11 -p udp --dport xxxxx -j DNAT --to-destin                                                                                                             >

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport xxxx -j DNAT --to-destina                                                                                                             >
iptables -t nat -I PREROUTING -i tun11 -p udp --dport xxxx -j DNAT --to-destina                                                                                                             >

and your DNAT rules isn't complete

 

[bhk20]

and your DNAT rules isn't complete

It is completed. Sorry, the copy paste didn't copy all. After --to destination, the IP is entered

 

[bhk20]

Oh, you meant nat-start.

As I said, you don't need any of the FORWARD rules. And you don't need that INPUT rule either since the "Inbound Firewall" setting, when set to Block (the default), prevents connections from being initiated inbound over the tunnel to either the router itself, or forwarded to the LAN, unless you create the necessary DNAT rules (which you've already done). You don't need to NAT the tunnel either since that's any option already available on the OpenVPN client GUI.

Basically, all you need are the DNAT rules. All the rest of it is completely unnecessary.

That's great! It works after a restart and I have access to the FritzNetwork. I deleted the first 4 rules. The workaround for many years are over!

-iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE
This rule was still necessary. Without that, the tunnel was established butthe internet on my clients were offline.

If you don't mind eibgrad, can ypu explain it to me, what the rules are actually doing. Just to understand what's going on here.

#!/bin/sh

iptables -I FORWARD -i br0 -o tun11 -j ACCEPT
iptables -I FORWARD -i tun11 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o vlan1 -j DROP
iptables -I INPUT -i tun11 -j REJECT
iptables -t nat -A POSTROUTING -o tun11 -j MASQUERADE

iptables -I FORWARD -i tun11 -p udp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -I FORWARD -i tun11 -p tcp -d 192.168.1.xx --dport xxxx -j ACCEPT
iptables -t nat -I PREROUTING -i tun11 -p tcp --dport xxxxx -j DNAT --to-destination xxx                                                                                                            >
iptables -t nat -I PREROUTING -i tun11 -p udp --dport xxxxx -j DNAT --to-destination xxx                                                                                                         >

What are the first 5 rules doing? And why I don't need the first 4 rules for port forwarding via VPN?

Whats the function of FORWARD rule?
- iptables -I FORWARD -i tun11 -p udp -d 192.168.1.xx --dport xxxx -j ACCEPT

Whats the function of prerouting rule and why I should not combine both (Forward & Prerouting) together?
- iptables -t nat -I PREROUTING -i tun11 -p udp --dport xxxxx -j DNAT --to-destination xxx


Thanks!

 

[eibgrad]

You're not listening to me. The ***ONLY*** rules you need are the DNAT rules. Get rid of all the other rules! If you insist on using the FORWARD rules associated w/ the DNAT rules (and that does NOT include the first five rules, those are pointless), then they *must* be placed in the firewall-start script. But again, that isn't necessary since the FORWARD chain already allows connections that enter the router via a DNAT to be forwarded.