Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    IPv6 equivalent to intercept outbound traffic from host?

    IPv6
    1
    1
    36
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      te last edited by

      I'm trying to figure out the best IPv6 equivalent to redirect outbound traffic from a specific host to another to actively intercept the network traffic coming from the host. I do a lot of device testing which are often embedded or similar devices which I do not have direct control over. I want to trivially capture the traffic leaving the device.

      In the IPv4 world this is easiest to trivially accomplish with a simple NAT rule:

      Interface: LAN
      Protocol: TCP
      Source: Host.IP.0.10
      Destination: !LAN net
      Destination Port: 80 (or whatever)
      Redirect Target IP: MITM.IP.0.5
      Redirect Port: 8080 (or whatever)

      And all outbound traffic to port 80 is redirected to the local MITM host. There are other methods, sure, you could probably make a static DHCP entry where you set the default gateway for that client and accomplish something similar.

      For IPv6, without NAT66 support that method doesn't work though. In practice, most of the time, testing can be accomplished by simply disabling IPv6 for the device VLAN to force the device to just use IPv4, but this isn't always guaranteed to work especially as some IPv6 only devices and servers are showing up. In cases where the physical device is right in front of me I can isolate it by using a laptop running Ubuntu or similar with two NICs and doing NAT on that where I can use iptables and NAT66 to redirect the connection locally, but this isn't always easy or practical, especially if it only connects over wifi or if the device is just on the same VLAN, but not physically on my desk. It works, but I end up with 5 PCs, a bunch of a devices, and a pile of cables on my desk. The NAT solution is easy, it's a few clicks and the packets show up where I want them to, on a VM, at my desktop, wherever.

      What's my best option using pfsense to do something similar with IPv6?

      I'm just racking my head how doing something simple with routing or RA advertisements to target a specific device would work. I guess if you isolated the device to it's own VLAN tagging it at the switch level you could do a routing solution by setting the IPv6 upstream gateway in pfsense? In cases where the device doesn't use it's own hardcoded DNS server, you could possibly give it a local DNS server through RA that returns the MITM.IP for all requests from a specific host? Not infeasible, but definitely more work.

      Am I missing something obvious, how would you do this?

      1 Reply Last reply Reply Quote 0
      • First post
        Last post

      Products

      • Platform Overview
      • TNSR
      • pfSense Plus
      • Appliances

      Services

      • Training
      • Professional Services

      Support

      • Subscription Plans
      • Contact Support
      • Product Lifecycle
      • Documentation

      News

      • Media Coverage
      • Press
      • Events

      Resources

      • Blog
      • FAQ
      • Find a Partner
      • Resource Library
      • Security Information

      Company

      • About Us
      • Careers
      • Partners
      • Contact Us
      • Legal
      Our Mission

      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

      Subscribe to our Newsletter

      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

      © 2021 Rubicon Communications, LLC | Privacy Policy