07-06-2020 04:34 AM - edited 07-06-2020 05:07 AM
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
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.
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
Solved! Go to Solution.
07-06-2020 04:59 AM - edited 07-06-2020 05:23 AM
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
07-07-2020 10:38 AM
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.
07-06-2020 04:59 AM - edited 07-06-2020 05:23 AM
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
07-06-2020 05:17 AM - edited 07-06-2020 05:23 AM
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:
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.
07-06-2020 05:21 AM - edited 07-06-2020 05:22 AM
This is a packet trace of my local IP address > external IP address whereby I want to allow SSH.
I'm still not getting any joy on the SSH to any of these servers.
07-06-2020 05:27 AM
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?
07-06-2020 05:37 AM - edited 07-06-2020 05:38 AM
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.
07-06-2020 07:11 AM
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.
Note - There are other rules to handle generic traffic and an implicit deny at the end.
NAT rule -
07-06-2020 10:19 AM
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
07-07-2020 12:59 AM
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?
07-07-2020 10:38 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide