nat64

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

nat64

Stéphane Guedon
Hello !

I am trying to setup a nat64 using my openbsd server as router.

This server has one physical network card (re0).
I connect it to native ipv6 world with a sixxs tunnel, and my local
network get ipv6 connectivity. So, no problem connerning that.

I would like to finish the damn thing (like said previously) by
furnishing a nat64 on this system. I tried to find the good pf rule,
but can't understand how to build it.

here is what I would like to write (or close) :

pass in on re0 inet6 from any to 64:ff9b::/96 af-to inet from (re0)

Here is my config (I supress loopback and log interface, but they are
active obviously) :

# ifconfig                                                                                                                                                                                                
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr bc:5f:f4:73:a7:e0
        priority: 0
        groups: egress
        media: Ethernet autoselect (1000baseT full-
duplex,rxpause,txpause)
        status: active
        inet6 fe80::be5f:f4ff:fe73:a7e0%re0 prefixlen 64 scopeid 0x1
        inet6 2001:16d8:dd00:8207::2 prefixlen 64
        inet6 2001:16d8:dd00:8207:be5f:f4ff:fe73:a7e0 prefixlen 64
        inet6 2001:16d8:dd00:8207:be5f:f4ff:fe73:a7e0 prefixlen 64
        inet 192.168.87.2 netmask 0xffffff00 broadcast 192.168.87.255
        inet6 2001:16d8:dd00:8207:8ce:b9a4:3069:1905 prefixlen 64
deprecated autoconf autoconfprivacy pltime 0 vltime 76312
        inet6 2001:16d8:dd00:8207:c425:547e:727:2bed prefixlen 64
deprecated autoconf autoconfprivacy pltime 0 vltime 162543
        inet6 2001:16d8:dd00:8207:7c7a:4871:52ad:fb96 prefixlen 64
deprecated autoconf autoconfprivacy pltime 0 vltime 248751
        inet6 2001:16d8:dd00:8207:49e:db9d:70e1:32a prefixlen 64
deprecated autoconf autoconfprivacy pltime 0 vltime 335038
        inet6 2001:16d8:dd00:8207:4cdc:5c4:8c74:464e prefixlen 64
deprecated autoconf autoconfprivacy pltime 0 vltime 421585
        inet6 2001:16d8:dd00:8207:fc2b:59a0:dbf3:e362 prefixlen 64
deprecated autoconf autoconfprivacy pltime 0 vltime 508014
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        priority: 0
        groups: tun egress
        status: active
        inet6 fe80::be5f:f4ff:fe73:a7e0%tun0 ->  prefixlen 64 scopeid
0x5
        inet6 fe80::14d8:dd00:207:2%tun0 ->  prefixlen 64 scopeid 0x5
        inet6 2001:16d8:dd00:207::2 -> 2001:16d8:dd00:207::1 prefixlen
128

Thanks in advance for your suggestions.

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Stuart Henderson-6
On 2014/03/12 22:03, Stéphane Guedon wrote:

> Hello !
>
> I am trying to setup a nat64 using my openbsd server as router.
>
> This server has one physical network card (re0).
> I connect it to native ipv6 world with a sixxs tunnel, and my local
> network get ipv6 connectivity. So, no problem connerning that.
>
> I would like to finish the damn thing (like said previously) by
> furnishing a nat64 on this system. I tried to find the good pf rule,
> but can't understand how to build it.
>
> here is what I would like to write (or close) :
>
> pass in on re0 inet6 from any to 64:ff9b::/96 af-to inet from (re0)

I have pretty much the same, the only difference is that I use a
fixed address rather than (re0), but I don't *think* that matters here.

Do you have v4 and v6 forwarding sysctl's enabled?

You'll probably want DNS64 to go with that, the one that is part of
newer versions of BIND (in ports) works fine.

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Simon Perreault-3
In reply to this post by Stéphane Guedon
Le 2014-03-12 17:03, Stéphane Guedon a écrit :
>         inet 192.168.87.2 netmask 0xffffff00 broadcast 192.168.87.255

Does that mean that you intend to do double NAT? NAT64 then NAT44?

Simon

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Stéphane Guedon
Le mercredi 12 mars 2014, 17:13:23 Simon Perreault a écrit :
> Le 2014-03-12 17:03, Stéphane Guedon a écrit :
> >         inet 192.168.87.2 netmask 0xffffff00 broadcast
> >         192.168.87.255
>
> Does that mean that you intend to do double NAT? NAT64 then NAT44?

I don't really intend, but have no choice...
I didn't think of that aspect. Is that important ?

>
> Simon

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Stuart Henderson-6
In reply to this post by Stuart Henderson-6
On 2014/03/12 22:15, Stéphane Guedon wrote:

> Le mercredi 12 mars 2014 21:10:01, vous avez écrit :
> > On 2014/03/12 22:03, Stéphane Guedon wrote:
> > > Hello !
> > >
> > > I am trying to setup a nat64 using my openbsd server as router.
> > >
> > > This server has one physical network card (re0).
> > > I connect it to native ipv6 world with a sixxs tunnel, and my
> > > local
> > > network get ipv6 connectivity. So, no problem connerning that.
> > >
> > > I would like to finish the damn thing (like said previously) by
> > > furnishing a nat64 on this system. I tried to find the good pf
> > > rule, but can't understand how to build it.
> > >
> > > here is what I would like to write (or close) :
> > >
> > > pass in on re0 inet6 from any to 64:ff9b::/96 af-to inet from
> > > (re0)
> >
> > I have pretty much the same, the only difference is that I use a
> > fixed address rather than (re0), but I don't *think* that matters
> > here.
> >
> > Do you have v4 and v6 forwarding sysctl's enabled?
>
> v6, sure, cause I need it to use the server as a router on his current
> status (tunnelling to native ipv6 world). For exemple, I reach
> facebook and google on ipv6 now using that way (without thinking of it
> really).
>
> v4... it seems.
>
> here is sysctl result :
>
> # sysctl|grep forw
> net.inet.ip.forwarding=1
> net.inet.ip.mforwarding=0
> net.inet6.ip6.forwarding=1
> net.inet6.ip6.mforwarding=0
>
> >
> > You'll probably want DNS64 to go with that, the one that is part of
> > newer versions of BIND (in ports) works fine.
>
> Yes I know ! It works perfectly fine ! The nat 64 part is the one that
> don't for now.

I suggest general PF rule debugging then, make sure that the
rule is hit (check it with "log" or "match log (matches)" and watch
tcpdump -nettipflog0, etc) and that it isn't hidden by another rule
or "set skip", etc.

$ ftp -V -o- http://[2001:8b0:648e:6464::129.128.5.194]/|grep Exp
$OpenBSD: index.html,v 1.302 2014/02/28 02:20:54 nick Exp $

Note that traceroute6 will look a bit odd:

$ traceroute6 2001:8b0:648e:6464::129.128.5.194
traceroute6 to 2001:8b0:648e:6464::129.128.5.194 (2001:8b0:648e:6464::8180:5c2) from 2001:8b0:648e:cc01:f2de:f1ff:fef9:a752, 64 hops max, 12 byte packets
 1  2001:8b0:648e:6464::8180:5c2  15.21 ms  33.176 ms  17.477 ms
 2  2001:8b0:648e:6464::8180:5c2  13.95 ms  14.503 ms  14.726 ms
 3  2001:8b0:648e:6464::8180:5c2  14.491 ms  14.187 ms  15.787 ms
 4  2001:8b0:648e:6464::8180:5c2  17.888 ms  19.384 ms  20.193 ms
 5  2001:8b0:648e:6464::8180:5c2  125.817 ms  125.296 ms  126.097 ms
 6  2001:8b0:648e:6464::8180:5c2  149.012 ms  143.149 ms  143.907 ms
 7  2001:8b0:648e:6464::8180:5c2  143.28 ms  143.636 ms  143.629 ms
 8  2001:8b0:648e:6464::8180:5c2  144.288 ms  143.456 ms  143.483 ms
 9  2001:8b0:648e:6464::8180:5c2  144.488 ms  143.657 ms  144.682 ms
10  2001:8b0:648e:6464::8180:5c2  144.796 ms  143.947 ms  150.969 ms
11  2001:8b0:648e:6464::8180:5c2  144.345 ms  144.027 ms  144.346 ms

Also in case you missed it, since this is a "pass in" rule for
inbound traffic coming in on a network interface, if you're testing
from the af-to router itself that won't hit the rule.

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Simon Perreault-3
In reply to this post by Stéphane Guedon
Le 2014-03-12 17:22, Stéphane Guedon a écrit :
>>>         inet 192.168.87.2 netmask 0xffffff00 broadcast
>>>         192.168.87.255
>>
>> Does that mean that you intend to do double NAT? NAT64 then NAT44?
>
> I don't really intend, but have no choice...
> I didn't think of that aspect. Is that important ?

Not really, no. It should work. Just curious what people actually do
with our NAT64 code... :)

Simon

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Stéphane Guedon
Le mercredi 12 mars 2014, 17:36:59 Simon Perreault a écrit :

> Le 2014-03-12 17:22, Stéphane Guedon a écrit :
> >>>         inet 192.168.87.2 netmask 0xffffff00 broadcast
> >>>         192.168.87.255
> >>
> >> Does that mean that you intend to do double NAT? NAT64 then
> >> NAT44?
> >
> > I don't really intend, but have no choice...
> > I didn't think of that aspect. Is that important ?
>
> Not really, no. It should work. Just curious what people actually do
> with our NAT64 code... :)

cool... just after the mail, I thought the same (after all, nat is
just a little transformation of packs on the router, why would it be a
problem ? there's routers all other the net). Let's stop now my
ignorance of net routing.

The fact is that, now, your code don't work because I don't understand
how to set it up. I have had a look at all the doc found on internet
(official or not) and can' figure how how to transform 64:ff9b::/96 to
inet and back.

>
> Simon

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Simon Perreault-3
Le 2014-03-12 17:48, Stéphane Guedon a écrit :
> The fact is that, now, your code don't work because I don't understand
> how to set it up. I have had a look at all the doc found on internet
> (official or not) and can' figure how how to transform 64:ff9b::/96 to
> inet and back.

Well, your pf rule looks good. But you haven't shown us what makes you
think it doesn't work. What did you investigate? Did you do tcpdump on
ingress and egress interfaces? etc. etc. Show us your homework!

Simon

Reply | Threaded
Open this post in threaded view
|

Re: nat64

Stéphane Guedon
Le mercredi 12 mars 2014, 17:51:02 Simon Perreault a écrit :

> Le 2014-03-12 17:48, Stéphane Guedon a écrit :
> > The fact is that, now, your code don't work because I don't
> > understand how to set it up. I have had a look at all the doc
> > found on internet (official or not) and can' figure how how to
> > transform 64:ff9b::/96 to inet and back.
>
> Well, your pf rule looks good. But you haven't shown us what makes
> you think it doesn't work. What did you investigate? Did you do
> tcpdump on ingress and egress interfaces? etc. etc. Show us your
> homework!
>
> Simon

I tried telnet -6 twitter.com (or other famous ipv4-only websites) on
the server itself, or on my desktop.

This desktop access ipv6 world (v6.facebook and others) through the
server without problem (so I assume the routing doesn't have any
problem).

the dns send well good adresses (64:ff9b::c710:9c06 and
64:ff9b::c710:9c26 for twitter).

When I looked at the log or read it real time, pf says he doesn't
received anything. You may be right. maybe the pf rule is good...

eventhough, why there's nothing ?

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]