I've been mulling in my head as to why multiple routing tables are necessary for these tunnels. Rather, I can't see why something like this:
ip route add 216.218.226.238 dev ppp0 src 184.x.x.x
ip tun add henet local 184.x.x.x remote 216.218.226.238 dev ppp0 mode sit
simply doesn't work. I tried this, of course it was (and still is) the most logical method in my head.
Unfortunately, tcpdump shows a MASSIVE amount of GREv1 packets feeding back, until eventually the PPP link is terminated or that route is deleted.
Also, the traffic flood doesn't make sense to me either:
12:28:25.049295 IP (tos 0x0, ttl 64, id 6348, offset 0, flags [DF], proto GRE (47), length 32)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, ack present], call 5120, ack 1143, no-payload, length 12
E.. ..@.@/.0..
A.... ..........w
12:28:25.049324 IP (tos 0x0, ttl 64, id 6349, offset 0, flags [DF], proto GRE (47), length 68)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, sequence# present], call 5120, seq 1060215, length 48
IP (tos 0x0, ttl 64, id 6348, offset 0, flags [DF], proto GRE (47), length 32)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, ack present], call 5120, ack 1143, no-payload, length 12
E..D..@.@/....
A....0....$....-w...!E.. ..@.@/.0..
A.... ..........w
12:28:25.049344 IP (tos 0x0, ttl 64, id 6350, offset 0, flags [DF], proto GRE (47), length 104)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, sequence# present], call 5120, seq 1060216, length 84
IP (tos 0x0, ttl 64, id 6349, offset 0, flags [DF], proto GRE (47), length 68)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, sequence# present], call 5120, seq 1060215, length 48
IP (tos 0x0, ttl 64, id 6348, offset 0, flags [DF], proto GRE (47), length 32)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, ack present], call 5120, ack 1143, no-payload, length 12
E..h..@.@/....
A....0....H....-x...!E..D..@.@/....
A....0....$....-w...!E.. ..@.@/.0..
A.... ..........w
12:28:25.049363 IP (tos 0x0, ttl 64, id 6351, offset 0, flags [DF], proto GRE (47), length 140)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, sequence# present], call 5120, seq 1060217, length 120
IP (tos 0x0, ttl 64, id 6350, offset 0, flags [DF], proto GRE (47), length 104)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, sequence# present], call 5120, seq 1060216, length 84
IP (tos 0x0, ttl 64, id 6349, offset 0, flags [DF], proto GRE (47), length 68)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, sequence# present], call 5120, seq 1060215, length 48
IP (tos 0x0, ttl 64, id 6348, offset 0, flags [DF], proto GRE (47), length 32)
192.168.10.65 > 216.218.226.238: GREv1, Flags [key present, ack present], call 5120, ack 1143, no-payload, length 12
E.....@.@/....
A....0....l....-y...!E..h..@.@/....
A....0....H....-x...!E..D..@.@/....
A....0....$....-w...!E.. ..@.@/.0..
... etc, until each packet is beyond pppd's capacity to deal with it.
192.168.10.65 is the address on my "external interface" which plows into the rear end of a DSL modem. I defined "local" in my tunnel creation, even "dev" to say "here, use this."
Do I not understand some fundamental principle of networking, or is something simply broken here?
My primary reason for not wanting to use multiple routing tables is so I can SNAT inbound IPv4 to a PC connected via Docsis a few kilometers away, but keep the IPv6 tunneled traffic on my main network. I haven't found a way to SNAT from one table to another, but I was thinking of maybe something like:
ip rule add not from <tunnel broker ip> table henet lookup main
which would validate my SNAT target.
Still, I come back to the whole "why doesn't this work the -normal- routing way?" question.