cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
597
Views
14
Helpful
6
Replies

administrative access via firewall

suthomas1
Level 6
Level 6

Hi,

Following is the network flow;

Remote Client Network --> client network switch( 192.168.100.1 ) ----- (192.168.100.2) ASA 5540 (172.16.10.1) --> (172.16.10.2) Nexus 5K --> SVR VLANS

Client network is 192.168.100.0/24 , 192.168.121.0 /24.

From the client network, we need to allow them administrative access to ASA and Nexus 5K via telnet or ssh.

There is an ASA firewall which interconnects both legs ( towards the remote client & other end to our side of infrastructure ).

Appreciate help on how to do this. What all should be enabled on the ASA & N5K on our side so administrators from 192.168.100.x and 192.168.121.x network

can access and manages both these devices.

Thanks in advance.

1 Accepted Solution

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

I cant really help with the Nexus

For ASA this should be pretty simple

To enable telnet and ssh you could use

telnet 192.168.100.0 255.255.255.0

telnet 192.168.121.0 255.255.255.0

crypto key generate modulus 2048  (IF you have not already done so, which you have if you use SSH currently to manage the firewall)

ssh 192.168.100.0 255.255.255.0

ssh 192.168.121.0 255.255.255.0

There is naturally "aaa" related settings which you should configured so that the users authenticate using their own username/password. That you can do either using the ASAs local database or use an AAA server to authenticate the users when they log in. And also you can use AAA servers as main authentication method and local database as fallback if the AAA servers have failed or are unreachable.

For the telnet/ssh connections to the Nexus device you will need to allow the traffic on the interface ACL where the source networks are connected.

I guess you should mainly stick to using SSH for the management purposes instead of Telnet. Or only use Telnet if there is some problems related to SSH.

- Jouni

View solution in original post

6 Replies 6

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

I cant really help with the Nexus

For ASA this should be pretty simple

To enable telnet and ssh you could use

telnet 192.168.100.0 255.255.255.0

telnet 192.168.121.0 255.255.255.0

crypto key generate modulus 2048  (IF you have not already done so, which you have if you use SSH currently to manage the firewall)

ssh 192.168.100.0 255.255.255.0

ssh 192.168.121.0 255.255.255.0

There is naturally "aaa" related settings which you should configured so that the users authenticate using their own username/password. That you can do either using the ASAs local database or use an AAA server to authenticate the users when they log in. And also you can use AAA servers as main authentication method and local database as fallback if the AAA servers have failed or are unreachable.

For the telnet/ssh connections to the Nexus device you will need to allow the traffic on the interface ACL where the source networks are connected.

I guess you should mainly stick to using SSH for the management purposes instead of Telnet. Or only use Telnet if there is some problems related to SSH.

- Jouni

i agree with jouni, use SSH whenever possible since telnet is insecure or sends traffic in clear text (sniffable).

also further adding to what jouni posted, you might want to enable a dedicated out-of-band (OOB) mangement interface on your 5540 (assign a higher security level)

interface management0/0

management-only

security-level x

Thanks.

What i forgot to tell is the way the management network is connected, may be that might help to analyse this.

The dedicated management interface on ASA is configured with the gateway ip address & this is connected to the core on an access port. I tried using access list on the ASA interfaces but it doesn't work.

The management network(Vlan50) is 10.10.50.1/24.

The ASA me0/0 is assigned 10.10.50.1 and the core switch is assigned 10.10.50.2 on Vlan50.

Management-only traffic has been disabled on the me0/0 interface to verify access, but it is not yielding anything.

We are trying to connect remotely (via ssh /telnet ) from Client network (192.168.100.0/24 , 192.168.121.0 /24) to ASA and switch on ip's 10.10.50.1 & 10.10.50.2.

Please help on tis.

Hi,

One thing to note with the ASA management is the fact that you can only connect to an ASA interface IP address from behind that said interface.

So if you Management0/0 interfaec is configured with an IP address and you want to manage the ASA using that interface IP address you will have to be behind that interface. So you cant connect to that interface from behind another ASA interface.

The only exception is when a management connections is coming through a VPN connection. Then you can use configured "management-access " to enable connecting to that interface. But in your case we are not talking about VPN.

Though you should be able to connect to the switch behind the Management0/0 interface. If we are talking about a L2 switch you have to make sure that the switch has its default gateway configured so it can forward the return traffic back to the management hosts. You will also have to make sure it has passwords configured under "vty" and that no ACL is blocking your access.

You will have to also make sure on the ASA that those connections are allowed.

You can always use the "packet-tracer" command to simulate a management connection coming from the user to the switch management IP address and see what rules/configurations it hits and if it goes through.

For example

packet-tracer input tcp 192.168.100.x 12345 10.10.50.2 22

packet-tracer input tcp 192.168.100.x 12345 10.10.50.2 23

Just enter the input interface "nameif" there and specify the complete source address for the simulated connection.

- Jouni

Thanks again.

Below is the related configuration from ASA and Core switch.

A simple network diagram is also attached.

ASA:->

interface Management0/0

nameif management

security-level 100

ip address 10.10.50.1 255.255.255.0

interface Port-channel1

description To Outside switch

nameif OUTSIDE

security-level 0

ip address 192.168.100.2 255.255.255.252

!

interface Port-channel2

description To Core Switch

speed 1000

duplex full

nameif INSIDE

security-level 100

ip address 172.16.10.1 255.255.255.252

access-list OUT_access_in extended permit ip 192.168.100.0 255.255.255.0 192.168.5.0 255.255.255.0

access-list OUT_access_in extended permit ip 192.168.121.0 255.255.255.0 192.168.5.0 255.255.255.0

access-list OUT_access_in extended permit ip 172.16.29.0 255.255.255.0 10.10.50.0 255.255.255.252

access-group OUT_access_in in interface OUTSIDE

route OUTSIDE 0.0.0.0 0.0.0.0 192.168.100.1 1

route INSIDE 192.168.5.0 255.255.255.0 172.16.10.2 1

============================================

Core Switch:->

ip route 0.0.0.0 0.0.0.0 172.16.10.1

int vlan 50

ip address 10.10.50.1 255.255.255.0

interface eth1/2

switc acc vlan 50

int vlan 5

ip address 192.168.5.1 255.255.255.0

What i see is i have no way of adding a defa gateway on the core switch for the managment traffic as there is a existing default route pointing to the ASA. I have also included ACL's to allow this.

Also, when i did packet trace earlier, it indicated flow is dropped by acl-drop.

Please help on this.

Hi,

According to the above both your switch and ASA is configured with the same IP address?

Notice also that your Management and Inside interface are both "security-level 100". This means that in order to pass traffic between these interfaces you will need to have the "same-security-traffic permit inter-interface" command configured.

You can confirm if its configured with the command

show run same-security-traffic

But yes, you will run into problems with routing if you try to handle inter Vlan routing on the core switch and are also trying to forward traffic through the ASA.

I would look into the possibility of configuring a separate VRF for each of your network segments. What you could do with VRFs is basically separate each network you have to their own routing table. Vlan5 could be in a VRF called INSIDE and Vlan50 could be in a VRF called MANAGEMENT. This would mean the networks on Vlan5 and Vlan50 couldnt see eachother, both could have their own default route. If you wanted to add more Vlans to the INSIDE or MANAGEMENT you could simply attach the Vlan interface to that VRF and that Vlans network would be only added to that VRFs routing table. This would enable you to easily separate the networks from eachother in the Core and still be able to easily forward each networks traffic through the ASA

Did a quick search and found this document related to VRF on the Nexus5k

http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/unicast/5_0_3_N1_1/l3_virtual.html

- Jouni

Review Cisco Networking products for a $25 gift card