Simple hardware not getting response when using UDP

  • Hi. Don't really know if this issue is a firewall or NAT problem.
    I have a hardware that transmits pooling packets to a receiver.
    If the hardware does not receive a response on the pooling packet,
    the hardware unit signals LINE FAILURE.

    Traffic from this hardware originates from source port 7700 UDP,
    and it targets destination port 7700 UDP. The receiving hardware
    generates a type of ACK when getting a pool request.

    The problem:

    The technican at the receiver confirms pooling packets arriving,
    and ACK packets being sent, but my hardware does not receive any ACK paket, and pfTop shows no transmissions
    from the target ip coming back to me
    (note that this not any IP ACK, but a hardware specific ACK, it only uses UDP
    as a transmission protocol).


    With a Netgear WGT624v3 firmware version 1.0.128 i had the same problem, but not after
    flashing the firmware up to 2.0.16_1.0.1, that firmware did the job.

    I did some more testing and i removed pfSense from the gateway computer at home where the
    sending unit is, and replaced the OS with ClarkConnect Home 3.2 R1 instead. It worked right away with the
    default CC config.

    And no problem at all with a WatchGuard X10e Edge. Worked right away with default config.

    I'm running pfSense 1.0.1-SNAPSHOT-02-14-2007 built on Fri Feb 16 16 :17:51 EST 2007.
    I have even tried doing portforward on port 7700 to internal ip with the same port
    (not that there is any need for a portforward), but still no luck :-[.

  • Search the forum for static port.

  • Thanks ;D, that did the trick.

    Looks like the technician was looking at the LAN card and never looked at the WAN card,
    because his firewall for this hardware was configured to only allow traffic back to a static port,
    and from what i have noticed is that BSD systems usually use a different translated port then the original source port when
    using NAT.

    Linux did not do this, it used the same source port as the originating source port, thus there was no problem at that point,
    but there would of been a problem if 2 or more units of the same type were behind the same Linux NAT.

    I checked a couple NAT software, and all Linux worked, and all BSD failed.

    The problem was solved when the technician allowed return traffic to every type of source port as long as
    the source did target the UDP port 7700 in the first place.

  • Scrambling ports is done as an extra security mechanism.

Log in to reply