This setup was given by Dominique Blas.

Bridge/router configuration

              br0 (192.168.100.254)
           +-------------------------+
           !                         !          192.168.100.253 +------------+
-- eth0 ---+                         +- eth1 ---------/---------+   Router   +---> Internet
  agency   !                         !            Cross         +------------+
   LAN     +-----------+-------------+            Cable
                       !
                       !    ipsec0
                       /    (192.168.100.254)
                       !
                       v
          Corporate network (192.168.0.0/19)

• eth0 and eth1 without any address.
• br0 is built upon eth0 and eth1.
• STP is off.
• ipsec0 defaults to br0's address.
• Default gateway is, of course, 192.168.100.253.
• When tunnel is established, route towards 192.168.0.0/19 is created by freeswan using interface ipsec0. Classical.

Stations configuration

• Addressing scheme : 192.168.100.0/24.
• Default gateway is 192.168.100.253.

Now the challenge

• Automatically inject packets, for which the destination address is within the corporate network addressing, to ipsec0.
• Keep the other packets going through eth1.
• That is: ping www.yahoo.com (Internet access through eth1) must respond, ping 192.168.0.33 (intranet access going through ipsec0) must answer.

One can ask why being so complicated. It's enough to configure default gateway (or a list a subnet in the routing table) on the stations to point towards the br0 address and the router will do its job routing toward intranet or towards Internet.
Perfectly exact.

Yes but imagine you have several dozens of such local stations without DHCP to manage their network configuration
and you are thousands of miles away. You can simply send the machine, ask someone to plug it in the router and in the hub with the correct cables you've provided.
That's all.

A solution

So

ebtables -t nat -A PREROUTING -i eth0 -p ipv4 --ip-dst 192.168.0.0/19 \
-j dnat --to-dst  $MAC_ADDR_OF_IPSEC0 --dnat-target ACCEPT

actually works and is enough for the challenge.

A notice on $MAC_ADDR_Of_IPSEC0.
Since the rule is set before ipsec is launched the mac address of ipsec0 is not set at this time. This doesn't matter since ipsec0's mac address will be the same as that of the outbound interface that is equal to eth1's mac address.

Hence this rule:

ebtables -t nat -A PREROUTING -i eth0 -p ipv4 --ip-dst 192.168.0.0/19 \
-j dnat --to-dst $MAC_ADDR_OF_ETH1 --dnat-target  ACCEPT

Of course that's only the first step. One can then take into account a few other things:

• protecting eth1 at the ip level (via iptables) or at the mac level (anti spoofing via ebtables or iptables),
• protecting intranet from devices attempting to access the tunnel from eth1,
• be sure such mac address is associated with such ip address without using arp -s, using ebtables,
• etc, etc.