Forwarding Promiscuous Packets over WAN

Discussion in 'Cisco/Linksys Wireless Routers' started by aka_rich, Mar 21, 2011.

  1. aka_rich

    aka_rich Networkin' Nut Member

    Hi Guys,

    I am posting for help because i am running way behind on my project and trying to find some help from anyone....... anywhere!!

    Some background....
    I am working on a product named "LS" for simplicity, that taps into a datastream with a sniffer and then exports the data to a database. From this database, we can use our "LS" tools. One of the main features of the product is that it uses a sniffer so it is "Non-intrusive" to the environment, which will not create any downtime as it is not an active element in the network.
    So again, but in short..... there are 2 sites, the client site has the data we would like to provide feedback on. The other end is the LS product (both ends are separated by Internet).
    Goal --> I need Promiscuously received (LAN) packets to traverse the WAN so they are received by "LS".

    The project i was asked to do was "easier said, than done", but this was to extend the sniffer port over the WAN so that it is not needed to go on site to tap into the data, where i can just send a Router.

    Right now, what it looks like i need is a LAN "Repeater" to Repeat (forward) the packets over the WAN (via VPN). I have seen Wireless Reaters in many 3rd party Router Firmwares, but they do not include any repeater functions for LAN.

    My efforts so far have been mainly with DD-WRT. However, my packets do pass into the LAN area of the Router, but do not traverse the WAN. I somehow need to make these packets go the rest of the way and go across the WAN and then i am finished.

    Problems (and open questions):
    I have found that there are 2 NICs in question (LAN and WAN). The LAN seems to be in Promiscuous mode and accepts all packets of any MAC address. Although it does not seem that the WAN NIC is promiscuous and i cannot turn it On via normal methods.

    The packets i need to receive will not be addressed to the router (via MAC or IP).

    I (and others) have communicated with DD-WRT at different (appropriate) levels and have not got much feedback. However, DD-WRT is great Firmware and would be my 1st choice, but i would go with whatever works right now.

    1) Is what i am required to do even possible?
    2) Could i route Promiscuous Packets through the WAN if i was using a Linux Machine with 2 NICs?
    3) Are there some socket filters that are applied to the WAN's NIC to not allow Promiscuous packets?
    4) Is there someone here who can jump and help?
    5) Is there other software that may be a better approach?


  2. Toxic

    Toxic Administrator Staff Member

    what about setting up a site to site vpn first of all?
  3. aka_rich

    aka_rich Networkin' Nut Member

    Hi Toxic,

    I already have a Site to Site VPN functionality, although the Router is not in a remote location because i have it on test right now.

    I will explain further....
    The Router that i am trying to configure is a Linksys WRT54GL V1.1 and this is capable of being flashed with a variety of different 3rd party Firmwares, including DD-WRT. DD-WRT v24 is currently flashed onto the Router.

    The firmware on the Router can enable it to become a VPN Server or simply as a Client. And it is possible to connect 2 DD-WRT routers via a VPN link, i have already tested this.

    Even if the VPN is connected i still could not push packets down the VPN because it traverses the WAN to get to the VPN. So i have been focusing on getting the packets out of the WAN because this is where it seems to fail.

    Thanks for your prompt reply :),

  4. aka_rich

    aka_rich Networkin' Nut Member


    Maybe i could restate my issue more clearly....

    Router Hardware: WRT54GL V1.1

    There are 2 sites that are separated by WAN, our site and the client site. Each site will have a WRT54GL router that has 3rd party firmware on it (DD-WRT or Open-WRT) because it was planned to provide a VPN layer to extend the sniffer for our in-house Product named as "LS". At the Customer Site we can already use a HUB as a network Tap to provide a data stream for ourselves without interfering with their traffic. In-fact our current design is with the Sniffer + LS being connected to the HUB at the Customer site, but now we need to change this design so the packets will get to LS running in our site via the VPN.

    Client Hardware
    HUB ------> (Customer Site) WRT54GL Router (VPN Client) ------> VPN over WAN ------> WRT54GL (VPN Server) ------> LS (in-house Product) with DB + Sniffer (Our Site)
    Client Server​

    The packets that we will be receiving via the HUB will not be addressed to the router (via MAC or IP). Ordinary function of a std NIC would be not to allow those packets through, so this would need to be in a Promiscuous type mode. From what i know (Im not an expert here!)..... the Router would also need to be in a Promiscuous mode too.

    I have tried so far with both Open-WRT and DD-WRT and had no success. I can only get the packets into the LAN area of the Router, but they do not pass through the WAN.

    To my untrained eye, this does seem more of a configuration problem that is at a linux/kernel level, but i have read all that i can and am truely stuck. I need someone technical who i can bounce my ideas off, because what i am trying to achieve is not normal.


  5. aka_rich

    aka_rich Networkin' Nut Member


    Did you have time to read my posts? I can elaborate more if you need :smile:

    I am still stuck at the same spot and would appreciate any kind input :confused:
  6. aka_rich

    aka_rich Networkin' Nut Member


    I have made a little progress on the way by learning some more Linux...

    It is starting to seem as if i need to build myself something custom to resolve my issue.

    Does anyone know of an Kernel settings that could help my packets flow past the WAN port?

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice