Solved

Does same-security-traffic require an access-list?

Posted on 2008-10-22
19
2,770 Views
Last Modified: 2012-05-05
I have my AS configured with one 'outside' interface and three 'inside' interfaces, at security-level 0 and 100, respectively.  The in1/2/3->outside traffic can pass without an explicit access-list.  Outside->in1/2/3 traffic needs both an access-list and relevant statics.  This is as expected.

However, if I need one of the inside interfaces to talk to another, I either need to change the security-levels, or use same-security-traffic permit.  If I do the latter, which security model applies (i.e. will I have to explicitly permit the relevant in1->in2 traffic via access-list)?
0
Comment
Question by:jimbobmcgee
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 10
  • 6
  • 3
19 Comments
 
LVL 57

Assisted Solution

by:Pete Long
Pete Long earned 100 total points
ID: 22775261
to get traffic from a lower security interface to a higher security interface (i.e from a DMZ to the inside) you need 2 things

1 A translation (either static NAT or a global and matching NAT statement)
2. An ACL allowing the traffic
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22775422
Agreed.

But to get between two interfaces with the same security, using the 'same-security-traffic' keyword, is traffic implicity allowed (as per higher-to-lower) or implicitly denied (as per lower-to-higher)?
0
 
LVL 57

Expert Comment

by:Pete Long
ID: 22775765
Then you should not - if you had to, VPN hairpinning would not work
0
Now Available: Firebox Cloud for AWS and FireboxV

Firebox Cloud brings the protection of WatchGuard’s leading Firebox UTM appliances to public cloud environments. It enables organizations to extend their security perimeter to protect business-critical assets in Amazon Web Services (AWS).

 
LVL 32

Expert Comment

by:harbor235
ID: 22776591

You need this command "same-security-traffic permit inter-interface" to get traffic to flow between interfaces with the same security levels. Default behavior is not to allow the traffic through unless the command above is used.

harbor235 ;}
0
 
LVL 32

Accepted Solution

by:
harbor235 earned 400 total points
ID: 22776645
"But to get between two interfaces with the same security, using the 'same-security-traffic' keyword, is traffic implicity allowed (as per higher-to-lower) or implicitly denied (as per lower-to-higher)?"

Using "same-security-traffic permit inter-interface" traffic is implicitly allowed, without it traffic is implictily denied.

http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/s1_72.html#wp1289167

harbor235 ;}
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22776655
Can you clarify on this a bit; what is/why should I care about VPN hairpinning?

Maybe some background will help (although, it is long, so will probably just scare you off):

I have three clients (A/B/C) in a rack sharing internet bandwidth provided by a single cable from the data-centre's core kit.  The client environments should not be able to see each other.

Rather than spending the money on three separate firewalls for these clients and some core kit 9i.e. router) to split the traffic, my company elected to bang them all on one ASA and give them each an interface with security-level 100 and a separate LAN range.  

All was well until client A decided that they needed to talk to client B.  Client A gave them the public IP addess and client B can't connect.  This is obviously because of the way the ASA deliberately prevents traffic going out and back in the 'outside' interface.

As such, if the two clients are to interact, they will have to do so directly via the LAN addresses.  This is acceptable to both, under the proviso that only traffic for this service (i.e. port) is allowed and that client C is still not able to see the other two.

I can't lower the security-level for client B, because client C would definitely be able to see client B.

This leads to why I am asking.  The 'same-security-traffic' option could allow traffic to pass across client A, B and C's interfaces.  My question is can I expect the ASA to prevent this traffic by default and have to allow A<->B traffic (preffered), or will I have to explicity deny C<->A and C<->B traffic?
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22776721
>> Using "same-security-traffic permit inter-interface" traffic is implicitly allowed, without it traffic is implictily denied.Using "same-security-traffic permit inter-interface" traffic is implicitly allowed, without it traffic is implictily denied.

Thanks, harbor235.

As such, am I going about this the wrong way?  Can I just apply an access-list to allow traffic between two security-level 100 interfaces, without 'same-security-traffic'?
0
 
LVL 57

Expert Comment

by:Pete Long
ID: 22776793
>> Can I just apply an access-list to allow traffic between two security-level 100 interfaces, without 'same-security-traffic'?

No its a throwback same value used to mean traffic wil NOT flow

>>what is/why should I care about VPN hairpinning?

sorry you shouldn't that was my fault for clouding the water, I was using the other use for the same command, to demonstrate an ACL was not needed :)
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22776864
So if I am going to achieve what I need to, I need to enable 'same-security-traffic' and add an access-list to explicitly deny A/B<->C...?
0
 
LVL 32

Expert Comment

by:harbor235
ID: 22777565

Correct, easy enough especially if its to deny all traffic from A -> C etc ....

harbor235 ;}
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22779293
I have now tried it with 'same-security-traffic permit inter-interface' and I still couldn't connect from client B to client A (using client A's server's LAN IP address) -- it just times out.

To date, I have tried it three ways:
  • 'same-security-traffic' not set, security-levels equal - times out (expected)
  • 'same-security-traffic' set, security-levels equal - times out (not expected)
  • 'same-security-traffic' not set, client A security-level lower - connection refused (not expected)
The connection refused event was instant, and 'portmap translation creation failed for tcp src in1:CLIENT_B_SERVER_IP/52533 dst in2:CLIENT_A_SERVER_IP/22' was shown in my syslog.

Might I be missing an access-list, access-group, static, route or something?

(I have upped the points to suit the increased complexity)
0
 
LVL 32

Assisted Solution

by:harbor235
harbor235 earned 400 total points
ID: 22779358

Translation implies NAT, If you are also doing NAT then you must make sure you have nonat rules specifiying that traffic from in1 to in2 and in2 to in1 does not get nat'd. Your NAT config is wrong, can you post your santized config

harbor235 ;}
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22794862
That looks like it's got it!!  I lowered the security-level for the target and added the source/target IPs to the nat0 access-lists for both interfaces and I got a connection.

Does that therefore mean that if I refrain from adding client C to the relevant nat0 lists, they will never be able to see the lower-security interface -- thus solving my problem?

J.
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22796268
Actually, it's not 100% right -- it's passable, for now.  I have added the two entries to their respective nat0 lists, using a 'permit tcp ... eq 22' statement (the relevant configs lines are below), but the nat0 doesn't appear to honour the 'eq 22' part, I can query all ports on either server.

Does nat0 not work at the port level?

interface Ethernet0/0
 speed 100
 duplex full
 nameif out0
 security-level 0
 ip address SITE_WAN_IP 255.255.255.248 
!
interface Ethernet0/1
 speed 100
 duplex full
 nameif in0
 security-level 100
 ip address CLIENT_C_GATEWAY_LAN_IP 255.255.255.0 
!
interface Ethernet0/2
 speed 100
 duplex full
 nameif in1
 security-level 100
 ip address CLIENT_A_GATEWAY_LAN_IP 255.255.255.0 
!
interface Ethernet0/3
 speed 100
 duplex full
 nameif in2
 security-level 100
 ip address CLIENT_B_GATEWAY_LAN_IP 255.255.255.0 
!
 
same-security-traffic permit inter-interface
 
access-list in1_nat0_outbound extended permit tcp host CLIENT_A_SERVER_LAN_IP eq ssh host CLIENT_B_SERVER_LAN_IP eq ssh 
access-list in1_nat0_outbound remark ^^^ Workaround to allow Client B to upload to Client A SFTP
access-list in2_nat0_outbound extended permit tcp host CLIENT_B_SERVER_LAN_IP eq ssh host CLIENT_A_SERVER_LAN_IP eq ssh 
access-list in2_nat0_outbound remark ^^^ Workaround to allow Client B to upload to Client A SFTP
 
nat (in0) 0 access-list in0_nat0_outbound
nat (in0) 10 0.0.0.0 0.0.0.0
nat (in1) 0 access-list in1_nat0_outbound
nat (in1) 10 0.0.0.0 0.0.0.0
nat (in2) 0 access-list in2_nat0_outbound
nat (in2) 10 0.0.0.0 0.0.0.0

Open in new window

0
 
LVL 32

Expert Comment

by:harbor235
ID: 22803252


nat0 is for defining what traffic does not get nat'd only, What are the ip networks for the internal interfaces?

Add the identity nat for the IPs as well;
static (in1,in2) 10.0.0.x 10.0.0.x netmask 255.255.255.255   (x = ip of clientA_server)


harbor235 ;}
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22816138
>> What are the ip networks for the internal interfaces?
Consider them 172.17.a.0/24, 172.17.b.0/24 and 172.17.c.0/24

>> Add the identity nat for the IPs as well;
What does the 'identity' NAT achieve?  172.17.a.123 will not exist behind the 172.17.b.123 interface.

To clarify the requirement:
I only want client B's server to be able to connect to an SFTP server on client A's server and receive the necessary replies.  I don't want any of client B's other servers to connect to any other server behind client A's interface, nor any of client B's servers to any other service on client A's SFTP server.  I don't want client A's server(s) to be able to connect to client B's server.  I don't want client C to connect to (or be connected to from) client A or B.

J.
0
 
LVL 32

Expert Comment

by:harbor235
ID: 22817215


Can you post your config? the question has changed

harbor235 ;}
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 22825962
You're right, I have gone off on a tanget somewhat.  As such, please find a suitable continuation question http:Q_23855765.html.

I will close off and assign for this one...

J.
0
 
LVL 16

Author Closing Comment

by:jimbobmcgee
ID: 31508689
Continued at http:Q_23855765.html to suit the additional requirements of the question
0

Featured Post

Surfing Is Meant To Be Done Outdoors

Featuring its rugged IP67 compliant exterior and delivering broad, fast, and reliable Wi-Fi coverage, the AP322 is the ideal solution for the outdoors. Manage this AP with either a Firebox as a gateway controller, or with the Wi-Fi Cloud for an expanded set of management features

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Use of TCL script on Cisco devices:  - create file and merge it with running configuration to apply configuration changes
For months I had no idea how to 'discover' the IP address of the other end of a link (without asking someone who knows), and it drove me batty. Think about it. You can't use Cisco Discovery Protocol (CDP) because it's not implemented on the ASAs.…
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…

696 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question