PIX syslog messages

Discussion in 'Cisco' started by AM, Apr 6, 2005.

  1. AM

    AM Guest

    I'm trying to connect from a PC behind my Firewall to a 837 router on the Internet
    The router can accept only ssh connections and only from a particular subset of public IP addresses. It can not accept
    telnet connections. When trying to connect via telnet I obtain "Connection refused" and it is correct.
    But when trying to connect via ssh on the PIX syslog I see the following.

    Apr 6 11:59:08 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from <837 public IP>/7 to <PIX
    public IP>/1119 flags SYN ACK on interface Tunn_Estero_Endpoint
    Apr 6 11:59:11 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from <837 public IP>/7 to <PIX
    public IP>/1119 flags ACK on interface Tunn_Estero_Endpoint
    Apr 6 11:59:11 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from <837 public IP>/8 to <PIX
    public IP>/1119 flags SYN ACK on interface Tunn_Estero_Endpoint
    Apr 6 11:59:16 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from <837 public IP>/7 to <PIX
    public IP>/1119 flags ACK on interface Tunn_Estero_Endpoint
    Apr 6 11:59:16 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from <837 public IP>/8 to <PIX
    public IP>/1119 flags SYN ACK on interface Tunn_Estero_Endpoint
    Apr 6 11:59:22 fw-ts-itbs-area.italtbs.com %PIX-6-302014: Teardown TCP connection 12073769 for outside:<837 public
    IP>/22 to inside:192.168.31.157/1414 duration 0:02:01 bytes 0 SYN Timeout
    Apr 6 11:59:27 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from <837 public IP>/8 to <PIX
    public IP>/1119 flags SYN ACK on interface Tunn_Estero_Endpoint

    I think the problem is on the router but I would troubleshoot the problem seeing the syslog messages.

    May anyone help me? What do the messages mean? It seems to me the router can not connect to the PIX but I don't know why.

    Thanks,

    Alex
    AM, Apr 6, 2005
    #1
    1. Advertising

  2. In article <B5P4e.28723$>, AM <> wrote:
    :I'm trying to connect from a PC behind my Firewall to a 837 router on the Internet
    :The router can accept only ssh connections and only from a particular subset of public IP addresses. It can not accept
    :telnet connections. When trying to connect via telnet I obtain "Connection refused" and it is correct.
    :But when trying to connect via ssh on the PIX syslog I see the following.

    :Apr 6 11:59:08 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no connection) from <837 public IP>/7 to <PIX
    :public IP>/1119 flags SYN ACK on interface Tunn_Estero_Endpoint

    Looking at that list of errors, what it suggests to me is that the IP address you
    are attempting to ssh to may not be the same as the IP address that is replying. If true,
    then the PIX is not going to recognize the packet as being a reply packet and will
    drop it with log messages such as you are seeing.

    Notice you indicate <837 public IP> -- if you are ssh'ing to the 837 from "inside" the 837
    then you would expect it to be the -private- IP that replied.

    If I recall correctly, there are ways in IOS to control which IP is used for some
    of the traffic from the device (837) itself; I do not recall the details at the
    moment.
    --
    Feep if you love VT-52's.
    Walter Roberson, Apr 6, 2005
    #2
    1. Advertising

  3. AM

    AM Guest

    Walter Roberson wrote:


    > Looking at that list of errors, what it suggests to me is that the IP address you
    > are attempting to ssh to may not be the same as the IP address that is replying. If true,
    > then the PIX is not going to recognize the packet as being a reply packet and will
    > drop it with log messages such as you are seeing.
    >
    > Notice you indicate <837 public IP> -- if you are ssh'ing to the 837 from "inside" the 837
    > then you would expect it to be the -private- IP that replied.
    >
    > If I recall correctly, there are ways in IOS to control which IP is used for some
    > of the traffic from the device (837) itself; I do not recall the details at the
    > moment.


    192.168.23.x <-->[PIX] (PIX public IP) <--->Internet cloud<---> (837 public IP)[837]

    the command given from 192.168.23.x is ssh -l <username> (837 public IP)

    Alex.

    Anyway I will have a look about settings of ssh server, thanks
    AM, Apr 6, 2005
    #3
  4. AM

    AM Guest

    Walter Roberson wrote:


    > Looking at that list of errors, what it suggests to me is that the IP address you
    > are attempting to ssh to may not be the same as the IP address that is replying. If true,
    > then the PIX is not going to recognize the packet as being a reply packet and will
    > drop it with log messages such as you are seeing.
    >
    > Notice you indicate <837 public IP> -- if you are ssh'ing to the 837 from "inside" the 837
    > then you would expect it to be the -private- IP that replied.
    >
    > If I recall correctly, there are ways in IOS to control which IP is used for some
    > of the traffic from the device (837) itself; I do not recall the details at the
    > moment.


    192.168.23.x <-->[PIX] (PIX public IP) <--->Internet cloud<---> (837 public IP)[837]

    the command given from 192.168.23.x is ssh -l <username> (837 public IP)

    Alex.

    Anyway I will have a look about settings of ssh server
    It is strange 837 uses a very low port to initiate connections
    ....
    <837 public IP>/7
    ....

    instead of those above 1023.

    Alex.
    AM, Apr 6, 2005
    #4
  5. AM

    Tosh Guest

    > Apr 6 11:59:08 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no
    > connection) from <837 public IP>/7 to <PIX public IP>/1119 flags SYN ACK
    > on interface Tunn_Estero_Endpoint


    That's tcp echo, it's usually used by global load balancers as one way to
    find the closest server to serve the connection, looking on the timestamp
    informations in the tcp header of your replies.
    Don't know why your 837 it's behaving like that, maybe you have turned on
    some strange feature on the router.
    Beside that, are your ssh connection attempts actually succeding or failing?
    Bye,
    Tosh.
    Tosh, Apr 7, 2005
    #5
  6. AM

    AM Guest

    Tosh wrote:

    >>Apr 6 11:59:08 fw-ts-itbs-area.italtbs.com %PIX-6-106015: Deny TCP (no
    >>connection) from <837 public IP>/7 to <PIX public IP>/1119 flags SYN ACK
    >>on interface Tunn_Estero_Endpoint

    >
    >
    > That's tcp echo, it's usually used by global load balancers as one way to
    > find the closest server to serve the connection, looking on the timestamp
    > informations in the tcp header of your replies.
    > Don't know why your 837 it's behaving like that, maybe you have turned on
    > some strange feature on the router.
    > Beside that, are your ssh connection attempts actually succeding or failing?
    > Bye,
    > Tosh.
    >
    >


    Ciao Tosh,

    the attempts fail each time. The client returns "Connection time out". SSH connections from LAN side are always
    successful. I don't know whether the problem is on ATM side configuration or on SSH server. I will wipe the config,
    change the IOS to any version and ten reload the current and write from the scratch and by hand the current
    configuration. But if you have another solution I will appreciate it.

    A presto,
    Alex.
    AM, Apr 7, 2005
    #6
  7. AM

    Tosh Guest

    > the attempts fail each time. The client returns "Connection time out". SSH
    > connections from LAN side are always successful. I don't know whether the
    > problem is on ATM side configuration or on SSH server. I will wipe the
    > config, change the IOS to any version and ten reload the current and write
    > from the scratch and by hand the current configuration. But if you have
    > another solution I will appreciate it.
    >


    Funny, two Italian guys talking english to each other about an issue that
    probably the rest of the world doesn't care of.
    This is a good exemple of technology that doesn't always shorten roads.
    Anyway, back to your problem, I'm not aware of any ios feature that uses tcp
    echo, so I can only support your plan to refresh the config getting rid of
    all the exotic commands you may find into.
    A final thought, are you sure you are sshing to the right device? Maybe your
    ssh is intercepted by some nat or policy routing or balancer or whoknows
    device in between.
    Bye,
    Tosh.
    Tosh, Apr 8, 2005
    #7
  8. In article <MJU4e.29736$>, AM <> wrote:
    :Anyway I will have a look about settings of ssh server
    :It is strange 837 uses a very low port to initiate connections

    :<837 public IP>/7

    But the 837 isn't initiating the connection -- the PIX is.
    The 837 is the one replying.

    The port 7 and port 8 references in the logs suggest to me that the 837
    is NAT'ing the reply back to you. The port 7 and 8 responses are not
    going to match the port 22 that the PIX is expecting the response on
    so the PIX isn't going to know it as the same connection.

    The question then becomes "Why is the reply back NAT'd" ?
    That would have to depend on the setup of the 837 NAT, and on
    whether the 837 has the firewall feature set or is using reflexive
    ACLs. The 837 "should" know to exempt replies from NAT, but
    if it is not using FFS or reflexive ACLs then maybe it doesn't know
    that and is blindly using a rule that NAT's all outgoing traffic
    including traffic from the 837 public IP.
    --
    "Who Leads?" / "The men who must... driven men, compelled men."
    "Freak men."
    "You're all freaks, sir. But you always have been freaks.
    Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD
    Walter Roberson, Apr 9, 2005
    #8
  9. On Fri, 08 Apr 2005 23:46:55 +0000, Walter Roberson wrote:

    > The question then becomes "Why is the reply back NAT'd" ? That would have
    > to depend on the setup of the 837 NAT, and on whether the 837 has the
    > firewall feature set or is using reflexive ACLs. The 837 "should" know to
    > exempt replies from NAT, but if it is not using FFS or reflexive ACLs then
    > maybe it doesn't know that and is blindly using a rule that NAT's all
    > outgoing traffic including traffic from the 837 public IP.


    Very easy to do this by using "permit any" in your NAT ACL. Makes it
    impossible to telnet, or in this case ssh, into the NAT outside interface.

    The reason this happens is that NAT is applied to traffic crossing the
    router from inside to outside, *and* to local traffic from the router.

    So people configure their NAT to monkey with the addresses in whatever
    way it likes, and then act surprised when it does.

    --
    Rgds,
    Martin
    Martin Gallagher, Apr 9, 2005
    #9
  10. AM

    Tosh Guest

    > Very easy to do this by using "permit any" in your NAT ACL. Makes it
    > impossible to telnet, or in this case ssh, into the NAT outside interface.
    >
    > The reason this happens is that NAT is applied to traffic crossing the
    > router from inside to outside, *and* to local traffic from the router.
    >

    I agree with you that a "permit any" in the nat acl is bad practice, but I
    also remember you that in order to get natted the traffic has to traverse
    both a "nat inside" and a "nat outside" interface and local traffic should
    not do that, at least when you access the outside interface from the
    outside.
    To say all, I think that should (not must) be the case in which the op
    configured a static nat with the outside interface of the router as the
    "inside global", which is a completely different issue, although nat
    related.
    This way the ssh to the outside interface will be directed, say, to a
    windows machine that doesn't know how to handle it.
    Bye,
    Tosh.
    Tosh, Apr 10, 2005
    #10
  11. On Sun, 10 Apr 2005 10:15:21 +0200, Tosh wrote:


    > I agree with you that a "permit any" in the nat acl is bad practice, but I
    > also remember you that in order to get natted the traffic has to traverse
    > both a "nat inside" and a "nat outside" interface and local traffic should
    > not do that, at least when you access the outside interface from the
    > outside.


    Nope, local traffic from the router will be natted if it matches the NAT
    ACL. I've seen it happen many times.

    --
    Rgds,
    Martin
    Martin Gallagher, Apr 10, 2005
    #11
  12. AM

    Tosh Guest

    > Nope, local traffic from the router will be natted if it matches the NAT
    > ACL. I've seen it happen many times.
    >

    I'm not following you, perhaps we are talking about two different issues,
    it'll be very helpful if you can do an example with some piece of config.
    Maybe it's time the op tells us if he solved and how, just in respect of who
    tried to help him.
    Bye,
    Max.
    Tosh, Apr 11, 2005
    #12
  13. AM

    Tosh Guest

    > Nope, local traffic from the router will be natted if it matches the NAT
    > ACL. I've seen it happen many times.
    >

    I'm not following you, perhaps we are talking about two different issues,
    it'll be very helpful if you can do an example with some piece of config.
    Maybe it's time the op tells us if he solved and how, just in respect of who
    tried to help him.
    Bye,
    Max.
    Tosh, Apr 11, 2005
    #13
  14. AM

    Tosh Guest

    > Nope, local traffic from the router will be natted if it matches the NAT
    > ACL. I've seen it happen many times.
    >

    I'm not following you, perhaps we are talking about two different issues,
    it'll be very helpful if you can do an example with some piece of config.
    Maybe it's time the op tells us if he solved and how, just in respect of who
    tried to help him.
    Bye,
    Tosh.
    Tosh, Apr 11, 2005
    #14
  15. AM

    Tosh Guest

    > Nope, local traffic from the router will be natted if it matches the NAT
    > ACL. I've seen it happen many times.
    >

    I'm not following you, perhaps we are talking about two different issues,
    it'll be very helpful if you can do an example with some piece of config.
    Maybe it's time the op tells us if he solved and how, just in respect of who
    tried to help him.
    Bye,
    Tosh.
    Tosh, Apr 11, 2005
    #15
  16. On Mon, 11 Apr 2005 06:20:50 +0200, Tosh wrote:

    > I'm not following you, perhaps we are talking about two different
    > issues, it'll be very helpful if you can do an example with some piece
    > of config. Maybe it's time the op tells us if he solved and how, just in
    > respect of who tried to help him.


    !
    interface Ethernet0
    ip address 192.168.25.254 255.255.255.0 ip nat inside
    !
    interface Serial0/0
    ip address 172.16.27.2 255.255.255.252 ip nat outside
    !
    ip nat inside source list 1 interface Serial0/0 overload ip route 0.0.0.0
    0.0.0.0 Serial0/0
    !
    access-list 1 permit any
    !

    Try and telnet to 172.16.27.2; times out.

    Remove "ip nat outside" from S0/0 or change access list 1 to "permit
    192.168.25.0 0.0.0.255" and telnet to 172.16.27.2 will succeed.

    --
    Rgds,
    Martin
    Martin Gallagher, Apr 12, 2005
    #16
  17. AM

    Tosh Guest

    > Remove "ip nat outside" from S0/0 or change access list 1 to "permit
    > 192.168.25.0 0.0.0.255" and telnet to 172.16.27.2 will succeed.
    >

    In my knowledge this is not normal, thats not the same to say you are wrong,
    simply has to be a bug or something.
    With nat overload (or pat) ios maintains a table of all the dynamic
    translations created absolutely only when traffic flows from the inside to
    the outside and they have port numbers higher than 1024 appearing on the
    outside, I'd like to know what the hell an ssh from the outside has to do
    with that.
    Bye,
    Tosh.
    Tosh, Apr 12, 2005
    #17
    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. mikester

    Syslog messages repeated

    mikester, Dec 3, 2003, in forum: Cisco
    Replies:
    2
    Views:
    8,422
    mikester
    Dec 4, 2003
  2. Replies:
    4
    Views:
    1,225
  3. Christian Knoblauch

    Syslog messages

    Christian Knoblauch, Feb 9, 2004, in forum: Cisco
    Replies:
    5
    Views:
    957
    Martin Gallagher
    Feb 12, 2004
  4. Lasani

    Syslog messages from PIX 515

    Lasani, Aug 13, 2004, in forum: Cisco
    Replies:
    1
    Views:
    4,271
    Pe5kyTac0
    Aug 15, 2004
  5. tobi
    Replies:
    7
    Views:
    4,022
    Walter Roberson
    May 6, 2005
Loading...

Share This Page