Thanks a lot for your help, Todd.
On Wed, 2008-12-17 at 13:01 -0600, Todd T. Fries wrote:
> | 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..
Yep, University gave us five ipv6 ranges without being able to route
them (yet).
> | 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.
Oh, yes. This is wrong indeed. I wonder why pfctl hasn't bailed out.
However, using "-> ::1" should then do the trick as well, right?
Unfortunately, I still see the same effect, here are the packets on
doing an 'ssh my.external.ipv4.host' from my ipv6-client:
gw# tcpdump -evni pflog0 -s 512 ip6
10:44:55.701935 rule 32/(match) [uid 0, pid 28859] pass in on em0:
2001:620:10:1401:20d:60ff:fe2e:251b.27021 > 2001:620:10:1401::eeee.53:
42719+ AAAA? merry.ini.uzh.ch. (34) [flowlabel 0xbc4e3] (len 42, hlim
64)
10:44:55.710561 rule 32/(match) [uid 0, pid 28859] pass in on em0:
2001:620:10:1401:20d:60ff:fe2e:251b.21304 > 2001:620:10:1401::eeee.53:
61177+ A? merry.ini.uzh.ch. (34) [flowlabel 0xdcf20] (len 42, hlim 64)
10:44:55.717571 rule 11/(match) [uid 0, pid 28859] rdr in on em0:
2001:620:10:1401:20d:60ff:fe2e:251b.37356 > ::1.8081: S
3170155212:3170155212(0) win 16384 <mss 1440,nop,nop,sackOK,nop,wscale
0,nop,nop,timestamp 1991902115 0> [flowlabel 0xc4399] (len 44, hlim 64)
So, the traffic *is* redirected to ::1.8081 but the client connection
times out after a while and the relayd log doesn't show anything.
However, if I test with 'telnet ::1 8081', I do see a connection attempt
in relayd's log file.
> | ---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.
I will take care of http as soon as the basic setup works.
> | 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.
Unfortunately, it doesn't. The packets aren't blocked by pf but are
properly redirected to relayd. Relayd stays quiet.
On a side note: I also don't understand why the wrong default gateway is
advertised to my client. Instead of my global IPv6 address, the
local-link address is propagated. I was under the impression rtadvd will
take care of it:
gw$ cat /etc/rtadvd.conf
em0:\
:addr="2001:620:10:1401::":prefixlen#64:raflags#0:
client$ sudo route -n show -inet6 | grep default
default fe80::20c:f1ff:fe8f:a9c4%em0 UG 0 43 - em0
client$ cat /etc/mygate
2001:620:10:1401::eeee
> 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!
Well, at least my pf.conf is fixed now! Thanks again. But I still
struggle with relayd. I'll try to setup this case at home on my much
simpler environment over christmess. Maybe that'll work.
Cheers,
--
Stephan A. Rickauer
-----------------------------------------------------------
Institute of Neuroinformatics Tel +41 44 635 30 50
University / ETH Zurich Sec +41 44 635 30 52
Winterthurerstrasse 190 Fax +41 44 635 30 53
CH-8057 Zurich Web www.ini.uzh.ch
