Go Premium for a chance to win a PS4. Enter to Win

x
?
Solved

Continuation of Q_23836442

Posted on 2008-10-28
4
Medium Priority
?
482 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
  • 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

Get Certified for a Job in Cybersecurity

Want an exciting career in an emerging field? Earn your MS in Cybersecurity and get certified in ethical hacking or computer forensic investigation. WGU’s MSCSIA degree program was designed to meet the most recent U.S. Department of Homeland Security (DHS) and NSA guidelines.  

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. 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…
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…
Suggested Courses
Course of the Month6 days, 19 hours left to enroll

783 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