relay.verizon.net oddness - TCP-IP

This is a discussion on relay.verizon.net oddness - TCP-IP ; These last few weeks I've noticed that mail to user@verizon.net always fails with a timeout connecting to relay.verizon.net. After checking the usual black hole lists and such I got around to snooping on a transaction. I saw that the SYN/ACK ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: relay.verizon.net oddness

  1. relay.verizon.net oddness

    These last few weeks I've noticed that mail to user@verizon.net always
    fails with a timeout connecting to relay.verizon.net. After checking
    the usual black hole lists and such I got around to snooping on a
    transaction. I saw that the SYN/ACK response to my mail server's SYN
    (a) claimed to have 4 data bytes of 0 and (b) had a bad checksum.

    Not believing that tcp/ip had changed that much while I wasn't looking
    I tried some other machines and found that more "modern" stacks could
    connect to relay.verizon.net's smtp port without a problem. This was
    not because they understood the weird SYN/ACK but because it did not
    occur. Near as I can tell, as long as you send some option(s) with
    the initial SYN, relay.verizon.net sends a reasonable SYN/ACK. But
    if you send no options at all it sends a broken response. My mail
    server sends no options at all; hence the problem.

    This all seems too weird to accept at face value. Can someone confirm
    (or better, refute) my observations?

    Dan Lanciani
    ddl@danlan.*com

  2. Re: relay.verizon.net oddness

    In article <1341132@news1.IPSWITCHS.CMM>,
    ddl@danlan.*com (Dan Lanciani) wrote:

    > These last few weeks I've noticed that mail to user@verizon.net always
    > fails with a timeout connecting to relay.verizon.net. After checking
    > the usual black hole lists and such I got around to snooping on a
    > transaction. I saw that the SYN/ACK response to my mail server's SYN
    > (a) claimed to have 4 data bytes of 0 and (b) had a bad checksum.


    I think that's the fingerprint of a Symantec Gateway Security firewall's
    SYN-flood protection mechanism. It expects you to respond to this with
    an RST and then try again, and then it knows that the SYN came from a
    real address.

    But many systems (like yours) just ignore these bogus replies, so it's
    recommended that SGS owners not turn this feature on unless they're
    under an attack and need to mitigate it.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: relay.verizon.net oddness

    In article , barmar@alum.mit.edu (Barry Margolin) writes:
    | In article <1341132@news1.IPSWITCHS.CMM>,
    | ddl@danlan.*com (Dan Lanciani) wrote:
    |
    | > These last few weeks I've noticed that mail to user@verizon.net always
    | > fails with a timeout connecting to relay.verizon.net. After checking
    | > the usual black hole lists and such I got around to snooping on a
    | > transaction. I saw that the SYN/ACK response to my mail server's SYN
    | > (a) claimed to have 4 data bytes of 0 and (b) had a bad checksum.
    |
    | I think that's the fingerprint of a Symantec Gateway Security firewall's
    | SYN-flood protection mechanism. It expects you to respond to this with
    | an RST and then try again, and then it knows that the SYN came from a
    | real address.

    Hmm. So are there really stacks that will respond with an RST to a packet
    with a bad checksum? That seems like a very bad idea.

    And why would SGS do this strange thing only if I do not include any
    options in the initial SYN packet? It feels like a bug.

    Dan

  4. Re: relay.verizon.net oddness

    In article <1341163@news1.IPSWITCHS.CMM>,
    ddl@danlan.*com (Dan Lanciani) wrote:

    > In article ,
    > barmar@alum.mit.edu (Barry Margolin) writes:
    > | In article <1341132@news1.IPSWITCHS.CMM>,
    > | ddl@danlan.*com (Dan Lanciani) wrote:
    > |
    > | > These last few weeks I've noticed that mail to user@verizon.net always
    > | > fails with a timeout connecting to relay.verizon.net. After checking
    > | > the usual black hole lists and such I got around to snooping on a
    > | > transaction. I saw that the SYN/ACK response to my mail server's SYN
    > | > (a) claimed to have 4 data bytes of 0 and (b) had a bad checksum.
    > |
    > | I think that's the fingerprint of a Symantec Gateway Security firewall's
    > | SYN-flood protection mechanism. It expects you to respond to this with
    > | an RST and then try again, and then it knows that the SYN came from a
    > | real address.
    >
    > Hmm. So are there really stacks that will respond with an RST to a packet
    > with a bad checksum? That seems like a very bad idea.


    Actually, I don't recall if the bad checksum was part of the behavior.
    I just remember the reply with 4 data bytes.

    > And why would SGS do this strange thing only if I do not include any
    > options in the initial SYN packet? It feels like a bug.


    No idea. They eventually got rid of this algorithm, so I think you're
    hitting a site with an old version of the firewall.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  5. Re: relay.verizon.net oddness

    In article , barmar@alum.mit.edu (Barry Margolin) writes:
    | In article <1341163@news1.IPSWITCHS.CMM>,
    | ddl@danlan.*com (Dan Lanciani) wrote:

    | > And why would SGS do this strange thing only if I do not include any
    | > options in the initial SYN packet? It feels like a bug.
    |
    | No idea. They eventually got rid of this algorithm, so I think you're
    | hitting a site with an old version of the firewall.

    This just started recently and I wouldn't think that Verizon would
    dig up an obsolete firewall to install in front of what appears to
    be their main relay for verizon.net, but I guess anything is possible.

    Dan Lanciani
    ddl@danlan.&com

  6. Re: relay.verizon.net oddness



    In article <1341132@news1.IPSWITCHS.CMM>, Dan Lanciani wrote:

    >occur. Near as I can tell, as long as you send some option(s) with
    >the initial SYN, relay.verizon.net sends a reasonable SYN/ACK. But
    >if you send no options at all it sends a broken response. My mail
    >server sends no options at all; hence the problem.


    In article <1341189@news1.IPSWITCHS.CMM>, Dan Lanciani wrote:

    >This just started recently and I wouldn't think that Verizon would
    >dig up an obsolete firewall to install in front of what appears to
    >be their main relay for verizon.net, but I guess anything is possible.


    It sounds like a bug to me too, but one that is almost never hit because
    so many TCP clients send MSS and other options with the SYN. It would
    _almost_ be reasonable for Verizon to say that an incoming SYN without
    even an MSS option is broken or an evil nasty 'cracking' probe.


    Vernon Schryver vjs@rhyolite.com

  7. Re: relay.verizon.net oddness

    In article <1341189@news1.IPSWITCHS.CMM>,
    ddl@danlan.*com (Dan Lanciani) wrote:

    > In article ,
    > barmar@alum.mit.edu (Barry Margolin) writes:
    > | In article <1341163@news1.IPSWITCHS.CMM>,
    > | ddl@danlan.*com (Dan Lanciani) wrote:
    >
    > | > And why would SGS do this strange thing only if I do not include any
    > | > options in the initial SYN packet? It feels like a bug.
    > |
    > | No idea. They eventually got rid of this algorithm, so I think you're
    > | hitting a site with an old version of the firewall.
    >
    > This just started recently and I wouldn't think that Verizon would
    > dig up an obsolete firewall to install in front of what appears to
    > be their main relay for verizon.net, but I guess anything is possible.


    Verizon has been a Symantec firewall customer for many years, I think
    they were mostly using the software version, not the appliances, which
    stopped being upgraded after the previous major release. What may have
    happened recently is that they enabled the SYN-flood protection for some
    reason.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  8. Re: relay.verizon.net oddness

    In article , vjs@calcite.rhyolite.com (Vernon Schryver) writes:

    | In article <1341132@news1.IPSWITCHS.CMM>, Dan Lanciani wrote:
    |
    | >occur. Near as I can tell, as long as you send some option(s) with
    | >the initial SYN, relay.verizon.net sends a reasonable SYN/ACK. But
    | >if you send no options at all it sends a broken response. My mail
    | >server sends no options at all; hence the problem.
    |
    | In article <1341189@news1.IPSWITCHS.CMM>, Dan Lanciani wrote:
    |
    | >This just started recently and I wouldn't think that Verizon would
    | >dig up an obsolete firewall to install in front of what appears to
    | >be their main relay for verizon.net, but I guess anything is possible.
    |
    | It sounds like a bug to me too, but one that is almost never hit because
    | so many TCP clients send MSS and other options with the SYN. It would
    | _almost_ be reasonable for Verizon to say that an incoming SYN without
    | even an MSS option is broken or an evil nasty 'cracking' probe.

    This kind of snuck up on me. The canonical BSD code from the 80's didn't
    send MSS when it wanted the default and that was the only option it knew
    about. The last SunOS 4.x (Solaris 1.x) behaves this way, as does my own
    stack based on BSD. The latter is easy enough to change and I suppose I
    can patch the Sun's kernel (though I am not really a Sparc assembly language
    person). I guess this is my punishment for using really, really old
    machines.

    I wonder if the MSS tweaker on a Cisco will add the option if it does
    not already exist.

    Dan Lanciani
    ddl@danlan.*com

+ Reply to Thread