Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

Continuation of Q_23836442

Posted on 2008-10-28
4
Medium Priority
?
478 Views
Last Modified: 2012-08-13
This is a continuation of the question started at http:Q_23836442.html.  As was rightly pointed out, the nature of the question has changed and so I am closing that one and starting this one.

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.

I've managed to get it as far as allowing all traffic from client B's server to client A's SFTP server, but I can't yet limit it to TCP port 22 traffic only.

Given my ASA running config (abstract below), what should I apply to allow only client B to connect to client A and only for port 22 (SSH)?

J.
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_SFTP_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
 
static (in2,out0) tcp CLIENT_A_WAN_IP www CLIENT_A_WEB_SERVER_LAN_IP www netmask 255.255.255.255 
static (in2,out0) tcp CLIENT_A_WAN_IP https CLIENT_A_WEB_SERVER_LAN_IP https netmask 255.255.255.255 
static (in2,out0) tcp CLIENT_A_WAN_IP ssh CLIENT_A_SFTP_SERVER_LAN_IP ssh netmask 255.255.255.255

Open in new window

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
  • 2
  • 2
4 Comments
 
LVL 29

Accepted Solution

by:
Alan Huseyin Kayahan earned 2000 total points
ID: 23122345
Hello jimbobmcgee,
    Its not a good practise to permit or deny traffic based on NAT rules. First, specifying a port number in a network access list like NAT ACL will force firewall to now check the port portion of each packet while making routing decisions. Restricting the unwanted traffic before it reaches the routing and forwarding phase will save processor cycles. This is achieved via access lists applied to 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_SFTP_SERVER_LAN_IP eq ssh
access-list in2_nat0_outbound remark ^^^ Workaround to allow Client B to upload to Client A SFTP
 
no nat (in0) 0 access-list in0_nat0_outbound
no nat (in0) 10 0.0.0.0 0.0.0.0
no nat (in1) 0 access-list in1_nat0_outbound
no nat (in1) 10 0.0.0.0 0.0.0.0
no nat (in2) 0 access-list in2_nat0_outbound
no nat (in2) 10 0.0.0.0 0.0.0.0
(Btw above Exempt NAT is bidirectional, so you don need an extra statement for return traffic)

static (in2,in1) CLIENT_B_SERVER_LAN_IP CLIENT_B_SERVER_LAN_IP netmask 255.255.255.255
access-list clientB_access_in permit tcp host CLIENT_B_SERVER_LAN_IP host CLIENT_A_SFTP_SERVER_LAN_IP eq 22
access-group clientB_access_in in interface in2

Regards
0
 
LVL 29

Expert Comment

by:Alan Huseyin Kayahan
ID: 23122360
forgot to put no before workaround ACLs

no access-list in1_nat0_outbound extended permit tcp host CLIENT_A_SERVER_LAN_IP eq ssh host CLIENT_B_SERVER_LAN_IP eq ssh
no access-list in1_nat0_outbound remark ^^^ Workaround to allow Client B to upload to Client A SFTP
no access-list in2_nat0_outbound extended permit tcp host CLIENT_B_SERVER_LAN_IP eq ssh host CLIENT_A_SFTP_SERVER_LAN_IP eq ssh
no access-list in2_nat0_outbound remark ^^^ Workaround to allow Client B to upload to Client A SFTP
0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 23149421
Thanks for this; based on your comments above and existing client requirements, I have tried the following:
  • Removed the workaround entries from the in1/2_nat0 access lists
  • Kept the nat rules, as I do want regular internet traffic from the client servers to be hidden behind the firewall address (nat 10 refers to a global, not listed), and I have VPNs that require nat0
  • Added the static (in2,in1) with the same source and destination (CLIENT_B_SERVER_LAN_IP)
  • Created an in2_access_in access list and added an entry permitting CLIENT_B_SERVER_LAN_IP to CLIENT_A_SFTP_SERVER_LAN_IP on TCP 22
  • Added an access-group on in2 for inbound traffic using access-list in2_access_in
It didn't work.  Client B's SFTP connection hung, then timed out and the ASA's syslog showed

"portmap translation creation failed for tcp src in1:CLIENT_B_SERVER_LAN_IP/63618 dst in2:CLIENT_A_SFTP_SERVER_LAN_IP/22"
I've tweaked and played as much as I can and have found that it only seems to allow the traffic through when the workaround permit rules are in the nat0 access lists, but will then allow all traffic between these servers (with or without the 'eq ssh' constraint).

The relevant parts of the current config, incorporating MrHusy's changes and my own requirements/tests is attached.  

J.

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 in1_nat0_outbound remark ...other VPN-related exemptions
access-list in2_nat0_outbound extended permit tcp host CLIENT_B_SERVER_LAN_IP eq ssh host CLIENT_A_SFTP_SERVER_LAN_IP eq ssh 
access-list in2_nat0_outbound remark ^^^ Workaround to allow Client B to upload to Client A SFTP
access-list in2_nat0_outbound remark ...other VPN-related exemptions
access-list out0_access_in remark -- The following entries dictate what is accessible from outside --
access-list out0_access_in extended permit tcp any host CLIENT_A_WAN_IP eq www 
access-list out0_access_in extended permit tcp any host CLIENT_A_WAN_IP eq https 
access-list out0_access_in extended permit tcp any host CLIENT_A_WAN_IP eq ssh 
access-list in2_access_in remark -- The following entries dictate what is accessible across LAN interfaces for in2 --
access-list in2_access_in extended permit tcp host CLIENT_B_SERVER_LAN_IP eq ssh host CLIENT_A_SFTP_SERVER_LAN_IP eq ssh 
 
global (out0) 10 interface
 
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
 
static (in2,out0) tcp CLIENT_A_WAN_IP www CLIENT_A_WEB_SERVER_LAN_IP www netmask 255.255.255.255 
static (in2,out0) tcp CLIENT_A_WAN_IP https CLIENT_A_WEB_SERVER_LAN_IP https netmask 255.255.255.255 
static (in2,out0) tcp CLIENT_A_WAN_IP ssh CLIENT_A_SFTP_SERVER_LAN_IP ssh netmask 255.255.255.255
static (in2,in1) tcp CLIENT_A_SFTP_SERVER_LAN_IP ssh CLIENT_A_SFTP_SERVER_LAN_IP ssh netmask 255.255.255.255 
 
access-group out0_access_in in interface out0
access-group in2_access_in in interface in2

Open in new window

0
 
LVL 16

Author Comment

by:jimbobmcgee
ID: 23156233
Also, when the access-group is in place on in2, VPN traffic from CLIENT_A_SFTP_SERVER to its DR-site counterpart no longer functions.  

Interestingly, traffic from the DR server to CLIENT_A_SFTP_SERVER still works, but not the other way around.

So I have taken the access-group out now, as well...
0

Featured Post

Enroll in September's Course of the Month

This month’s featured course covers 16 hours of training in installation, management, and deployment of VMware vSphere virtualization environments. It's free for Premium Members, Team Accounts, and Qualified Experts!

Question has a verified solution.

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

On Feb. 28, Amazon’s Simple Storage Service (S3) went down after an employee issued the wrong command during a debugging exercise. Among those affected were big names like Netflix, Spotify and Expedia.
This article is in regards to the Cisco QSFP-4SFP10G-CU1M cables, which are designed to uplink/downlink 40GB ports to 10GB SFP ports. I recently experienced this and found very little configuration documentation on how these are supposed to be confi…
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
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…
Suggested Courses

721 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