You can only have one default route on a system.
You can add static routes in to force some traffic to go via a different router:
route add 172.16.1.0/24 172.26.1.250
or
ip route add 172.16.1.0/24 via 172.26.1.250 dev eth0:1
These commands can be added to /etc/network/interfaces.
Where you are going, you don't need iptables.
What I understand you want to do is to have the gateway forward IP packets between two interfaces without the gateway performing any NAT on the forwarded packets. You can do this without any iptables rules.
My knowledge of LTE is lacking. So if there turns out to be any LTE specific caveats, I won't be able to help you with those. My answer will for the most part assume eth0 and eth1 are both running ordinary IPv4 over Ethernet.
First of all you need to ensure forwarding is enabled:
echo 1 >/proc/sys/net/ipv4/ip_forward
Packets arriving from the Internet will arrive on eth1. But the sender of those packets may need to perform ARP requests for 10.20.30.6 which isn't assigned to your gateway. So your gateway will not respond to those ARP requests unless you enable ARP proxying:
echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
Once the ARP reply has been sent, the rest of the processing of incoming packets happens using ordinary IP packet forwarding, no magic needed.
Packets from the PC to the gateway require no tricks to arrive at the gateway through eth0. The tricky part then is how to get them to leave through the eth1 interface.
You need a default route. But the gateway for that route would presumably be 10.20.30.1, which you just assigned to eth0 on the gateway you are setting up. However if you know the MAC address of the original gateway, you can get this to work without needing a real gateway IP address.
First you invent a placeholder gateway IP address (should be an RFC 1918 address, which you don't need to communicate otherwise). For the example I'll assume 10.1.2.3:
ip neigh add 10.1.2.3 lladdr xx:xx:xx:xx:xx:xx dev eth1
ip route add 10.1.2.3 dev eth1
ip route add default via 10.1.2.3
Because 10.1.2.3 is created as a permanent entry in the ARP cache on your gateway, no ARP requests will be sent for this address. That means it will not be a problem that the next gateway is unaware of your chosen placeholder IP address.
Best Answer
It's certainly possible to do this, and it's actually possible to do this with existing kernel modules today:
LAN -> (nic module) -> (dot1q module) -> (bridge module) -> (dot1q module) -> (nic module) -> WAN
Or:
eth0 -> eth0.10 -> br0 -> eth1.20 -> eth1
(takes anything tagged as vlan 10 off eth0, re-tags it as vlan 20 and pushes it out eth1, and visa-versa. Additional access control can be done using ebtables.)
If you don't need to change tags, you can simplify down to:
eth0 -> br0 -> eth1
And apply ebtables to br0.
That said, if your application can do the "eth0.10 -> br0 -> eth1.20" piece internally, though it would not require tap devices to do it, since you can read frames off one interface, filter, and write to the other.