Penned by Stephan A. Rickauer on 20081216 16:14.32, we have:
| I started playing with ipv6. It feels like back in the early 90's, when
| I had to learn how 'the Internet' works ;)
Yes, I recall sitting in a basement with friends around that time, deciding
with enough parts and computers we would learn how to setup an IPv4 network..
Lots of trials and errors later...
| Here's the setup:
|
| An ipv6 only host with a non-link-local address should be able to use
| the ipv4 world. I don't want to deal with a tunnel broker, nor do I have
| native ipv6 access to the internet.
Your assumption is invalid. If you have a non link local address you have,
by definition, a global IPv6 address, in which case someone (a tunnel broker
or a native provider) has allocated you an IPv6 address. If you can get to
anywhere in the IPv6 world, you can use places like:
http://<domain>.sixxs.org/
to visit IPv4 hosts via a free IPv6 `proxy' setup by sixxs.net. Note it
doesn't just spit out pages verbatim, but tries to tweak them to refer back
to the proxy; most of the time it succeeds.
| The ipv6 only client gets its ipv6 address via the rtadvd running on the
| gatway's internal interface. The gateway's external interface is ipv4
| only.
So however you've managed it you have an IPv6 subnet internally. But it is
not routed to the world? Shame. Go get a tunnel broker and fix this! You
really are missing out..
| The ipv6 host can already ping6 the gatway. DNS I have 'fixed' with
| totd, so ipv4 addressed are mapped into the ipv6 space:
|
| ipv6-client:~$ host www.google.ch
| www.l.google.com has address 74.125.39.147
| www.l.google.com has IPv6 address 2001:620:10:1401::4a7d:2767
|
|
| The default ipv6-gateway of my ipv6 client is properly set
| in /etc/mygate.
|
| I try to use pf on the gateway to intercept tcp/ip6 traffic and to feed
| it into relayd. The relevant parts are as follows:
|
| ---pf.conf--
| rdr pass inet6 proto tcp from lan:network -> :: port 8081
| ---pf.conf--
Wrong. Try this instead:
rdr pass inet6 proto tcp from lan:network -> lan port 8081
You cannot redirect to `::', a wildcard address. You must redirect to
a specific address.
| ---relayd.conf---
| tcp protocol tcpgeneric {
| tcp { backlog 128, nodelay, sack, socket buffer 131072 }
| }
|
| relay tcp6to4 {
| listen on :: port 8081
| forward to nat lookup inet
| protocol tcpgeneric
| }
| ---relayd.conf---
This relayd.conf looks like what I've done. here is my setup on the gateway
with a couple little twists (I'm using abcd::/48 as an example allocation):
-- pf.conf --
table <6to4ok> { abcd::/48 } # who is permitted to use this relay?
table <6to4net> { abcd:0:0:ffff::/96 } # the 6to4 prefix
rdr pass inet6 proto tcp from <6to4ok> to <6to4net> port { 80 8080 } ->
abcd::1 port 8080
rdr pass inet6 proto tcp from <6to4ok> to <6to4net> -> abcd::1 port 8081
-- pf.conf --
-- relayd.conf --
tcp protocol tcpgeneric {
tcp { backlog 128, nodelay, sack, socket buffer 131072 }
}
http protocol httpgeneric {
header append "$REMOTE_ADDR" to "X-Forwarded-For"
header append "$SERVER_ADDR:$SERVER_PORT" to \
"X-Forwarded-By"
header change "Connection" to "close"
tcp { backlog 128, nodelay, sack, socket buffer 131072 }
}
relay tcp6to4 {
listen on :: port 8081
forward to nat lookup inet
protocol tcpgeneric
}
relay http6to4 {
listen on :: port 8080
forward to nat lookup inet
protocol httpgeneric
}
-- relayd.conf --
.. this way http traffic gets some info injected about being forwarded.
| After that kinda long intro, here's the problem:
|
| Though name resolution works, an actual connection to an ipv6 address on
| port 80 wouldn't work and isn't 'seen' by relayd either. If I tcpdump on
| the gateway I see that the client, after it got the faked ipv6 address,
| sends an "icmp6: neighbor sol: who has 2001:620:10:1401::4a7d:2767".
|
| So, it believes google is part of 'our' name space, which is probably
| wrong. I then tried to change the prefix of totd to a non-local prefix,
| like 2001:620:10:1400:: (instead of :1401::) so that a 'host
| www.google.ch' results in 2001:620:10:1400::4a7d:2767 and thus can't be
| treated as 'local'.
|
| When I do this I can see the traffic on the gatway:
| 2001:620:10:1401:20d:60ff:fe2e:251b.13239 >
| 2001:620:10:1400::4a7d:2768.80
|
| but it's still not seen by relayd.
|
| Can someone with some degree of patience shed some light on my dark
| spots?
I think the pf.conf tweak may be all thats necessary for you to see traffic
via relayd.
However, I'll go a step further and document what I was able to accomplish
without totd.
Without totd, just using pf.conf on the client and relayd on the client in
addition to the above that I've already documented on the gateway, I was
able to use IPv4 by sending only native IPv6 packets from the client to
the gateway.
On the client, I did the following in pf.conf:
#set skip on lo # Important that this is commented!
scrub in
no rdr inet proto tcp from 127.0.0.1
no rdr inet proto tcp to 127.0.0.1
rdr inet proto tcp tag tcp4to6 -> 127.0.0.1 port 8081
pass out route-to (lo0 127.0.0.1) inet proto tcp tagged tcp4to6
On the client, I did the following in relayd.conf:
relay tcp4to6 {
listen on 127.0.0.1 port 8081
forward to nat lookup inet6 abcd:0:0:ffff::
}
If you have no global or rfc internal IPv4 address on the system, you still
need a `default' IPv4 route. You should be able to do this:
route add default 127.0.0.1
though I did not need to since I had another interface with an IPv4 address I
already had a default route through.
I generally do IPv4 over IPv6 inside of IPSec, for access to home afs and
other reasons. I've added specific bypass rules to bypass that tunnel to
test the relay stuff. For example:
me4="10.0.0.206"
rmt6="abcd::1"
ike dynamic esp from $me4 to any peer $rmt6 \
srcid me.example.com dstid rmt.example.com
flow protocol tcp from 0.0.0.0/0 to 0.0.0.0/0 port 80 type bypass
flow protocol tcp from 0.0.0.0/0 to 0.0.0.0/0 port 22 type bypass
flow from $me4 to $me4 type bypass
As a true tangent but relevent to those roaming around on the ancient IPv4
network wanting to have a fixed IPv6 address .. I submit the following (because
the bypass rules are required and took a bit to realize why.. ndp traffic over
IPSec is not a useful waste of bandwith..):
me6="abcd:42::feed:8ee"
rmt4="1.2.3.4"
ike dynamic esp from $me6 to any peer $rmt4 \
srcid me.example.com dstid rmt.example.com
flow from $me6 to $me6 type bypass
flow from ::/0 to ff02::/16 type bypass
flow out from ff02::/16 to ::/0 type bypass
flow from ::/0 to fe80::/16 type bypass
flow out from fe80::/16 to ::/0 type bypass
For both of the above IPSec examples, $me6 and $me4 are on trunk1 with no
trunkports but the interface is up. For IPv4, 'route add default $me4' works.
For IPv6, 'route add -inet6 default $me6' works. Why? Because traffic without
a destination in the routing table does not make it to the IPSec stack.. so
some route (any route) must be present for traffic to flow.. at which point
IPSec can inspect and do its thing if the situation merits.
Hope this provides some useful pointers!
--
Todd Fries .. [email protected]
_____________________________________________
| \ 1.636.410.0632 (voice)
| Free Daemon Consulting, LLC \ 1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX)
| "..in support of free software solutions." \ 250797 (FWD)
| \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A
http://todd.fries.net/pgp.txt
