Forum Discussion

Mike_Maher's avatar
Mike_Maher
Icon for Nimbostratus rankNimbostratus
Apr 26, 2011

IPv6 translation to v4

So we are in the process of doing a POC in our labs using Big-IP. Currently we have LTM and ASM on 2 seperate hardware devices. Right now I have an ASM setup with a v6 Virtual Server, that has SNATing setup with a v4 address. The traffic is then pointed to a pool that contains a v4 Virtual Server on that same device that pushes the traffic through a class to the web server on the back in that is v4.

 

When running TCPDump I see traffic hitting the v6 VS but I am not seeing any traffic hit the v4 server. Honestly I am not sure if I should be seeing it in TCPdump or if TMOS is smarter than I am :) and just handling it via some internal channel.

 

If anyone has any thoughts on or is trying to make v6 work through ASM I would appreciate any help.

 

 

Mike

 

8 Replies

  • Hi Mike,

     

     

    ASM doesn't completely support IPv6 in current versions. I think you should be able to get IPv6 traffic through ASM, but IP-specific functionality like DDOS won't work yet. I'd get in touch with the person helping with the PoC to get more details.

     

     

    Is there a reason you have ASM processing the traffic first? Do you have an ASM standalone unit or a full ASM? Can you try with an IPv6 client facing virtual server which points to a pool containing the IPv4 ASM virtual server?

     

     

    Aaron

     

     

  • Hoolio is correct, we currently do not support IPv6 traffic in ASM. I am sure that something is choking somewhere there when ASM tries to look at the IPv6 address.

     

     

    Until ASM has full native IPv6 support, there might be a way to accomplish what you want using layered virtual servers. Essentially, you would have an IPv6 Virtual server that would do SNAT and target the internal IPv4 virtual server that will have ASM enabled. Since ASM will see the source IP as v4(after translation), things should work without a hitch - and that ASM virtual will then SNAT again and load-balance to the pool of actual IPv4 servers. The downside of this approach is that you will lose your source IP address in the ASM logs for violations.

     

  • Actually, I just realized another issue that you have - if you've added an IPv4 virtual IP to a pool, it won't work at all - while the GUI allows it, unfortunately, the only way this will properly work is if you use a virtual command in an iRule. VIP still cannot be a pool member - I believe there is an issue with the GUI validation that we need to investigate.

     

     

  • Guys,

     

    Thanks for the tips, we had already figured out that ASM does not support IPv6 as anytime we added it to a VS the traffic would just die.

     

     

    Yes we were trying to set a v6 VS with SNATing and then add a pool with a v4 VS inside it but it is not working. As I know see from Michael's post it apparently won't work. I will try using an iRule to direct the traffic.

     

     

    One last part that I was questioning, is that when we were doing a TCPDump on port 80 which is the port both the v4 and v6 VS are setup on, we would see the traffic hitting the v6 server but never the v4. Is that because of the fact that it won't work inside the pool, when I setup the iRule should I expect to see the traffic in tcpdump? Thanks for the help so far.

     

     

     

  • So will something as simple as this work?

     

     

    when HTTP_REQUEST {

     

    node 172.2.3.4 80

     

    }
  • Oh one other thing we have another iRule that will be needed on the v6 VS as well, that preserves the orginal source address and UA String in the header. I looks like this. Would there be a problem with running both of these on the same VS. Thanks

     

     

    when HTTP_REQUEST {

     

    HTTP::header insert x-remote-host [IP::remote_addr]

     

    HTTP::header insert x-user-agent [HTTP::header User-Agent]

     

    }
  • Are you testing on one BIG-IP? If so, you can use the virtual command to send traffic to another VS:

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/virtual

     

     

    You can insert as many HTTP headers as you like. The inserts you've posted should work fine. But the original User-Agent header shouldn't be modified, so I assume the web app could just reference that instead of a custom x- header.

     

     

    Aaron
  • So would this work to cover everything in one iRule?

     

     

    when HTTP_REQUEST {

     

    HTTP::header insert x-remote-host [IP::remote_addr]

     

    HTTP::header insert x-user-agent [HTTP::header User-Agent]

     

     

    virtual VS_Name

     

    }