forget its a tunnel - just think of it as network connection between 2 routers or 2 endpoints that act as routers.
You have to have the routing on both sides so devices can talk to each other.
If 192.168.1.100 sends traffic to 192.168.1.1 (eth1 on your vpn endpoint) for 18.104.22.168 where in the routing table that you listed does that box know to send the traffic down the tunnel? Is that traffic natted or will its source be 192.168.1.100? When it gets to the vpn server (other end of the tunnel) Does that box have routes to send out its internet gateway. Does it nat it? When the answer comes back, does that end point know to send it back down the tunnel - what is the source IP going to be when it comes back. What is the network on the remote side - if 192.168.1.0/24 or overlap you can have problems.
At min your going to have to have 1 nat somewhere, could be double - you could even have a triple nat scenario in your setup depending.
Where did you come up with 192.168.1.0/24 - does the remote side, your vpn server know about this network?
Is the vpn server your connecting to an actual cisco vpn concentrator at the edge of that network, or something inside that network going through a nat at their edge? If your tunnel is up, lets forget all the protocols and details of how the tunnel works and just think of it as a simple network segment (transient network) to get to the internet.
You end up with this something like this
So both of the routers in this picture need to know where to route the traffic, and where does the nat(s) take place since your dest in public internet and your IP is private.