Hurricane Electric's IPv6 Tunnel Broker Forums

General IPv6 Topics => IPv6 on Linux & BSD & Mac => Topic started by: doneill on September 15, 2010, 05:33:08 PM

Title: PPTP tunnels on Linux
Post by: doneill on September 15, 2010, 05:33:08 PM
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.