[Beta 382] Asuswrt-Merlin 382.2 Beta is now available

[OsoTheBear]

Yes, reset. Plus: configure again from the beginning, don’t restore your configuration from a saved file.

Gotcha. From what I read, it's recommended to take screenshots of the configuration settings. Sure beats writing them down.

Sent from my Nexus 5X using Tapatalk

 

[m33ts4k0z]

Okey I can't se any problem with those.
Only thing I can think of is the order in chain after Merlin have reorganize chain(s) for VPN
Here is new openvpn-event script.
https://www.snbforums.com/threads/s...pn-port-5060-blocked.41585/page-2#post-352772

This issue has nothing to do with scripts. I run no scripts and I still have that problem. Its purely an iptables/config. I'm having working ovpn configs both for server and for clients but I cant find a way to use them since the server always reloads its own config even when I'm using service stop_vpnserver1 and service start_vpnserver1.

Atm, my bet is with the iptables rules. There are just many rules already setup on the router and I'm not that sure which is causing our trouble.

 

[skeal]

Strange issue here. I can configure and use ovpn client 1 and use it. When I try to use client 2 with saved settings from before the Beta install, it does not fully connect. I get a public description next to on off switch. When I check the ovpn server I'm connecting to it shows me connected fully. The connection does not work. When I try to shut off client 2 it hangs my system for about 10 minutes. Then I'm ok again. I have a ac3100. Am382.2 Beta.

It turns out that the client 2 on my ac3100 is unable to connect to a ovpn server on a ac68u. I can however connect using the android ovpn app to the ac68u. I can import the server ovpn file to my phone and it works excellent. Same config on the router in client 2 or in client 3 it screws my whole router up if I connect. Sometimes I have to manual reboot. The weird thing is as the connection is being tried it kills the internet sometimes sometimes not. It always kills access to my router gui. My server on the ac3100 works great. Server on the ac68u works great. cannot connect router to router over ovpn.

 

[Bob.Dig]

The webui checks the timezone against what is used by your browser. Make sure they match.

The DST time zone changes are set default totally wrong.

 

[king006]

This issue has nothing to do with scripts. I run no scripts and I still have that problem. Its purely an iptables/config. I'm having working ovpn configs both for server and for clients but I cant find a way to use them since the server always reloads its own config even when I'm using service stop_vpnserver1 and service start_vpnserver1.

Atm, my bet is with the iptables rules. There are just many rules already setup on the router and I'm not that sure which is causing our trouble.

I think so! iptables -L -n says:

As sample, <LOCAL IP>/24 = 192.168.1.0/24.

Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 0.0.0.0/0 <LOCAL IP>/24
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1866
DROP all -- 0.0.0.0/0 <LOCAL IP>/24
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
logdrop all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
PTCSRVWAN all -- 0.0.0.0/0 0.0.0.0/0
PTCSRVLAN all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW
OVPN all -- 0.0.0.0/0 0.0.0.0/0 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
logdrop all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP)
target prot opt source destination
DROP all -- 0.0.0.0/0 <LOCAL IP>/24
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 0.0.0.0/0 <LOCAL IP>/24
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
logdrop all -- 0.0.0.0/0 0.0.0.0/0
logdrop all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
SECURITY all -- 0.0.0.0/0 0.0.0.0/0
NSFW all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate DNAT
OVPN all -- 0.0.0.0/0 0.0.0.0/0 state NEW
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain ACCESS_RESTRICTION (0 references)
target prot opt source destination

Chain FUPNP (0 references)
target prot opt source destination

Chain INPUT_ICMP (0 references)
target prot opt source destination

Chain NSFW (1 references)
target prot opt source destination

Chain OVPN (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain PControls (0 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain PTCSRVLAN (1 references)
target prot opt source destination

Chain PTCSRVWAN (1 references)
target prot opt source destination

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

Chain default_block (0 references)
target prot opt source destination

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

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

 

[StefanoN]

Hi
I have 2 scripts, one is for the overclock, the second is to block two lan ip
towards internet.
I tried after disabling the scripts, but the problem remains.

 

[DonnyJohnny]

OpenVPN working fine for me, also on 68U and the 382 beta.

Hi, are u able to paste your iptables rule here.
iptables -S
I just want to see the order... thanks.
Anyone with a working openvpn in 382.2.beta... can paste the iptables for reference. Thx.

This is my iptables... can someone see mine...

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N ACCESS_RESTRICTION
-N FUPNP
-N INPUT_ICMP
-N NSFW
-N OVPN
-N PControls
-N PTCSRVLAN
-N PTCSRVWAN
-N SECURITY
-N default_block
-N logaccept
-N logdrop
-A INPUT -p udp -m udp --dport 1195 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD ! -i br0 -o eth0 -j logdrop
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -j NSFW
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT-A FORWARD -m state --state NEW -j OVPN-A FORWARD -i br0 -j ACCEPT
-A NSFW -i br0 -o eth0 -p ipv6-auth -j DROP
-A NSFW -i br0 -o eth0 -p ipv6-crypt -j DROP
-A NSFW -i br0 -o eth0 -p udp -m udp --dport 4500 -j DROP
-A NSFW -i br0 -o eth0 -p udp -m udp --dport 500 -j DROP
-A NSFW -i br0 -o eth0 -p udp -m udp --dport 1701 -j DROP
-A NSFW -i br0 -o eth0 -p gre -j DROP
-A NSFW -i br0 -o eth0 -p tcp -m tcp --dport 1723 -j DROP
-A OVPN -i tun22 -j ACCEPT
-A PControls -j ACCEPT
-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 logdrop
-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 logdrop
-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 logdrop-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 -i eth0 -m set --match-set Whitelist src -j ACCEPT
-A logdrop -i eth0 -p tcp -m multiport --sports 80,443,143,993,110,995,25,465 -m state --state INVALID -j DROP
-A logdrop -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A logdrop -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A logdrop -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,ACK -j ACCEPT
-A logdrop -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,ACK -j ACCEPT
-A logdrop -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG RST -j ACCEPT
-A logdrop -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG RST,ACK -j -A logdrop -i eth0 -m state --state INVALID -j LOG --log-prefix "[BLOCKED - NEW BAN] " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -i eth0 -m state --state INVALID -j SET --add-set Skynet src
-A logdrop -j DROP

Below is my Iptables NAT

-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-N DNSFILTER
-N LOCALSRV
-N PCREDIRECT
-N PUPNP
-N VSERVER
-N VUPNP
-A PREROUTING -p udp -m udp --dport 1195 -j ACCEPT
-A PREROUTING -d myWANip/32 -j VSERVER
-A POSTROUTING -o eth0 -j PUPNP
-A POSTROUTING ! -s myWANIP/32 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.0/24 -o br0 -j MASQUERADE
-A VSERVER -j VUPNP

 

[RMerlin]

The Alpha firmware didn’t have this problem.

Where is the difference?

OpenVPN firewall setup was recently overhauled to resolve various issues with it

 

[skeal]

It turns out that the client 2 on my ac3100 is unable to connect to a ovpn server on a ac68u. I can however connect using the android ovpn app to the ac68u. I can import the server ovpn file to my phone and it works excellent. Same config on the router in client 2 or in client 3 it screws my whole router up if I connect. Sometimes I have to manual reboot. The weird thing is as the connection is being tried it kills the internet sometimes sometimes not. It always kills access to my router gui. My server on the ac3100 works great. Server on the ac68u works great. cannot connect router to router over ovpn.

Further troubleshooting reveals that once OVPN client 1 is setup you cannot setup any other clients with any settings to any server.

 

[king006]

OpenVPN firewall setup was recently overhauled to resolve various issues with it

But apparently a new problem has now been made!
Do you have a possible idea? can you debug it in your test lab?

 

[skeal]

OVPN is messed up man!

 

[Deleted member 22229]

Wow reading through this thread looks like Beta 1 turned out to be a new years mess.

 

[DonnyJohnny]

The solution is factory reset and key in manually... but I refused to give in like that... lol... someone help me with the iptables above.. lol

 

[RMerlin]

Relax, and breathe people... This is just OpenVPN-specific, no need to start panicking as if the sky was falling.

The issue is caused by the following rule in the FORWARD chain which is blocking traffic before it can get accepted by the OVPN chain:

20  7730 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0

 

[RussellInCincinnati]

The solution is factory reset and key in manually... but I refused to give in like that... lol... someone help me with the iptables above.. lol

My 382.2beta install went perfectly on RT-AC68u. (1) Write down config info (2) install software (3) reset to factory defaults (4) reconfigure manually.

Also confirmed that under Samba sharing, the SMB version 1.0 works faster and more consistently than SMB version 2.0, as Merlin has suggested repeatedly. My Arch Linux "mount" command includes an option ",vers=1.0" (one point zero) and works fine.

Also nice to see more of the heretofore-unused RAM being used now to run the router.

 

[skeal]

Relax, and breathe people... This is just OpenVPN-specific, no need to start panicking as if the sky was falling.

The issue is caused by the following rule in the FORWARD chain which is blocking traffic before it can get accepted by the OVPN chain:

20  7730 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0

Thank you sir I thought I was going crazy!

 

[skeal]

The solution is factory reset and key in manually... but I refused to give in like that... lol... someone help me with the iptables above.. lol

I have factory reset....I have recovery reset.....still have the same problem. Factory reset is not the answer.

 

[DonnyJohnny]

I have factory reset....I have recovery reset.....still have the same problem. Factory reset is not the answer.

Lol...

Relax, and breathe people... This is just OpenVPN-specific, no need to start panicking as if the sky was falling.

The issue is caused by the following rule in the FORWARD chain which is blocking traffic before it can get accepted by the OVPN chain:

20  7730 DROP       all  --  !br0   eth0    0.0.0.0/0            0.0.0.0/0

Nice to see some light for some quick fix soon... give it to me baby...
By the way, Happy New Year to all of you...!!

 

[skeal]

Yeah all you guys from around the world "Happy New Year" to all!!

 

[Deleted member 22229]

Happy New Year to all !!!