Destination Unreachable when trying SMTP from behind a PIX 501

Discussion in 'Cisco' started by MyndPhlyp, Dec 15, 2003.

  1. MyndPhlyp

    MyndPhlyp Guest

    I'm having a bit of a problem with SMTP - getting an ICMP Destination
    Unreachable on the first hop outbound with an email client. It appears to be
    due to something in my PIX 501 configuration, but I have yet to discover the
    solution.

    Just for grins, I took the PIX out of the picture and installed a wide open
    Linksys. Tried a POP3/SMTP exchange and didn't get the ICMP error. (I didn't
    get total success either, but THAT particular problem is at the other end of
    the wire. <g>)

    With the PIX 501 on the line, I can trace route to the mail server with no
    problem. The POP3 side of things works just fine.

    It's just SMTP that is hosing me up.

    Pertinent to POP3/SMTP, I have a "fixup" for SMTP and both SMTP and POP3 are
    allowed out, unrestricted. If it matters, I'm using PAT on an ADSL
    connection. I am trying to keep the configuration tight - "deny everything
    except" - on both inbound and outbound rather than allowing everything
    outbound.

    Any ideas on what brick needs to be removed from the wall?
     
    MyndPhlyp, Dec 15, 2003
    #1
    1. Advertising

  2. In article <c3nDb.5619$>,
    MyndPhlyp <> wrote:
    :I'm having a bit of a problem with SMTP - getting an ICMP Destination
    :Unreachable on the first hop outbound with an email client. It appears to be
    :due to something in my PIX 501 configuration, but I have yet to discover the
    :solution.

    :pertinent to POP3/SMTP, I have a "fixup" for SMTP and both SMTP and POP3 are
    :allowed out, unrestricted. If it matters, I'm using PAT on an ADSL
    :connection.

    Is there a valid reverse DNS for the outside IP? Not having one
    can cause problems with the smtp fixup. Usually, though, those
    problems would only be for incoming smtp.

    Try turning off the smtp fixup and see if that helps with your
    outgoing smtp.


    :I am trying to keep the configuration tight - "deny everything
    :except" - on both inbound and outbound rather than allowing everything
    :eek:utbound.

    Hmmm -- is it possible there's a DNS problem? e.g., if the
    destination has an MX record but you aren't allowing DNS and so you
    aren't discovering the MX and so are going directly to the host...

    --
    vi -- think of it as practice for the ROGUE Olympics!
     
    Walter Roberson, Dec 15, 2003
    #2
    1. Advertising

  3. MyndPhlyp

    MyndPhlyp Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:brkvh8$puo$...
    > In article <c3nDb.5619$>,
    > MyndPhlyp <> wrote:
    > :I'm having a bit of a problem with SMTP - getting an ICMP Destination
    > :Unreachable on the first hop outbound with an email client. It appears to

    be
    > :due to something in my PIX 501 configuration, but I have yet to discover

    the
    > :solution.
    >
    > :pertinent to POP3/SMTP, I have a "fixup" for SMTP and both SMTP and POP3

    are
    > :allowed out, unrestricted. If it matters, I'm using PAT on an ADSL
    > :connection.
    >
    > Is there a valid reverse DNS for the outside IP? Not having one
    > can cause problems with the smtp fixup. Usually, though, those
    > problems would only be for incoming smtp.
    >
    > Try turning off the smtp fixup and see if that helps with your
    > outgoing smtp.
    >
    >
    > :I am trying to keep the configuration tight - "deny everything
    > :except" - on both inbound and outbound rather than allowing everything
    > :eek:utbound.
    >
    > Hmmm -- is it possible there's a DNS problem? e.g., if the
    > destination has an MX record but you aren't allowing DNS and so you
    > aren't discovering the MX and so are going directly to the host...


    DNS is allowed through the PIX.

    It is questionable whether or not the host domain's DNS is completely set
    up. There is certainly an MX record - they receive mail on a regular basis
    from the outside world.

    If I use only the host's domain as a POP3 and/or SMTP server, it (in this
    case, Outlook Express) fails miserably. I have to use the fully-qualified
    mail host's name or IP address.

    The reverse DNS points to the ISP's name for the IP address, not the mail
    host's domain.

    I tried turning off the SMTP fixup, but it didn't help. I tried setting SNMP
    logging to Debug to see if I could catch anything interesting. Nothing.

    The only inbound opening I have is any ICMP. The DNS, POP3 and SMTP are open
    outbound only. Seems valid since I am not offering any of those services to
    the Internet.

    So far, the only clue I have is that running on the 'Net bare naked gets me
    past the Destination Unreachable. And while running naked is fun once in a
    while, eventually we all get caught.

    More ideas?
     
    MyndPhlyp, Dec 15, 2003
    #3
  4. MyndPhlyp

    Rik Bain Guest

    On Mon, 15 Dec 2003 15:40:12 -0600, MyndPhlyp wrote:

    >
    > DNS is allowed through the PIX.
    >
    > It is questionable whether or not the host domain's DNS is completely
    > set up. There is certainly an MX record - they receive mail on a regular
    > basis from the outside world.
    >
    > If I use only the host's domain as a POP3 and/or SMTP server, it (in
    > this case, Outlook Express) fails miserably. I have to use the
    > fully-qualified mail host's name or IP address.
    >
    > The reverse DNS points to the ISP's name for the IP address, not the
    > mail host's domain.
    >
    > I tried turning off the SMTP fixup, but it didn't help. I tried setting
    > SNMP logging to Debug to see if I could catch anything interesting.
    > Nothing.
    >
    > The only inbound opening I have is any ICMP. The DNS, POP3 and SMTP are
    > open outbound only. Seems valid since I am not offering any of those
    > services to the Internet.
    >
    > So far, the only clue I have is that running on the 'Net bare naked gets
    > me past the Destination Unreachable. And while running naked is fun once
    > in a while, eventually we all get caught.
    >
    > More ideas?


    Can you post the contents of the ICMP packet?
    Also, I doubt this is it but it bears mentioning, the SMTP server may do
    an IDENT lookup for all connecting hosts. The pix will drop this packet
    by default, causing connection delays/failures.

    Rik Bain
     
    Rik Bain, Dec 15, 2003
    #4
  5. MyndPhlyp

    MyndPhlyp Guest

    Just a little additional info:

    With syslog=debug, the only thing I get is:

    %PIX-6-302013: Built outbound TCP connection <###> for
    outside:<mailhostip/25> (mailhostip/25) to inside:<clientip/port>
    (pixwanip/port)
    %PIX-6-305011: Built dynamic TCP translation from inside:clientip/port to
    outside:pixwanip/port

    The packets caught by Ethereal are (shorthand):

    TCP/SMTP => outbound
    ICMP Destination Unreachable
    TCP/SMTP => outbound
    ICMP Destination Unreachable
    TCP/SMTP => outbound
    ICMP Destination Unreachable


    I never see the teardown process from the PIX.

    I did a little snooping with NSLOOKUP. Their MX record definitely points to
    the fully-qualified mail server's name and PING resolves to the correct IP
    address. As mentioned before, PING -A resolves to the ISP's rendition of the
    address's name and not the mail server's fully-qualified name.

    I just don't understand why I can do a trace route from end to end while I
    continuously get a Destination Unreachable using SMTP unless I run naked. It
    has to be something I have to open on the PIX, but I just don't know what it
    might be.
     
    MyndPhlyp, Dec 15, 2003
    #5
  6. In article <VyrDb.6754$>,
    MyndPhlyp <> wrote:
    :%PIX-6-302013: Built outbound TCP connection <###> for
    :eek:utside:<mailhostip/25> (mailhostip/25) to inside:<clientip/port>
    :(pixwanip/port)
    :%PIX-6-305011: Built dynamic TCP translation from inside:clientip/port to
    :eek:utside:pixwanip/port

    :The packets caught by Ethereal are (shorthand):

    :TCP/SMTP => outbound
    :ICMP Destination Unreachable
    :TCP/SMTP => outbound
    :ICMP Destination Unreachable
    :TCP/SMTP => outbound
    :ICMP Destination Unreachable

    Ah, but which IP is reporting the unreachable? It isn't the PIX itself --
    it would have logged an appropriate message in the log if you were
    hitting an ACL issue.

    The ethereal captures should show you the source IP of the unreachable.

    :I just don't understand why I can do a trace route from end to end while I
    :continuously get a Destination Unreachable using SMTP unless I run naked.

    If you are nat'd to an IP address that the remote system is set up to
    block at the mailer level..
    --
    Admit it -- you peeked ahead to find out how this message ends!
     
    Walter Roberson, Dec 16, 2003
    #6
  7. MyndPhlyp

    MyndPhlyp Guest

    "Rik Bain" <> wrote in message
    news:p...
    >
    > Can you post the contents of the ICMP packet?
    > Also, I doubt this is it but it bears mentioning, the SMTP server may do
    > an IDENT lookup for all connecting hosts. The pix will drop this packet
    > by default, causing connection delays/failures.


    I'll do even more than that. My apologies in advance for any text wrap.

    Just for grins, I added IDENT to the any:eek:utside => any:inside
    (outside_access_in) both with and without a fixup on SMTP. No effect - the
    symptom remains.

    ============================
    show configure (trimmed down)
    ============================

    interface ethernet0 auto
    interface ethernet1 100full
    nameif ethernet0 outside security0
    nameif ethernet1 inside security100
    fixup protocol ftp 21
    fixup protocol h323 h225 1720
    fixup protocol h323 ras 1718-1719
    fixup protocol http 80
    fixup protocol ils 389
    fixup protocol rsh 514
    fixup protocol rtsp 554
    fixup protocol sip 5060
    fixup protocol sip udp 5060
    fixup protocol skinny 2000
    fixup protocol smtp 25
    fixup protocol sqlnet 1521
    names
    object-group service basic_tcp tcp
    port-object eq ftp
    port-object eq pop3
    port-object eq nntp
    port-object eq domain
    port-object eq https
    port-object eq telnet
    port-object eq www
    port-object eq smtp
    port-object range 8085 8086
    port-object range 8081 8081
    port-object eq whois
    object-group service basic_udp udp
    port-object eq ntp
    port-object eq domain
    access-list acl_out permit tcp any any object-group basic_tcp
    access-list acl_out permit udp any any object-group basic_udp
    access-list acl_out permit icmp any any
    access-list outside_access_in permit icmp any any
    ip address outside pppoe setroute
    ip address inside xxx.xxx.xxx.xxx 255.255.255.0
    ip verify reverse-path interface outside
    ip verify reverse-path interface inside
    ip audit info action alarm
    ip audit attack action alarm
    arp timeout 14400
    global (outside) 1 interface
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    access-group outside_access_in in interface outside
    access-group acl_out in interface inside
    timeout xlate 0:05:00
    timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225
    1:00:00
    timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
    timeout uauth 0:05:00 absolute


    ============================
    ICMP Destination Unreachable
    ============================

    Frame 4 (70 bytes on wire, 70 bytes captured)
    Arrival Time: Dec 15, 2003 19:41:45.841685000
    Time delta from previous packet: 0.055925000 seconds
    Time since reference or first frame: 0.056192000 seconds
    Frame Number: 4
    Packet Length: 70 bytes
    Capture Length: 70 bytes
    Ethernet II, Src: [1st hop mac], Dst: [client mac]
    Destination: [client mac] ([client mac])
    Source: [1st hop mac] ([1st hop mac])
    Type: IP (0x0800)
    Internet Protocol, Src Addr: [1st hop ip] ([1st hop ip]), Dst Addr: [client
    ip] ([client ip])
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    0000 00.. = Differentiated Services Codepoint: Default (0x00)
    .... ..0. = ECN-Capable Transport (ECT): 0
    .... ...0 = ECN-CE: 0
    Total Length: 56
    Identification: 0x177e (6014)
    Flags: 0x00
    .0.. = Don't fragment: Not set
    ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 255
    Protocol: ICMP (0x01)
    Header checksum: 0x3f27 (correct)
    Source: [1st hop ip] ([1st hop ip])
    Destination: [client ip] ([client ip])
    Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 13 (Communication administratively filtered)
    Checksum: 0x62df (correct)
    Internet Protocol, Src Addr: [client ip] ([client ip]), Dst Addr: [mail
    host ip] ([mail host ip])
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    0000 00.. = Differentiated Services Codepoint: Default (0x00)
    .... ..0. = ECN-Capable Transport (ECT): 0
    .... ...0 = ECN-CE: 0
    Total Length: 48
    Identification: 0x177e (6014)
    Flags: 0x04
    .1.. = Don't fragment: Set
    ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0x7154 (correct)
    Source: [client ip] ([client ip])
    Destination: [mail host ip] ([mail host ip])
    Transmission Control Protocol, Src Port: 2068 (2068), Dst Port: smtp
    (25)
    Source port: 2068 (2068)
    Destination port: smtp (25)
     
    MyndPhlyp, Dec 16, 2003
    #7
  8. MyndPhlyp

    MyndPhlyp Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:brlmef$6o3$...
    >
    > Ah, but which IP is reporting the unreachable? It isn't the PIX itself --
    > it would have logged an appropriate message in the log if you were
    > hitting an ACL issue.
    >
    > The ethereal captures should show you the source IP of the unreachable.
    >
    > If you are nat'd to an IP address that the remote system is set up to
    > block at the mailer level..


    We seemed to have posted follow-ups at the same time. The more detailed
    Ethereal catch of the ICMP shows the 1st hop off the PIX reporting the
    destination is unreachable. And, I know the mail server isn't blocking
    anybody at the IP, domain or network level.
     
    MyndPhlyp, Dec 16, 2003
    #8
  9. MyndPhlyp

    Rik Bain Guest

    On Mon, 15 Dec 2003 19:17:08 -0600, MyndPhlyp wrote:


    > ============================
    > ICMP Destination Unreachable
    > ============================
    >
    > Frame 4 (70 bytes on wire, 70 bytes captured)
    > Arrival Time: Dec 15, 2003 19:41:45.841685000 Time delta from
    > previous packet: 0.055925000 seconds Time since reference or first
    > frame: 0.056192000 seconds Frame Number: 4 Packet Length: 70 bytes
    > Capture Length: 70 bytes
    > Ethernet II, Src: [1st hop mac], Dst: [client mac]
    > Destination: [client mac] ([client mac]) Source: [1st hop mac] ([1st
    > hop mac]) Type: IP (0x0800)
    > Internet Protocol, Src Addr: [1st hop ip] ([1st hop ip]), Dst Addr:
    > [client ip] ([client ip])
    > Version: 4
    > Header length: 20 bytes
    > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    > 0000 00.. = Differentiated Services Codepoint: Default (0x00)
    > .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0
    > Total Length: 56
    > Identification: 0x177e (6014)
    > Flags: 0x00
    > .0.. = Don't fragment: Not set
    > ..0. = More fragments: Not set
    > Fragment offset: 0
    > Time to live: 255
    > Protocol: ICMP (0x01)
    > Header checksum: 0x3f27 (correct)
    > Source: [1st hop ip] ([1st hop ip])
    > Destination: [client ip] ([client ip])
    > Internet Control Message Protocol
    > Type: 3 (Destination unreachable)
    > Code: 13 (Communication administratively filtered) Checksum: 0x62df
    > (correct)




    there is something blocking the traffic upstream.



    > Internet Protocol, Src Addr: [client ip] ([client ip]), Dst Addr:
    > [mail
    > host ip] ([mail host ip])
    > Version: 4
    > Header length: 20 bytes
    > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN:
    > 0x00)
    > 0000 00.. = Differentiated Services Codepoint: Default
    > (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0
    > = ECN-CE: 0
    > Total Length: 48
    > Identification: 0x177e (6014)
    > Flags: 0x04
    > .1.. = Don't fragment: Set
    > ..0. = More fragments: Not set
    > Fragment offset: 0
    > Time to live: 128
    > Protocol: TCP (0x06)
    > Header checksum: 0x7154 (correct)
    > Source: [client ip] ([client ip])
    > Destination: [mail host ip] ([mail host ip])
    > Transmission Control Protocol, Src Port: 2068 (2068), Dst Port: smtp
    > (25)
    > Source port: 2068 (2068)
    > Destination port: smtp (25)
     
    Rik Bain, Dec 16, 2003
    #9
  10. MyndPhlyp

    MyndPhlyp Guest

    "Rik Bain" <> wrote in message
    news:p...
    >
    > > Internet Control Message Protocol
    > > Type: 3 (Destination unreachable)
    > > Code: 13 (Communication administratively filtered) Checksum: 0x62df
    > > (correct)

    >
    >
    >
    > there is something blocking the traffic upstream.


    Yeppers. But the question is, "why?"

    I can ping and trace route out to the mail host. I can SMTP to other mail
    hosts. But not this particular mail host.
     
    MyndPhlyp, Dec 16, 2003
    #10
  11. MyndPhlyp

    MyndPhlyp Guest

    "Rik Bain" <> wrote in message
    news:p...
    > On Mon, 15 Dec 2003 19:17:08 -0600, MyndPhlyp wrote:
    >

    <... megasnip ...>

    Rik:

    I believe I figured it out, after a hair pulling session with Earthlink's
    (for lack of a better description) technical support. EL blocks outbound
    SMTP for everything that is not directed towards their mail servers. Simple
    enough. The bottom line is that an Earthlink user must use the Earthlink
    mail servers for outbound mail. Inbound (POP3) can be from anywhere, but
    outbound must stay with the ISP.

    That frosts my onions!
     
    MyndPhlyp, Dec 16, 2003
    #11
  12. MyndPhlyp

    KR Guest

    MyndPhlyp wrote:
    > "Rik Bain" <> wrote in message
    > news:p...
    >
    >>>Internet Control Message Protocol
    >>> Type: 3 (Destination unreachable)
    >>> Code: 13 (Communication administratively filtered) Checksum: 0x62df
    >>> (correct)

    >>
    >>
    >>
    >>there is something blocking the traffic upstream.

    >
    >
    > Yeppers. But the question is, "why?"
    >


    Just an idea...

    If you telnet to port 25 on this particular host, do you get a
    connection? My guess is "no". I had a similar problem with a mail server
    once. It seemed that Most people could send mail to this host, but I
    could not. At least not from behind a firewall (FW-1 in that particular
    case).

    Turned out that the firewall guys on the other end were blocking
    connections that didn't originate from port 25. NAT'ed and PAT'ed
    connections usually get the source port remapped to a (random) high
    port, and as a result, I couldn't connect. But I could connect from any
    host that was not behind a NAT/PAT firewall.
     
    KR, Dec 16, 2003
    #12
  13. MyndPhlyp

    MyndPhlyp Guest

    "KR" <> wrote in message
    news:...
    > MyndPhlyp wrote:
    > > "Rik Bain" <> wrote in message
    > > news:p...
    > >
    > >>>Internet Control Message Protocol
    > >>> Type: 3 (Destination unreachable)
    > >>> Code: 13 (Communication administratively filtered) Checksum: 0x62df
    > >>> (correct)
    > >>
    > >>
    > >>
    > >>there is something blocking the traffic upstream.

    > >
    > >
    > > Yeppers. But the question is, "why?"
    > >

    >
    > Just an idea...
    >
    > If you telnet to port 25 on this particular host, do you get a
    > connection? My guess is "no". I had a similar problem with a mail server
    > once. It seemed that Most people could send mail to this host, but I
    > could not. At least not from behind a firewall (FW-1 in that particular
    > case).
    >
    > Turned out that the firewall guys on the other end were blocking
    > connections that didn't originate from port 25. NAT'ed and PAT'ed
    > connections usually get the source port remapped to a (random) high
    > port, and as a result, I couldn't connect. But I could connect from any
    > host that was not behind a NAT/PAT firewall.


    That sounds like it might be my situation. Is there a way to configure the
    PIX 501 to not NAT/PAT an outbound SMTP?
     
    MyndPhlyp, Dec 16, 2003
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave
    Replies:
    0
    Views:
    1,666
  2. mh
    Replies:
    2
    Views:
    552
    Adrian Grigorof
    May 10, 2004
  3. Corbin O'Reilly
    Replies:
    2
    Views:
    3,250
    Corbin O'Reilly
    May 26, 2004
  4. Andre
    Replies:
    7
    Views:
    791
    Andre
    Feb 20, 2005
  5. Mac Hammer
    Replies:
    5
    Views:
    975
    Jyri Korhonen
    Jun 21, 2005
Loading...

Share This Page