LinuxQuestions.org - ip packets are not forwarded from tun0 to interface eth0

I have a customized TLS-like server running on the Linux server(Ubuntu 12.04.5). The TLS server creates a tun0 interface when it runs.
There is also a VPN server running on the server.
This Linux server has two physical interfaces, eth0 and eth1. eth1 connects to pulic network. eth0 connects to the private network.
See the list below(ip address is modified for explanation purpose)

client(VPN and TLS): private ip is : 172.10.40.4
server: eth1(10.337.405.344)
eth0(172.10.1.71)
tun0(no ip address)
node in private network: 172.10.1.2

ifconfig shows tun0 interface on the server as below.
tun0
Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1
RX packets:961 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:79648 (79.6 KB) TX bytes:0 (0.0 B)

A vpn connection is established between client and server.
Traffic arriving at eth1 interface are encrypted with ipsec.
After ipsec descrption, the ip packet A (dest port is tls server listening port) is sent to tls server.
Tls server will extract the payload data ( which is an ip packet B) in the ip packet A and write it to tun0 interface.
It is expected that ip packet B is forwarded to eth0. (This is an experiment use case).
I see tun0 has sent out the ip packet B, but the eth0 interface does not receive the packet.

I used the commands below to change ip forwarding table to route all the traffic received from tun0 to eth0.
$sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
$sudo iptables -I FORWARD 1 --in-interface tun0 -o eth0 -j ACCEPT
$sudo iptables -I FORWARD 2 --in-interface eth0 -o tun0 -j ACCEPT

$ sudo iptables -L -n -v
Chain INPUT (policy ACCEPT 288 packets, 34092 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- eth0 tun0 0.0.0.0/0 0.0.0.0/0
2 144 ACCEPT all -- eth1 * 172.10.40.4 0.0.0.0/0 policy match dir in pol ipsec reqid 403 proto 50
1 132 ACCEPT all -- * eth1 0.0.0.0/0 172.10.40.4 policy match dir out pol ipsec reqid 403 proto 50
0 0 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 228 packets, 255K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- *

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.337.405.454 0.0.0.0 UG 100 0 0 eth1
10.337.404.0 0.0.0.0 255.255.254.0 U 0 0 0 eth1
172.10.0.0 0.0.0.0 255.255.128.0 U 0 0 0 eth0
172.10.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

I sends ping traffic (destination 172.10.1.2) from client side, Tls server receives the ping data and writes to tun0 interface.
But eth0 does not receive the traffic. I did not see dropped packet number increases in tun0 interface or eth0 interface.

$ sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
16:50:41.293522 IP 172.10.40.4 > 172.10.1.2: ICMP echo request, id 4, seq 118, length 64
16:50:42.273676 IP 172.10.40.4 > 172.10.1.2: ICMP echo request, id 4, seq 119, length 64
16:50:43.273741 IP 172.10.40.4 > 172.10.1.2: ICMP echo request, id 4, seq 120, length 64
16:50:44.275108 IP 172.10.40.4 > 172.10.1.2: ICMP echo request, id 4, seq 121, length 64
16:50:45.277230 IP 172.10.40.4 > 172.10.1.2: ICMP echo request, id 4, seq 122, length 64

I also notice that the forward entry order is changed after a while when issuing $sudo iptables -L -n -v shows
The vpn related entries beome the first two entries again.
2 144 ACCEPT all -- eth1 * 172.10.40.4 0.0.0.0/0 policy match dir in pol ipsec reqid 403 proto 50
1 132 ACCEPT all -- * eth1 0.0.0.0/0 172.10.40.4 policy match dir out pol ipsec reqid 403 proto 50

Any suggestion is appreciated.