iptables -I PREROUTING --DNAT --to-source rule via openvpn client tunnel locks RT-N10U

[GoogleCodeExporter]

What steps will reproduce the problem?
1. install openvpn.
2. run openvpn in client mode (tun interface). both client and server can ping 
and connect to each other via tun0 tunnel
3. on router execute: iptables -t nat -I PREROUTING -s 172.16.1.1 -p tcp  
--dport 5900 -j DNAT --to-destination 192.168.1.10:5900
-- where 172.16.1.1 - vpn server ip, 192.168.1.10 - PC connected to router's 
LAN port.
4. on vpn server side execute: telnet 172.16.1.1 5900

What is the expected output? What do you see instead?
router shouldn't lock up. it does lock up immediately after issuing telnet 
command from step 3, stops responding to LAN/WAN requests and hangs (to verify 
this I set up continuous logging to usb flash, and logging stops the same 
moment router locks up).

What version of the product are you using?
I've tried several RT-N10U routers with rtn-3702, rtn-4051, rtn-r4177, and 
openvpn 2.2.0, 2.2.1

Please provide any additional information below.
tcpdump -i tun0, last message before lockup:
09:39:14.748912 IP 172.16.1.1.52913 > 172.16.1.254.5900: Flags [S], seq 
2348921998, win 5840, options [mss 1368,sackOK,TS val 1537082042 ecr 
0,nop,wscale 7], length 0

system configuration: http://pastebin.com/raw.php?i=p3TNpdte

in all my test cases radio was turned off programmatically, or even had wl 
module unloaded - doesn't make any difference.

Please help me to pin-down this issue, for the last few days it really is 
driving me crazy. the same configuration works without problems on the same 
router using dd-wrt24vpn-small firmware, but I like oleg's firmware flexibility 
and awesomeness. By the way, I've donated to the project yesterday via yandex 
money, and I'm ready to make another donation, just let me know the quote.

Original issue reported on code.google.com by oblikoamorale@gmail.com on 10 May 2012 at 8:23

[GoogleCodeExporter]

a typo on step 4. should be read as this:

4. on vpn server side execute: telnet 172.16.1.254 5900 (where 172.16.1.254 - 
ip assigned to vpn client)

Original comment by oblikoamorale@gmail.com on 10 May 2012 at 8:31

[GoogleCodeExporter]

I figured that there's no other way to know whats going on other than check the 
serial console, so I've soldered TTL-RS232 converter, and... as expected, it's 
kernel panic:
http://pastebin.com/raw.php?i=GJHj7GGk

rtn-r4177, and openvpn 2.2.1 from default repository.

any thoughts?

Original comment by oblikoamorale@gmail.com on 11 May 2012 at 6:14

[GoogleCodeExporter]

full kernel boot log: http://pastebin.com/eayhKJC1

Original comment by oblikoamorale@gmail.com on 11 May 2012 at 6:20

[GoogleCodeExporter]

I'm using rtn-r4177 compiled without wl, ntfs-3g and a couple of other modules.

if it helps the case, I'm ready to reproduce the crash and post results on 
vanilla rt-n4177. just let me know.

Original comment by oblikoamorale@gmail.com on 11 May 2012 at 6:23

[GoogleCodeExporter]

You have to turn off Fast-NAT, as written in 
http://code.google.com/p/wl500g/wiki/News

Original comment by lly.dev on 11 May 2012 at 7:29

• Changed state: Duplicate

[GoogleCodeExporter]

whoa, I'd never have thought about this. turning fastnat does help indeed. 
thank you!

and, just for history & google, whoever might need this in future: ASUS RT-N10U 
serial console pinout: J4 1.VCC 2.GND 3.TX 4.RX.

Original comment by oblikoamorale@gmail.com on 11 May 2012 at 7:46

[GoogleCodeExporter]

could you please reproduce kernel bug with latest rtn firmware?
the paste you have attached shows nothing, mean incomplete stack trace

Original comment by themiron.ru on 9 Jun 2012 at 3:43

[GoogleCodeExporter]

with latest firmware you mean last trunk build? sure, I'll give it a shot next 
week.

unfortunately that paste is everything I managed to retrieve from the device 
via serial console. I am unaware of any other way.

Original comment by oblikoamorale@gmail.com on 9 Jun 2012 at 4:39

[GoogleCodeExporter]

nevermind, test r4320 with fastnat *enabled*.
should be no problem.

Original comment by themiron.ru on 10 Jun 2012 at 10:44

• Changed state: Fixed

[GoogleCodeExporter]

tested 4320, I confirm that kernel panic is gone. thank you!

do you consider 4320 safe enough to use or should I wait for "official" stable 
release?

Original comment by oblikoamorale@gmail.com on 14 Jun 2012 at 12:57

[GoogleCodeExporter]

disregard the question - I missed recently featured 4330 release

Original comment by oblikoamorale@gmail.com on 14 Jun 2012 at 12:59