Cisco ASA Routing between 2 subnets behind 'Inside' interface

[Jim R]

Hi folks,

I am hoping this is something trivial but am having some issues routing between two subnets behind a Cisco ASA 5510.  Before I start I am aware this is less than optimal however at present we have no choice regarding this configuration.

So E0/1 is configured as the 'inside' interface with an address of 192.168.1.0/24.  We also have another subnet on the inside; 192.168.15.0/24 (Accessible via router 192.168.1.180) which is configured with a static route to provide access.  That router is directly connected to both subnets.

The following configuration is on the ASA:

no nat-control

interface Ethernet0/0
 description outside
 nameif outside
 security-level 0
 ip address 87.224.126.171 255.255.255.248
!
interface Ethernet0/1
 description inside
 nameif inside
 security-level 100
 ip address 192.168.1.254 255.255.255.0
!

same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
access-list inside_access_in extended permit ip any any
access-list inside_access_out extended permit ip any any

access-group inside_access_in in interface inside
access-group inside_access_out out interface inside
route inside 192.168.15.0 255.255.255.0 192.168.1.180 1

The confusing thing here is I can ping all interfaces and all devices local to those subnets (Trace route appears to check out etc) however I can do nothing else.   I have a number of open ports on devices at the other end which are not visible however I can see nothing occurring on the firewall to block access.

Does anyone have any thoughts? This one has me bamboozled at the moment ...

J

[Jim R]

Also included below is the packet tracer output:

ciscoasa#  packet-tracer input inside tcp 192.168.1.100 20761 192.168.15.100 3$

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   192.168.15.0    255.255.255.0   inside

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: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_access_out out interface inside
access-list inside_access_out extended permit ip any any
Additional Information:

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

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

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow

[Jouni Forss]

Hi,

The main problem with for example TCP connections is the fact that the ASA does not see the whole TCP connection negotiation.

Since you are running into this problem I presume the other LAN network is using the ASA as its gateway rather than the internal router? In this case when the host attempts to open the TCP connection it sends the TCP SYN packet to the ASA which then forwards this packet to the internal router and the internal router forwards this packet to the actual host in the other subnet. This host then replies with TCP SYN ACK and forwards this to the internal router which then forwards this packet directly to the host that is attempting to form the TCP connection. This host then finally responds with TCP ACK to the other host and sends this packet to the ASA and ASA drops the packet as its still expecting to see the TCP SYN ACK that now went directly to the host past the ASA.

In this situation I guess there are a few solution (of which some dont seem to be an option for you)

• Move the internal router behind some other ASA interface. If no physical interfaces are available consider configuring Trunk
• Have the LAN hosts use the internal router as their gateway. This probably causes unnecesary extra traffic on the LAN as everything would go through the router and then to the ASA. Then again we dont know where the routers default route is pointing, perhaps somewhere else than the ASA?
• Configure TCP State Bypass on the ASA to avoid the ASA dropping the packets that dont match the normal TCP connection behaviour

I guess in your situation you would like to temporarily use the TCP State Bypass rather than make actual modifications to the existing network?

You should probably check the TCP State Bypass configuration from a Cisco document and apply it to your situation. It is pretty simple to configure.

Here is a link to the document:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/conns_tcpstatebypass.html

The document uses an example situation that does not really match your situation. The most important example part is the following.

Configuration Examples for TCP State Bypass

The following is a sample configuration for TCP state bypass (modified from the document):

hostname(config)# access-list tcp_bypass extended permit tcp <lan1 subnet> <mask> <lan2 subnet> <mask>

hostname(config)# class-map tcp_bypass

hostname(config-cmap)# description "TCP traffic that bypasses stateful firewall"

hostname(config-cmap)# match access-list tcp_bypass

hostname(config-cmap)# policy-map tcp_bypass_policy

hostname(config-pmap)# class tcp_bypass

hostname(config-pmap-c)# set connection advanced-options tcp-state-bypass

hostname(config-pmap-c)# service-policy tcp_bypass_policy inside

- Jouni

[Jim R]

Hi Jouni,

Thanks for your detailed response,  In the background I replicated the configuration on a non production system that was a bit quieter when I saw this:

 %ASA-6-106015: Deny TCP (no connection) from 192.168.1.100/3389 to 192.168.15.100/58305 flags SYN ACK  on interface inside

Annoyingly I came to the same conclusion as yourself shortly after I posted :) But your reply has been a big help in filling in the blanks.  Anyway for completeness (And anyone else who runs into this) I did the following: 

access-list tcp_bypass extended permit tcp 192.168.1.0 255.255.255.0 192.168.15.0 255.255.255.0
class-map tcp_bypass
match access-list tcp_bypass
policy-map tcp_bypass_policy
class tcp_bypass
set connection advanced-options tcp-state-bypass
set connection timeout idle 0:10:00
service-policy tcp_bypass_policy interface inside

And all is working expected.   However I do need to work how how to do this pre 8.2 (The version in question is 7.2 I believe)  so I'll move onto that now :)

Thanks again,  Your input was greatly appreciated.

J

[Jouni Forss]

Hi,

I would suggest changing the "any" to the actual destination subnet. The other LAN subnet. Otherwise I guess this will affect ALL traffic from the LAN. Even to the external network.

As Karsten noted below, this is not an ideal solution and its actually disabling one important feature of the firewall. Best solution in these cases is to setup the network so that there are no secondary gateways inside one subnet.

I have not personally used this configuration in any production environment. Always gone with the option of changing the network setup. If its supported in 7.2 then thee configuration format should be identical to 8.2.

Hope this helps :)

Let us know if you get the setup to work on your actual network.

Please do remember to mark a reply as the correct answer if it answered your question and/or rate helpfull answers.

- Jouni

[Karsten Iwen]

The state-bypass was introduced in 8.2, so that solution won't be available in 7.2.

[Karsten Iwen]

In a situation like this, the ASA should not be configured to be the default-gateway for your systems. Configure your internal systems in the 192.168.1.0/24 network to use the router at 192.168.1.180 as the default gateway. All other solutions will mess up the ASA with a painful NAT-configuration or disabled statefull inspection. That's really not what should be done.