Menu

Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Sign In Register

Setting up IPv6 tunnel over IPv4

jhamiltonjhamilton Newbie ✭
in High End Firewalls

I need to set up a private IPv6 tunnel from our main campus in Raleigh NC (fd00:1ac:1::/64) to our subsidiary campus in High Point NC (fd00:1ac:5::/64) over IPv4.

On our NSA4600 (SonicOS 6.5.4) I went to VPN -> Add VPN Policy and set up the tunnel:

Add-IPv4-Tunnel.png

So far so good.

Then to test the link I went to Network -> Routing to set up a Policy Based Route (PBR) to connect our IPv4 network in High Point (10.5.0.0/16) to our IPv4 network in Raleigh (10.1.0.0/16) through the VPN tunnel:

Add-IPv4-Route.png

It works great. I can ping 10.1.x.x from 10.5.x.x through the IPv4 tunnel, all is wonderful.

I then added an IPv6 Policy Based Route through the IPv4 tunnel to route fd00:1ac:5::/64 to fd00:1ac:1::/64 but I got an error message:

Add-IPv6-Route.png

I went to Google to search for "IPv6 PBR Object ID" and "SonicWall IP version mismatch" and got basically no useful hits.

Questions:

1) Does the SonicWall allow IPv6 to be tunneled through an IPv4 Tunnel? The documentation says yes.

2) Is the above error message expected? Google says no.

Something is messed up. I am wondering if something is fubar in the PBR object table in our SonicWall that has somehow screwed up the mapping of the Object ID with the IP version. Cisco reported a similar bug (https://quickview.cloudapps.cisco.com/quickview/bug/CSCth02826), so I'm wondering if this error message is related.

3) If the answer to #1 and #2 are both yes, then what am I missing in setting up my IPv6-over-IPv4 tunnel?

Category: High End Firewalls
Reply
Tagged:

Answers

  • jhamiltonjhamilton Newbie ✭

    Can anybody confirm if the SonicWall allows IPv6 to be tunneled through an IPv4 site-to-site VPN? The documentation says it can be done. Page 6 of the SonicOS 7and SonicOSX 7 IPSec VPN Administration Guide says,

    VPNs can support either remote access—connecting a user’s computer to a corporate network—or site to site, which is connecting two networks. A VPN can also be used to interconnect two similar networks over a dissimilar middle network: for example, two IPv6 networks connecting over an IPv4 network.

    So it should be possible. However, the Administration Guide does not give any actual instructions on how to provision the SonicWall to tunnel IPv6 inside a IPv4 VPN. Surely someone has done this before? I can't find any online examples on how to do it.

    Meanwhile I am looking at installing and configuring a separate standalone server at both ends so I can build the dang tunnel. My boss is asking me if I will recommend SonicWall for future firewall upgrades and right now I am not very sanguine about it.

  • jhamiltonjhamilton Newbie ✭

    I am making progress. I can now ping IPv6 from fd00:1ac:5::/64 (High Point NC) to fd00:1ac:1::/64 (Raleigh) through an IPv4 GRE tunnel. The return pings are getting dropped by policy despite a wildcard access rule allowing it.

    It turns out that you can create a 6to4 interface for a an IPv4 GRE tunnel for IPv6 packets. It is barely documented, and it is very non-obvious how to provision it. First, you have to create the interface under 'IPv6' not 'IPv4'. This seems intuitively backwards as the interface is assigned IPv4 addresses at both ends, but whatever. Second, you have to provision it right:

    6to4-GRE-Intf-HPLACGRE6.png

    I had to assign the 6to4 GRE interface to the LAN zone. (The choices offered are LAN or WAN, not VPN). For security policy that's okay for us for now. I just want to get working; I can tighten it up later.

    Next I had to assign a the local 'Tunnel Interface IPv6 Address'. This makes no sense to me, as I would expect to have to create an IPv6 route to reach fd00:1ac:1::/64 via the Sonicwall's X1 (LAN) interface (fd00:1ac:5::ff/64 -> fd00:1ac:1::ff/64 via gateway fd00:1ac:1::fd) for PCs on the LAN.

    Then it asks for a 'Prefix Length'. At first I thought this was part of the route info (presumably broadcast to the LAN by IPv6 Router Advertisements), but no. I was also worried that it might start sending out bogus RA address assignments, wrongly handing out fd00:1ac:1::/64 SLAAC assignments to our PCs in High Point and screwing them up, but that didn't happen.

    Question: What the heck does 'Prefix Length' mean in this context? It's not a route. There is no SonicWall documentation on this anywhere I can find. Indeed, I can find no examples of setting up a 6to4 tunnel at all.

    Anyway, at this point I was ready to run a ping test. I went to Manage -> System Diagnostics and pinged the remote Tunnel IPv6 Address (fd00:1ac:1::fd).

    Guess what, it worked! Hooray! I received back an ICMPv6 Type 129 (Echo Reply) packet...

    .. which the SonicWall promptly dropped, citing a policy violation in the log ('No rule LAN -> LAN for this packet type').

    So close. I added an access rule for Zone LAN -> Zone LAN for any packet type. The packets still got dropped. Interestingly, the packet statistics for the rule showed an incrementing Tx packet count for each ping attempt, but zero Rx packets coming back.

    I am so close now, but the dang Sonicwall is dropping all incoming IPv6 packets from the 6to4 tunnel no matter what access rules I add. Either there is something I don't understand, or there is a bug.

    Even if I get this working, there is still the problem that the 6to4 GRE tunnel is not encrypting anything. Obviously I don't want plaintext IPv6 packets tunneling around on the public Internet. Again there seems to be zero documentation from Sonicwall on how to do this.

    Why is this so hard? Getting this to work with the Sonicwall is like banging my head against the wall.

  • jhamiltonjhamilton Newbie ✭

    The other weird thing was the source address on the ICMPv6 Ping Reply (Type 129). The SonicWall at Highpoint has X1 (LAN) fd00:1ac:1::ff, with its counterpart in Raleigh having fd00:1ac:5::ff.

    I pinged from HighPoint to fd00:1ac:5::fd and got a reply, which was wrongly dropped per policy as I explained above. The weird thing is that the dropped Ping Reply packet had source=fd00:1ac:1:ff (Raleigh X1) dest=fd00:1ac:5::fd (High Point GRE). The source of fd00:1ac:1::ff was odd. I expected to see fd00:1ac:1::fd not ff.

    So I tried changing the 6to4 GRE tunnel by assigning a 'Tunnel Interface IPv6 Address' of fd00:1ac:5::ff to match the X1 address. The Sonicwall promptly bitched at me that I was trying to assign the same IPv6 address to two different interfaces (which makes sense). Pinging fd00:1ac:1::ff didn't work either, but I expected that (no route).

    I don't get the weird source address on the ping reply. Either there is something I don't understand or it's a bug.

  • jhamiltonjhamilton Newbie ✭

    Fixed typos:

    I would expect to have to create an IPv6 route to reach fd00:1ac:1::/64 via the Sonicwall's X1 (LAN) interface (fd00:1ac:5::ff/64 -> fd00:1ac:1::ff/64 via gateway fd00:1ac:5::fd) for PCs on the LAN.

    I pinged from from High Point to fd00:1ac:1::fd and got a reply.

  • jhamiltonjhamilton Newbie ✭

    Nobody responded to my plea for help. I give up.

    I'll spin up a pair of Windows Servers running Routing and Remote Access Services (RRAS) to create the tunnel.

Sign In or Register to comment.