Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > permit same-security-traffic

Reply
Thread Tools

permit same-security-traffic

 
 
aleu@op.pl
Guest
Posts: n/a
 
      03-29-2009
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
 
Reply With Quote
 
 
 
 
bod43
Guest
Posts: n/a
 
      03-29-2009
On 29 Mar, 19:21, "(E-Mail Removed)" <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
 
aleu@op.pl
Guest
Posts: n/a
 
      03-29-2009
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
 
Reply With Quote
 
bod43
Guest
Posts: n/a
 
      03-30-2009
On 30 Mar, 00:53, "(E-Mail Removed)" <(E-Mail Removed)> 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.


 
Reply With Quote
 
aleu@op.pl
Guest
Posts: n/a
 
      03-31-2009
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
 
Reply With Quote
 
Andrey Tarasov
Guest
Posts: n/a
 
      03-31-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) 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/...807968d1.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.
 
Reply With Quote
 
aleu@op.pl
Guest
Posts: n/a
 
      03-31-2009
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
 
Reply With Quote
 
Andrey Tarasov
Guest
Posts: n/a
 
      03-31-2009
(E-Mail Removed) 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.
 
Reply With Quote
 
aleu@op.pl
Guest
Posts: n/a
 
      04-01-2009
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
 
Reply With Quote
 
Andrey Tarasov
Guest
Posts: n/a
 
      04-01-2009
(E-Mail Removed) 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/secu...html#wp1046322

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

For tcpdump you need to check "capture" command.

Regards,
Andrey.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How do I permit users to share wireless connection? =?Utf-8?B?U3RhckNoaWxk?= Wireless Networking 1 01-12-2005 02:55 AM
remove sysopt connection permit-ipsec on my PIX? You May Know Who Cisco 5 11-10-2004 04:40 AM
Permit VPN in my router Babe meneses Cisco 0 01-26-2004 06:16 PM
Permit Established ? does it work? Graeme Cisco 11 12-20-2003 05:19 AM
permit only outbound icmp requests and inbound replies, deny other Mark Matheney Cisco 1 12-10-2003 02:00 PM



Advertisments