cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3504
Views
0
Helpful
9
Replies

Configuring outbound traffic on SSH to specific IP addresses

RonTrello31209
Level 1
Level 1

Hi, very new to this and unfortunately in a position where I need to try and get some config working without having learned all the basics and core concepts yet. I'm using the ASDM for configuration. 

 

What I am trying to achieve - An internal IP address able to talk to 4 external public IP addresses over SSH. The traffic only needs to be outbound and on port 22. 

 

At first, I created a network object for the internal IP address and I created network objects for each of the external IP addresses. I then created a rule in ACL manager as so:

 

Source: server-appliance (my local IP that needs to communicate outbound on SSH/22)

Destination: external servers 

Service: TCP/SSH

Action: Permit

Capture.PNG

 

I didn't get anything working from this and saw that I need a NAT rule in place. So I created a NAT rule from inside to outside using my internal network object and external destinations. After this I still had no results, I'm not sure if this NAT rule is correct. 

Capture.PNG

 

 

Ultimately I'm a bit confused and it's hard to know what to configure where. E.G, I created a rule in the ACL manager but not in the access rules section. 

 

*Note - The firewall is already running with a config in place. This is just an extra bit of config to be added in. 

 

Thanks

2 Accepted Solutions

Accepted Solutions

Marvin Rhoads
Hall of Fame
Hall of Fame

Don't use the ACL Manager section - that's mostly for ACLs used for things other than interfaces (VPNs, service policies etc.)

Use the Configuration > Firewall > Access Rules section. Also not that once you put an outbound ACL in place all other traffic will be implicitly denied. If that's your intention, fine. Otherwise you may need to add some entries permitting other traffic outbound.

For instance, a simple rule set would be:

1. permit the desired ssh

2. deny all other ssh

3. permit any other traffic you want to allow

View solution in original post

As we can see from the packet-tracer cli output you aren't hitting any of the special ACL entries or NAT rule that you added. The traffic is allowed and NATted by the general rules already in place.

That's why I asked for that output - to see how or even if the new rules you were looking at interact with what's already in the config.

View solution in original post

9 Replies 9

Marvin Rhoads
Hall of Fame
Hall of Fame

Don't use the ACL Manager section - that's mostly for ACLs used for things other than interfaces (VPNs, service policies etc.)

Use the Configuration > Firewall > Access Rules section. Also not that once you put an outbound ACL in place all other traffic will be implicitly denied. If that's your intention, fine. Otherwise you may need to add some entries permitting other traffic outbound.

For instance, a simple rule set would be:

1. permit the desired ssh

2. deny all other ssh

3. permit any other traffic you want to allow

Thanks for your reply. When you say "Access List", do you mean the "Access Rules" right at the top? Pretty sure you do but wanted to check. 

I've deleted my ACL and replaced it with a rule in Access Rules on the inside interface as so: 


Capture.PNG

 

You'll see this is rule #2, above this is already a rule for any -> any (service IP) > permit. (There is a global deny rule at the bottom too). Part of what I'm confused by is that this is on the inside interface and it says it's an incoming rule but I want it to be an outbound rule. 

 

Thanks and appreciate the help. 

 

 

This is a packet trace of my local IP address > external IP address whereby I want to allow SSH. 

 

Capture.PNG

 

I'm still not getting any joy on the SSH to any of these servers. 

We generally make the rule "incoming" so that the ASA can drop the traffic right away. So "incoming" on the inside interface is effectively outgoing on the outside interface (oversimplifying for the sake of discussion).

Your NAT rule is essentially "no NAT". Is that what you want? To preserve the original source and destination addresses?

@Marvin Rhoads 

No, I would assume that isn't what I want (this will be my lack of current knowledge), there is no need for the private IP to be preserved as far as I am aware. Is this no-NAT because I've left the translated packets as 'original'? So I should actually be setting the source interface to 'inside'? Initially I thought this, but when I try to apply the rule it errors and is deleted.

 

Thanks for the help again. I'm aware I'm trying to run before I can walk but I just need to get this in place and working.

This is where I am at the moment (but not working successfully): 

 

Access rule - I've changed source to 'any' as I don't think this really matters. So any source heading to those 4 destinations can do so over ssh. 

Capture2.PNG

Note - There are other rules to handle generic traffic and an implicit deny at the end. 

 

NAT rule - 

Capture1.PNG

 

Can you run packet-tracer from the cli and verify you are hitting the intended ACL entry and NAT rule? You've only shared snippets from the GUI and there may be other higher precedence rules that you are hitting instead of the ones you want.

packet-tracer input inside tcp <your source address> 1025 <address of one of the destination ssh servers> 22

 

Hi @Marvin Rhoads 

From what I can see, tracking a packet over the CLI returns what I should expect, see sanitised results below: 

 

# packet-tracer input inside tcp 192.168.16.54 1025 EXTERNAL_IP 22

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop [EGRESS_IP] using egress ifc outside

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_in in interface inside
access-list inside_access_in extended permit ip any any
Additional Information:

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
object network obj_any
nat (inside,outside) dynamic interface
Additional Information:
Dynamic translate 192.168.16.54/1025 to TRANSLATED

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 4965522, packet dispatched to next module

Result:
output-interface: outside
output-status: up
output-line-status: up
Action: allow

 

I may well have over-complicated things here by presuming I needed to add new rules to the firewall. 

We already have a ANY ANY rule on the inside interface which I now know is permitting any traffic from the inside to go out.
We also already have a NAT rule from inside to outside which is set to ANY ANY. 

 

So in actual fact, am I trying to put something more in place that I actually don't need?

As we can see from the packet-tracer cli output you aren't hitting any of the special ACL entries or NAT rule that you added. The traffic is allowed and NATted by the general rules already in place.

That's why I asked for that output - to see how or even if the new rules you were looking at interact with what's already in the config.

Review Cisco Networking for a $25 gift card