permit same-security-traffic

Discussion in 'Cisco' started by aleu@op.pl, Mar 29, 2009.

  1. Guest

    I have found on the internet an article which describes how to enable
    traffic to enter and exit the same interface. The command is

    hostname(config)# same-security-traffic permit intra-interface

    I have four follow up questions:
    1. Why is this disabled by default on the Cisco ASA?
    2. What is the danger of enabling it?
    3. Is it disabled by default on the PIX firewalls as well?
    4. Is there a way to enable this behavior only on a specific interface
    or is this a global setting for all physical interfaces?

    Thank you.

    Regards,
    AL
    , Mar 29, 2009
    #1
    1. Advertising

  2. bod43 Guest

    On 29 Mar, 19:21, "" <> wrote:
    > I have found on the internet an article which describes how to enable
    > traffic to enter and exit the same interface. The command is
    >
    > hostname(config)# same-security-traffic permit intra-interface
    >
    > I have four follow up questions:
    > 1. Why is this disabled by default on the Cisco ASA?

    The entire basis of the pix is to deny everything unless
    specifically permitted. It's what the old Pix did.

    > 3. Is it disabled by default on the PIX firewalls as well?

    Yes. Prior to 7.0 Pix, it was not possible to enable this
    at all.
    bod43, Mar 29, 2009
    #2
    1. Advertising

  3. Guest

    bod43 wrote:
    >> 1. Why is this disabled by default on the Cisco ASA?

    > The entire basis of the pix is to deny everything unless
    > specifically permitted. It's what the old Pix did.
    >
    >> 3. Is it disabled by default on the PIX firewalls as well?

    > Yes. Prior to 7.0 Pix, it was not possible to enable this
    > at all.


    Thank you for your feedback. Is there any danger of enabling this on the
    firewall? From your response, I judge that there is no way to enable
    this only on a specific interface, but needs to be enabled globally?

    AL
    , Mar 30, 2009
    #3
  4. bod43 Guest

    On 30 Mar, 00:53, "" <> wrote:
    > bod43 wrote:
    > >> 1. Why is this disabled by default on the Cisco ASA?

    > > The entire basis of the pix is to deny everything unless
    > > specifically permitted. It's what the old Pix did.

    >
    > >> 3. Is it disabled by default on the PIX firewalls as well?

    > > Yes. Prior to 7.0 Pix, it was not possible to enable this
    > > at all.

    >
    > Thank you for your feedback. Is there any danger of enabling this on the
    > firewall? From your response, I judge that there is no way to enable
    > this only on a specific interface, but needs to be enabled globally?


    I can't answer further since I don't really know much about
    the pix. I do know that Checkpoint for example make virtually
    no distinction regarding interfaces. The security rules are
    applied irrespective of the interface that traffic arrives on
    or departs from. You do have to specify an "external" interface
    but it is not used (I am reasonably sure:) for the security
    rules. (NAT maybe, licensing definately - hosts on Internal
    interfaces are counted.)

    So - there is nothing inherently bad about same interface traffic
    that I can think of.
    bod43, Mar 30, 2009
    #4
  5. Guest

    Tosh wrote:
    > Afaik that command enables the so called feature "vpn hairpinning" that is
    > the chance for different vpn tunnels terminated on the same interface to
    > talk to each other.
    > As long as you don't have any vpn's terminated on an interface that comand
    > doesn't have any effect on the interface itself.
    > Even on interfaces with vpn's terminated on it the command doesn't do
    > nothing until you properly configure the crypto acl's.
    > Unless I miss something...


    Let me explain what I am trying to accomplish. I have a mail server (A)
    which resides on one interface of my firewall. Mail server's default
    gateway is the firewall. There is a MX record (another SMTP server -
    call it B) that resides on the same interface of the firewall (different
    IP address of course). Sometimes my mail server (A) needs to send emails
    to MX record of mail server B. The packets are being sent to the
    firewall (default gateway of server A), but are not routed back to
    server B. I am not sure whether lack of "same-security-traffic permit
    intra-interface" is causing it, but it looks like it it. Can you please
    confirm whether I am on the right track?

    Thanks,
    AL
    , Mar 31, 2009
    #5
  6. wrote:
    > Tosh wrote:
    >> Afaik that command enables the so called feature "vpn hairpinning"
    >> that is the chance for different vpn tunnels terminated on the same
    >> interface to talk to each other.
    >> As long as you don't have any vpn's terminated on an interface that
    >> comand doesn't have any effect on the interface itself.
    >> Even on interfaces with vpn's terminated on it the command doesn't do
    >> nothing until you properly configure the crypto acl's.
    >> Unless I miss something...

    >
    > Let me explain what I am trying to accomplish. I have a mail server (A)
    > which resides on one interface of my firewall. Mail server's default
    > gateway is the firewall. There is a MX record (another SMTP server -
    > call it B) that resides on the same interface of the firewall (different
    > IP address of course). Sometimes my mail server (A) needs to send emails
    > to MX record of mail server B. The packets are being sent to the
    > firewall (default gateway of server A), but are not routed back to
    > server B. I am not sure whether lack of "same-security-traffic permit
    > intra-interface" is causing it, but it looks like it it. Can you please
    > confirm whether I am on the right track?


    Probably not. Chances are server A is trying to reach public IP of
    server B. You can do two things -

    1. Enable DNS doctoring -

    http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml

    2. Make sure resolver on server A is using hosts file besides DNS
    servers and put a mapping between server B name (as listed in MX record)
    and internal IP.

    Regards,
    Andrey.
    Andrey Tarasov, Mar 31, 2009
    #6
  7. Guest

    Andrey Tarasov wrote:
    > Probably not. Chances are server A is trying to reach public IP of
    > server B.


    Not sure what you mean. Server A is trying to access server B via its MX
    record which resides in the DMZ. That I am sure. So what is preventing
    it from accessing it?
    A packet needs to leave server A via its DMZ IP address then hits the
    firewall and should come back via the same firewall's interface to reach
    DMZ IP of server B. However, the packet never reaches server B. I
    thought that the line in my original post will allow it as it seems to
    be disabled by default by the firewall.


    Thanks,
    AL
    , Mar 31, 2009
    #7
  8. wrote:
    > Andrey Tarasov wrote:
    >> Probably not. Chances are server A is trying to reach public IP of
    >> server B.

    >
    > Not sure what you mean. Server A is trying to access server B via its MX
    > record which resides in the DMZ. That I am sure. So what is preventing
    > it from accessing it?
    > A packet needs to leave server A via its DMZ IP address then hits the
    > firewall and should come back via the same firewall's interface to reach
    > DMZ IP of server B. However, the packet never reaches server B. I
    > thought that the line in my original post will allow it as it seems to
    > be disabled by default by the firewall.


    Is firewall doing NAT for those servers? How name resolution is done?

    Most common scenario which causes problem you described - NAT is in
    place, name resolution is done via externally hosted DNS server. In that
    case when server A queries DNS for MX record, it gets external IP of
    server B in reply. It tries to establish a connection via firewall
    (since it's default gateway) and firewall drops SYN packet because it
    can't NAT it properly. Permit same-security-traffic is not going to
    help. How to check if that is the case - look for log/syslog entries
    with DMZ IP of server A and public IP of server B (could be names if you
    use them in configuration)

    Regards,
    Andrey.
    Andrey Tarasov, Mar 31, 2009
    #8
  9. Guest

    Andrey Tarasov wrote:
    > Most common scenario which causes problem you described - NAT is in
    > place, name resolution is done via externally hosted DNS server. In that
    > case when server A queries DNS for MX record, it gets external IP of
    > server B in reply. It tries to establish a connection via firewall
    > (since it's default gateway) and firewall drops SYN packet because it
    > can't NAT it properly. Permit same-security-traffic is not going to
    > help. How to check if that is the case - look for log/syslog entries
    > with DMZ IP of server A and public IP of server B (could be names if you
    > use them in configuration)


    Andrey,

    Thanks for the thorough explanation. I think that this can be the case
    then.
    Is there a quick way to "grep" through the log messages stored on the
    firewall? I have logging enabled and messages are being sent to the
    buffer, but I am not sure whether there is something similar to tcpdump
    on a cisco firewall (which would allow me to specify both hosts and
    watch the traffic in real time displaying only the events that I am
    interested in).

    Regards,
    AL
    , Apr 1, 2009
    #9
  10. wrote:
    > Andrey Tarasov wrote:
    >> Most common scenario which causes problem you described - NAT is in
    >> place, name resolution is done via externally hosted DNS server. In
    >> that case when server A queries DNS for MX record, it gets external IP
    >> of server B in reply. It tries to establish a connection via firewall
    >> (since it's default gateway) and firewall drops SYN packet because it
    >> can't NAT it properly. Permit same-security-traffic is not going to
    >> help. How to check if that is the case - look for log/syslog entries
    >> with DMZ IP of server A and public IP of server B (could be names if
    >> you use them in configuration)

    >
    > Andrey,
    >
    > Thanks for the thorough explanation. I think that this can be the case
    > then.
    > Is there a quick way to "grep" through the log messages stored on the
    > firewall? I have logging enabled and messages are being sent to the
    > buffer, but I am not sure whether there is something similar to tcpdump
    > on a cisco firewall (which would allow me to specify both hosts and
    > watch the traffic in real time displaying only the events that I am
    > interested in).


    As a matter of fact - both grep and tcpdump are available. Here is the
    description of filters for "show" commands -

    http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/cli.html#wp1046322

    (version 7 has a few less options, but similar)

    For tcpdump you need to check "capture" command.

    Regards,
    Andrey.
    Andrey Tarasov, Apr 1, 2009
    #10
  11. Guest

    , Apr 2, 2009
    #11
    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. Replies:
    3
    Views:
    1,448
    Walter Roberson
    Mar 1, 2005
  2. Diego Fernández

    Permit web traffic by user

    Diego Fernández, Mar 14, 2006, in forum: Cisco
    Replies:
    1
    Views:
    396
    Walter Roberson
    Mar 14, 2006
  3. PIXn00b
    Replies:
    0
    Views:
    2,110
    PIXn00b
    Nov 7, 2006
  4. Mike Rahl
    Replies:
    6
    Views:
    2,317
    Walter Roberson
    Dec 12, 2006
  5. Replies:
    3
    Views:
    5,500
    Walter Roberson
    Jan 5, 2007
Loading...

Share This Page