cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10599
Views
0
Helpful
48
Replies

Connecting two subnets

dataIP
Level 1
Level 1

I have a problem with linking two seperate subnets which contain a individual small business networks.

Setup is each network has an ASA5505 and a 887 to provide internet connectivity. A variety of Cisco small business and one enterprise switch provide the switching. Each network contains its own servers and clients.

As a temporary measure I need to be able to access resources 'cross subnets'. (It is one business that has split in to two business units, so no privacy/security issues). The router will be removed once all relevant data has been migrated between networks.

Networks are 192.168.88.0 and 192.168.0.0, both with netmasks of 255.255.255.0

So, as a simple example a server on the .88 network needs to access information on a server at 192.168.0.128

We have the two segments linked with a Cisco E1000 router (was using a 871, but that seemed to cause more issues). IPs are 88.253 and 0.253 on each side.

I have enabled RIP on the E1000 and both ASA.

Both ASA have same-security-traffic permit intra-interface

From the 88.128 server, I can ping everything on the .88 network plus the far side of the E1000 (at 0.253) and the far side ASA (at 0.254), but not the far side server (at 0.128).

Maybe going back to the 871 may be a good plan, at least I should be able to debug things a bit easier from the command line?

I am sure there is something fundamental I am missing here.

48 Replies 48

As far as I can tell, I shouldn't need an acl on the inside interface ... the implied rule is to allow.

However, I placed those rules so that I could monitor the hits. I was seeing hits on that rule when I generated traffic.

Rules now removed.

Hi,

Please try this configurations. This configuration is based on the assumption that you already has ICMP reachability between two networks as you have mentioned on previous posts. If you dont have ICMP reachability please use the static routes on 871 as mentioned below. Ensure that you have ICMP reachability before applying my configuration

ASA1

---------

interface vlan 1

nameif inside

security-level 100

ip address 192.168.88.254 255.255.255.0

!

same-security-traffic permit intra-interface

!

access-list tcp_bypass extended permit tcp 192.168.88.0 255.255.255.0 any

!

router rip

network 192.168.88.0

version 2

no auto-summary

!

class-map tcp_bypass

description "TCP traffic that bypasses stateful firewall"

match access-list tcp_bypass

!

policy-map tcp_bypass_policy

class tcp_bypass

  set connection advanced-options tcp-state-bypass

!

service-policy tcp_bypass_policy interface inside

!

ASA2

--------

interface vlan 1

nameif inside

security-level 100

ip address 192.168.0.254 255.255.255.0

!

router rip

network 192.168.0.0

version 2

no auto-summary

!

same-security-traffic permit intra-interface

!

access-list tcp_bypass extended permit tcp 192.168.0.0 255.255.255.0 any

!

class-map tcp_bypass

description "TCP traffic that bypasses stateful firewall"

match access-list tcp_bypass

!

!

policy-map tcp_bypass_policy

class tcp_bypass

  set connection advanced-options tcp-state-bypass

!

service-policy tcp_bypass_policy interface inside

!

871

---

ip route 192.168.0.0 255.255.255.0 192.168.0.254

ip route 192.168.88.0 255.255.255.0 192.168.88.254

!

IMPORTANT NOTE:


Believe me, I’m not an expert on ASA. To be frank this is the first time I'm playing around with ASA (with my GNS3) like this. I hope the above solution may fix the telnet or http access issue between two networks but not sure whether my proposed configuration will have any other impact on a real production network. So just be cautious about that.

After applying the configuration please confirm back that status and if the solution is working I can write up brief explanation of my solution.

Regards

Najaf

Hi Najaf,

Thanks for your interest in this problem.... looks like your solution works for me!

The ICMP connectivity was present, so I did not need to add the static routes on the 871.

I wasn't sure about the RIP configuration... on the 871 obviously it needs both 192.168.0.0 and 192.168.88.0, but I thought this also applied to the ASAs as they are passing traffic for both destinations (at least on their inside interfaces).

My initial question was obviously looking at the wrong element... I assumed that the 871 (or E1000) router wasn't passing traffic, with everyones help we were able to focus on traffic flowing through the router but then not passing correctly through the inside interfaces on each ASA.

I now have ICMP connectivity, http, and important for this migration project, access to Windows 'shares' on both networks to allow our customer to migrate their data between networks.

I have some more testing to do on site this morning, but it looks like you have solved my issue.

Thanks to you and all others that help with this issue.

Mark

Hi Mark,

Good to know that you have a workable solution now.

Sorry it took hell out of time for me to come up with this solution. While i was simulating this on my GNS3 i could see that the problem was with ASA. ASA was dropping the packet as it was looking in its stateful table when it get SKY packets from downstream devices and since i was not able to find anything on stateful tabel the packets was getting dropped. You would be able to see this on ASA A logs when you initiate a telnet from Server B to A as shown below.

%ASA-6-106015: Deny TCP (no connection) from 192.168.88.128/23 to 192.168.0.128/57508 flags SYN ACK  on interface inside

%ASA-6-106015: Deny TCP (no connection) from 192.168.88.128/23 to 192.168.0.128/57508 flags ACK  on interface inside

%ASA-6-106015: Deny TCP (no connection) from 192.168.88.128/23 to 192.168.0.128/57508 flags SYN ACK  on interface inside

Here ASA is actually inspecting TCP traffic and when ASA A gets a SYN ACK and it will check its stateful table to see if has send a SYN request to get SYN ACK. Since it doesnot find a match entry it will drop the packet.

So the workaround was to enable TCP State Bypass., this was a feature put on the firmware 8.2.

TCP state bypass is a feature where the firewall will disable its TCP inspection for certain traffic types.

I was not able to test this feature on my GNS3 as i was using firmware 8.0 and hence i had to upgrade the firmware in order to test this. Belive it or not i had a though time is getting my current firmware 8.4 up and running on GNS.

Coming back to the actual solution

access-list tcp_bypass extended permit tcp 192.168.88.0 255.255.255.0 any

!---the above access list to specify the TCP traffic that needs to by-pass inspection

class-map tcp_bypass

description "TCP traffic that bypasses stateful firewall"

match access-list tcp_bypass

!--- Configure the class map and specify the match parameter for the!--- class map to match the interesting traffic (that is the above created acl).

policy-map tcp_bypass_policy

class tcp_bypass

!--- Configure the policy map and specify the class map inside this policy map for the class map.

set connection advanced-options tcp-state-bypass

Use the set connection advanced-options tcp-state-bypass 
!--- command in order to enable TCP state bypass feature

and Finally

service-policy tcp_bypass_policy interface inside

!--- Use the service-policy policymap_name on the inside interface!--- This command is used in global configuration mode in order to activate a policy map

Hope this helps

Regards

Najaf

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: