ping works, SSH does not

[jussivee]

ASA default gateway in 172.31.224.0/20 subnet. Address is 172.31.224.1.

172.31.224.4 is a gateway to 172.31.100.0/24 subnet. This gateway is connected to same external switch as ASA.

My aim is to make ASA forward packets destined to 172.31.100.0/24 through 172.31.224.4.

Here is parts of the configuration that I've done to get it working:

access-list inside_access_in extended permit ip any any log debugging

access-list NONAT extended permit ip 172.31.224.0 255.255.240.0 172.31.100.0 255.255.255.0

access-list NONAT extended permit ip 172.31.100.0 255.255.255.0 172.31.224.0 255.255.240.0

nat (inside) 0 access-list NONAT

access-group inside_access_in in interface inside

route inside 172.31.100.0 255.255.255.0 172.31.224.4 1

The result is that ping works from 172.31.224.0/20 to 172.31.100.0/24.

Dest MAC is ASA MAC when sending the packets and replies are coming from the GW 172.31.224.4 MAC. So routing works.

But when trying to connect SSH to host 172.31.100.20, connection times out. Some packets can be seen in packet capture between client and SSH server, but still no connection.

If I add route 172.31.100.0 mask 255.255.255.0 gateway 172.31.224.4 to client machine, SSH connection starts working.

So how to configure ASA so that I do not have to create the route to 172.31.100.0/24 in all client machines?

[Jouni Forss]

Hi / Moi,

If I understood the situation correctly it would seem to me that we are talking possibly talking about asymmetric routing.

Also the problem might be because of the ASA configurations even though you have the route.

Have you configured the "same-security-traffic permit intra-interface"?

This would enable the connection that enters an ASA interface to head out the same interface in which this case seems to be the "inside" interface.

Have you monitored what the ASA logs say. In the capture have you seen any return traffic from the network 172.31.100.0/24 hosts? To my understanding there should be none because of the asymmetric routing.

So if I understood correctly the connection would work this way at the moment

• Host on network 172.31.224.0/20 initiates connection to network 172.31.100.0/24
• Connection attempt gets routed to ASA
• ASA routes the traffic back out the "inside" interface to another gateway address on the 172.31.224.0/20 network 
  • unless the connections get blocked right at this point because of the ASA
• Traffic heads to host on the 172.31.100.0/24 network through the other gateway
• The host on the network 172.31.100.0/24 replies to the TCP connection forming.
• HOWEVER as the gateway device 172.31.224.4 sees the network as directly connected it will ARP for the host that tried to open the connection and will send the traffic directly to the host AND NOT to the ASA
• Therefore ASA never sees the reply and the connection attempt from its perspective ends with SYN Timeout
• The host on the "inside" will probably try to send TCP ACK to the remote host which then arrives on the ASA first and the ASA blocks this and generates log message. This is because it has never seen the TCP SYN ACK from the remote host

Though I might have missunderstood the situation.

- Jouni

[jussivee]

Thanks Jouni,

You understood the situation just right and seems that I was talking about asymmetric routing.

same-security-traffic permit intra-interface has been configured. Now I understand that ping is working because it does not require TCP connection.

According to this document https://supportforums.cisco.com/docs/DOC-14491 and example B, which is this situation, there are two options that could be used to fix this:

1. remove the other router 172.31.224.4 and make ASA 172.31.224.1 the ONLY router for 172.31.100.0 network

2. use TCP State Bypass for this traffic

As this option 2 would significantly degrade security I think I'll go with option 1.

[Jouni Forss]

Yeah,

I tend to avoid any special routing related setups when it comes to ASA firewall since it doesnt handle those that well. Usually either handle the routing on an actual router or if firewall is required, bring the connection first to the ASA on its own interface/subinterface so the traffic flow is something that doesnt cause problems with the ASA or require configuration related workarounds.

Once you decide to use the ASA for some "special" routing setups you will probably end up regretting it in the long run and wish you had done it right the first time

- Jouni