NAT64 troubleshooting

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

NAT64 troubleshooting

Kamil Jiwa
Hi, I've got an IPv6 network that I'd like to connect to an IPv4
network with a NAT64 router. The router has two interfaces with the
following configurations:

    - em0: internal, IPv6 network
        - IPv4 address: 10.0.66.1/24
        - IPv6 address: fc00::1/64

    - em1: external, IPv4 network
        - IPv4 address: DHCP
        - IPv6 address: none

I've enabled IP forwarding:

    # sysctl net.inet.ip.forwarding
    net.inet.ip.forwarding=1
    # sysctl net.inet6.ip6.forwarding
    net.inet6.ip6.forwarding=1

Here's my /etc/pf.conf _before_ adding any NAT64 rules. Note that it
is set up to perform NAT44 and I've verified that part works.

    set block-policy return
    set loginterface egress
    set skip on lo
    match out on egress inet from em0:network to any nat-to (egress:0)
    block in log
    pass out quick
    pass in inet proto icmp all icmp-type echoreq
    pass in on em0

I'd like to translate any requests going to fc00::ffff:0:0/96 into
IPv4 requests. An example address is 173.194.33.80 (www.google.com).
This gets mapped to fc00::ffff:adc2:2150. I expected the following
rule to work:

    pass in on em0 inet6 from any to fc00::ffff:0:0/96 af-to inet from (em0)

When I try to ping Google (with the address above) address from
another host on the internal network I get these errors:

    $ ping6 fc00::ffff:adc2:2150
    PING fc00::ffff:adc2:2150(fc00::ffff:adc2:2150) 56 data bytes
    From fc00::33 icmp_seq=1 Destination unreachable: Address unreachable

I can see the packets coming in on the router itself.

    # tcpdump -nvvi em0 -c 10
    tcpdump: listening on em0, link-type EN10MB
    tcpdump: WARNING: compensating for unaligned libpcap packets
    21:44:21.280527 fc00::33 > ff02::1:ffc2:2150: icmp6: neighbor sol:
who has fc00::ffff:adc2:2150(src lladdr: 08:00:27:71:55:eb) [icmp6
cksum ok] (len 32, hlim 255)
    21:44:22.282785 fc00::33 > ff02::1:ffc2:2150: icmp6: neighbor sol:
who has fc00::ffff:adc2:2150(src lladdr: 08:00:27:71:55:eb) [icmp6
cksum ok] (len 32, hlim 255)

I know the router itself works with NAT44 because I can assign the
host an internal IPv4 address and ping external sites. I'm trying to
understand what is missing for IPv6 packets to be translated and
routed by the router. Thanks.

Kamil
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NAT64 troubleshooting

Stuart Henderson-6
On 2014/11/13 21:55, Kamil Jiwa wrote:

> Hi, I've got an IPv6 network that I'd like to connect to an IPv4
> network with a NAT64 router. The router has two interfaces with the
> following configurations:
>
>     - em0: internal, IPv6 network
>         - IPv4 address: 10.0.66.1/24
>         - IPv6 address: fc00::1/64
>
>     - em1: external, IPv4 network
>         - IPv4 address: DHCP
>         - IPv6 address: none
>
> I've enabled IP forwarding:
>
>     # sysctl net.inet.ip.forwarding
>     net.inet.ip.forwarding=1
>     # sysctl net.inet6.ip6.forwarding
>     net.inet6.ip6.forwarding=1
>
> Here's my /etc/pf.conf _before_ adding any NAT64 rules. Note that it
> is set up to perform NAT44 and I've verified that part works.
>
>     set block-policy return
>     set loginterface egress
>     set skip on lo
>     match out on egress inet from em0:network to any nat-to (egress:0)
>     block in log
>     pass out quick
>     pass in inet proto icmp all icmp-type echoreq
>     pass in on em0
>
> I'd like to translate any requests going to fc00::ffff:0:0/96 into
> IPv4 requests. An example address is 173.194.33.80 (www.google.com).
> This gets mapped to fc00::ffff:adc2:2150. I expected the following
> rule to work:
>
>     pass in on em0 inet6 from any to fc00::ffff:0:0/96 af-to inet from (em0)

These rules are correct, the problem is occurring before packets
reach PF - you need a valid route table entry otherwise they will
be rejected earlier in the stack.

Not fully tested as I have v6 routes on my machines, but something
like this should be enough:

        route add -inet6 default ::1 -reject

> When I try to ping Google (with the address above) address from
> another host on the internal network I get these errors:
>
>     $ ping6 fc00::ffff:adc2:2150

BTW there is another valid address format which saves a manual
hex conversion:

        $ ping6 fc00::ffff:173.194.33.80
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NAT64 troubleshooting

Kamil Jiwa
Thanks Stuart. I set the default route on my host and I can see it in
my route table but I'm still not able to send out pings. Is there a
way I can verify that the packets are making it to PF? Does the order
of that command in /etc/pf.conf make a difference?

Kamil

On Fri, Nov 14, 2014 at 1:25 AM, Stuart Henderson <[hidden email]> wrote:

> On 2014/11/13 21:55, Kamil Jiwa wrote:
>> Hi, I've got an IPv6 network that I'd like to connect to an IPv4
>> network with a NAT64 router. The router has two interfaces with the
>> following configurations:
>>
>>     - em0: internal, IPv6 network
>>         - IPv4 address: 10.0.66.1/24
>>         - IPv6 address: fc00::1/64
>>
>>     - em1: external, IPv4 network
>>         - IPv4 address: DHCP
>>         - IPv6 address: none
>>
>> I've enabled IP forwarding:
>>
>>     # sysctl net.inet.ip.forwarding
>>     net.inet.ip.forwarding=1
>>     # sysctl net.inet6.ip6.forwarding
>>     net.inet6.ip6.forwarding=1
>>
>> Here's my /etc/pf.conf _before_ adding any NAT64 rules. Note that it
>> is set up to perform NAT44 and I've verified that part works.
>>
>>     set block-policy return
>>     set loginterface egress
>>     set skip on lo
>>     match out on egress inet from em0:network to any nat-to (egress:0)
>>     block in log
>>     pass out quick
>>     pass in inet proto icmp all icmp-type echoreq
>>     pass in on em0
>>
>> I'd like to translate any requests going to fc00::ffff:0:0/96 into
>> IPv4 requests. An example address is 173.194.33.80 (www.google.com).
>> This gets mapped to fc00::ffff:adc2:2150. I expected the following
>> rule to work:
>>
>>     pass in on em0 inet6 from any to fc00::ffff:0:0/96 af-to inet from (em0)
>
> These rules are correct, the problem is occurring before packets
> reach PF - you need a valid route table entry otherwise they will
> be rejected earlier in the stack.
>
> Not fully tested as I have v6 routes on my machines, but something
> like this should be enough:
>
>         route add -inet6 default ::1 -reject
>
>> When I try to ping Google (with the address above) address from
>> another host on the internal network I get these errors:
>>
>>     $ ping6 fc00::ffff:adc2:2150
>
> BTW there is another valid address format which saves a manual
> hex conversion:
>
>         $ ping6 fc00::ffff:173.194.33.80
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NAT64 troubleshooting

Torsten Schuchort
In reply to this post by Stuart Henderson-6
Hi, i’ve got trouble with nat64 to until i changed the default state policy for the nat64 rule.
pf set’s for default „set state-policy if-bound“, so is use for the nat64 rule:

pass in log quick on $int_if inet6 from any to 64:ff9b::/96 af-to inet from $ext_if modulate state (floating)

maybe this is a useful hint.



Am 14.11.2014 um 10:25 schrieb Stuart Henderson <[hidden email]>:

On 2014/11/13 21:55, Kamil Jiwa wrote:
Hi, I've got an IPv6 network that I'd like to connect to an IPv4
network with a NAT64 router. The router has two interfaces with the
following configurations:

   - em0: internal, IPv6 network
       - IPv4 address: 10.0.66.1/24
       - IPv6 address: fc00::1/64

   - em1: external, IPv4 network
       - IPv4 address: DHCP
       - IPv6 address: none

I've enabled IP forwarding:

   # sysctl net.inet.ip.forwarding
   net.inet.ip.forwarding=1
   # sysctl net.inet6.ip6.forwarding
   net.inet6.ip6.forwarding=1

Here's my /etc/pf.conf _before_ adding any NAT64 rules. Note that it
is set up to perform NAT44 and I've verified that part works.

   set block-policy return
   set loginterface egress
   set skip on lo
   match out on egress inet from em0:network to any nat-to (egress:0)
   block in log
   pass out quick
   pass in inet proto icmp all icmp-type echoreq
   pass in on em0

I'd like to translate any requests going to fc00::ffff:0:0/96 into
IPv4 requests. An example address is 173.194.33.80 (www.google.com).
This gets mapped to fc00::ffff:adc2:2150. I expected the following
rule to work:

   pass in on em0 inet6 from any to fc00::ffff:0:0/96 af-to inet from (em0)

These rules are correct, the problem is occurring before packets
reach PF - you need a valid route table entry otherwise they will
be rejected earlier in the stack.

Not fully tested as I have v6 routes on my machines, but something
like this should be enough:

route add -inet6 default ::1 -reject

When I try to ping Google (with the address above) address from
another host on the internal network I get these errors:

   $ ping6 fc00::ffff:adc2:2150

BTW there is another valid address format which saves a manual
hex conversion:

$ ping6 fc00::ffff:173.194.33.80

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NAT64 troubleshooting

Henning Brauer-2
* Torsten Schuchort <[hidden email]> [2014-11-23 20:00]:
> Hi, i’ve got trouble with nat64 to until i changed the default state policy for the nat64 rule.
> pf set’s for default „set state-policy if-bound“, so is use for the nat64 rule:

just to make it utterly clear: the default is "floating", and NOT
if-bound. For good reasons. if-bound really only makes sense for enc
and the like.

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NAT64 troubleshooting

Torsten Schuchort

> Am 01.12.2014 um 13:36 schrieb Henning Brauer <[hidden email]>:
>
> * Torsten Schuchort <[hidden email]> [2014-11-23 20:00]:
>> Hi, i’ve got trouble with nat64 to until i changed the default state policy for the nat64 rule.
>> pf set’s for default „set state-policy if-bound“, so is use for the nat64 rule:
>
> just to make it utterly clear: the default is "floating", and NOT
> if-bound. For good reasons. if-bound really only makes sense for enc
> and the like.

so if-bound is only useful for interfaces like enc and tun etc. ? Can you please explain this for me, or us. Only for interest?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NAT64 troubleshooting

Torsten Schuchort

> Am 10.12.2014 um 17:59 schrieb Torsten Schuchort <[hidden email]>:
>
>
>> Am 01.12.2014 um 13:36 schrieb Henning Brauer <[hidden email]>:
>>
>> * Torsten Schuchort <[hidden email]> [2014-11-23 20:00]:
>>> Hi, i’ve got trouble with nat64 to until i changed the default state policy for the nat64 rule.
>>> pf set’s for default „set state-policy if-bound“, so is use for the nat64 rule:
>>
>> just to make it utterly clear: the default is "floating", and NOT
>> if-bound. For good reasons. if-bound really only makes sense for enc
>> and the like.
>
> so if-bound is only useful for interfaces like enc and tun etc. ? Can you please explain this for me, or us. Only for interest?
Forget my request, found it by myself in the book of pf and it make sense for me.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NAT64 troubleshooting

Henning Brauer-2
* Torsten Schuchort <[hidden email]> [2014-12-10 20:34]:
> > Am 10.12.2014 um 17:59 schrieb Torsten Schuchort <[hidden email]>:
> > Can you please explain this for me, or us. Only for interest?
> Forget my request, found it by myself in the book of pf and it make sense for me.

see? Explaining things to peter (if needed, at all) once, usually
during the tech edit phase, is more efficient than repeating
explanations on some ML every now and then. At least from my PoV :)

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
Loading...