you'd need definite answers to the following questions before you can proceed:
can you ping the router from the linux box?
if you can, can you traceroute from the linux box to the router?
from the above questions, I want to make sure that
a. your traffic goes to the windows box indeed and then the router, not directly to the router. the tracert will tell you that for sure.
b. your internal routing infrastructure is working right.
what is the other company's IPsec device's IP address? IPsec tunnels are quite static and you cannot configure them using DNS names or so, so you must know the address of the IPsec remote end point.
does the other endpoint support IPsec Nat-Traverse (NAT-T) ? if they cannot tell you this for sure, ask them the make and model of that endpoint device and if possible , the software/firmware version of that and search for such info.
from what you're telling us above, it seems that first you have to get your internal routing right, as the router will send the traffic directly to the Linux and gets it from it as well, without even letting the windows into the game;unless you either manually mess with routing tables on all 3 boxes, ALL 3(well, maybe not the windows if you've setup RRAS on it but Even that needs checking), or use different subnets for different seagments; for example 192.168.0.1 for router, 192.168.0.2 for windows,another IP like 192.168.1.1 for windows and 192.168.1.3 for linux. By the way if you go with this second approach, make sure that the router knows about the second subnet as well by putting a route to the 192.168.1.x network via the 192.168.0.2 (the windows IP in the same range as the router's IP).
after you got all the c..p above right, now you can start working with the real thing! this is what happens:
we name the IP on the linux LinIP
we name the IP of the windows on the Linux Seagment WinIPL
we name the IP of the windows on the router seagment WinIPR (in case you've chosen manual routing table manipulation approach above, the two WinIPs will be the same)
we name the IP of the router on your internal side RoutIPint
we name the IP of your router on the public facing side (the IP that ISP gives you) RoutIPext.
we name the remote IPsec end point IP, RemTunIP.
we name the IP of the resource you're trying to reach at the other company behind the Tunnel RemResIP.
when your linux generates a packet , it puts LinIP as the source, and RemResIP as the dest; gives that to the Windows Box through the IP WinIPL.
Windows Box, if setup right, will put that packet (including the IP header mentioned above) into another packet, puts WinIPR as the source, RemTunIP as the dest, DIGITALLY SIGNS WinIPR and RemTunIP and gives it to the router
the router NATs that signed packet's to RoutIPext and RemTunIP. here is one of the many places where this chain can get messed up as the SIGNATURE is here violated and the packet gets invalidated UNLESS your windows box and the other Company's IPsec end point are NAT-aware; aka have NAT-T enabled on them. use this kb article from microsoft to enable Nat-T on your windows box(it might seem that it is for VPN at the first sight, but it is a general IPsec settings so DOES do the job):
if your remote company's IPsec device is behind the NAT as well, put 2; if not or if the other company does not support Nat-T(which implies that they're not NATting their IPsec traffic indeed),put 1.
when the remote edge Ipsec device got your packet (FINALLY!), it would be in the form of RoutIPext and RemTunIP . using Nat-T it will extract the packet with WinIPR and RemTunIP, using IPsec Decryption it will extract the packet with LinIP and RemResIP, routes it accordingly and hands it over to the resource your linux was trying to reach.
so you need to have:
a. remote office made aware of your local linux subnet
b. set the policy of IPsec on your windows to form the tunnel with WinIPR and RemTunIP not anything else.
c. have the matching policy of RemTunIP and WinIPR setup at the remote site.
d. have the passthrough enabled on your router.
e. have passed the pre-reqs as I told before the IPsec part above(tracert and subnetting and stuff)
!!!SO IT IS NOT TRIVIAL AT ALL!!!