[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Inter-network Communication Issues

Posted on 2012-08-13
119
Medium Priority
?
505 Views
Last Modified: 2012-08-28
I have posted about this setup before, and mcke0wn777 was gracious enough to persevere with me while we worked out the connectivity issue.  Now, I have a communication issue.

I can ping IP addresses on both sides of this configuration, but I cannot communicate.  here is what I mean (and this won't make sense unless you see the attached PDF).

If I try to ping something on the 192.168.2.xxx side, I get a proper response.  If I ping -a from either side to the other, I get a proper response.  However,  if I try to RDP, or ping by name, or VNC to something from one side to the other -- no dice.  Any thoughts?
DormLink.pdf
ASA-Post.txt
1711MAR.txt
0
Comment
Question by:Quantifiable
  • 45
  • 40
  • 34
119 Comments
 
LVL 12

Expert Comment

by:mlongoh
ID: 38289039
Sounds like you don't have other ports open between the two sides.  For instance, if you can't PING by name but you can PING by IP, then DNS resolution isn't working and probably DNS updates.  Do the workstations on the 192.168.2.0 side get IP addresses from the DHCP server, and if you run NSLOOKUP can you resolve names?
0
 

Author Comment

by:Quantifiable
ID: 38289237
I was unable to resolve names with NSLOOKUP on the other side.  I actually tried that because of the weird results.  

Yes, the workstations are getting IP addresses from a device on the other side (see updated drawing attached).

I took out the untangle server (transparent bridge mode) that was handing-out the addresses and went straight from the router to the switch on the dorm side and got the same result as before (ruling out the untangle box).

I am suspicious that only ICMP packets are permitted.
DormLink.pdf
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38289488
You're probably right.  From a workstation try to telnet to the ip address of the DNS server using the port 53.  For example, if the DNS server (AKA Domain Controller) is 172.16.0.20, then from the workstation do this:
TELNET 172.16.0.20 53

The DNS server should be listening on that port and you should get a connection - basically a blank screen (as opposed to a failure to connect error).  You may have to just close the CMD window to break the connection.  You can verify that this works by doing it on a workstations on the 172 side... if you works on that side it should work on the other side, unless the port is blocked.

That will verify DNS.  You can do the same test for other ports (such as RDP and VNC's default ports).
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 

Author Comment

by:Quantifiable
ID: 38293306
When trying to telnet to the DNS service on the 192 side, I just received the "Could not open connection to the host, on port 53: Connect failed"
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293377
Hi Quantifiable, seems like you are still in trouble!

Don't want to jump on @mlongoh's help, but based on your telnet results that means this is ACL related...since you should get a connection to those ports normally...

Will have another look at the configs and see if I can help...
0
 

Author Comment

by:Quantifiable
ID: 38293392
Many thanks to both of you.
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38293510
Yep, the problem is almost surely in the 1711's access control list.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293560
Yep, try this to see...

On the 1711

conf t
access-list 102 permit ip any any
int vlan2
ip access-group 102 in
exit
exit

See if that allows traffic to pass, note its a wide open ACL just for testing, but will confirm if we are on the right path
0
 

Author Comment

by:Quantifiable
ID: 38293568
That makes sense, especially considering that the 1711 WAS using RIP, and I pulled that out because of the ASA on the other side.  I never introduced an ACL on the 1711 side for the 172 traffic coming in and out.

But, ACL for me stands for AChilles heeL.
0
 

Author Comment

by:Quantifiable
ID: 38293578
Should I have to reload the 1711 after that?  Is it tempermental?
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293582
No, no need for a reload, should work straight away...I hope...
0
 

Author Comment

by:Quantifiable
ID: 38293591
Oh.  Bummer
0
 

Author Comment

by:Quantifiable
ID: 38293602
I put VNC on a machine on the 192 network and I know it's up and running (I had someone check).

Is there a debug command I can enter to watch traffic come in and out.  I did do a SHOW ACCESS-LIST and 102 shows (10480) matches.  Eeeesh.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293604
Problems?
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293619
Well that means traffic is passing...which is good I think!

To see active connections on the 1711(well nat translations really) do

sh ip nat tr

Will show a lot of stuff though, but try and see
0
 

Author Comment

by:Quantifiable
ID: 38293627
Sorry, my brain didn't make it to the keyboard before my fingers.  I am unable to gain VNC access to the other workstation.  I can ping it from all places considered, but I cannot gain access.

I verified that the firewall was not turned on, and that VNC was indeed running.  The machine is also awake and eager to be active.
0
 

Author Comment

by:Quantifiable
ID: 38293635
Alright, so 192.168.2.250 (the machine running VNC) has one entry.


tcp 184.43.97.92:1493  192.168.2.250:1493 192.168.1.26:18082 192.168.1.26:18082


That isn't me trying to access it.  That is an attempt to hack on the SQL port (which isn't active)
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293638
This is after the ACL is applied...and the ACL is showing matches...so its not ACL related then, least not on the 1711

On the output of sh ip nat tr - can you see any traffic from 172 at all?
0
 

Author Comment

by:Quantifiable
ID: 38293658
Not at all.  Taking the cue, is there a similar command on the ASA?
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293699
ASA command is

sh xlate
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38293701
Can I suggest that you try doing the telnet test again from the 192 network to the DNS server (your DC) now that you have opened the ACL.  Stay consistent in your testing and work up from there.
0
 

Author Comment

by:Quantifiable
ID: 38293704
I will give that a shot.  I may not be able to respond again until tomorrow (I have to drive over to the dorms to do it).
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38293713
If I read the diagram right, then the ASA isn't playing a part in the flow of traffic between the two network segments... right?  The only thing really between them is the 1711?
0
 

Author Comment

by:Quantifiable
ID: 38293724
by: mlongohPosted on 2012-08-14 at 13:18:45ID: 38293713

If I read the diagram right, then the ASA isn't playing a part in the flow of traffic between the two network segments... right?  The only thing really between them is the 1711?

That's the way I expect it to be, yes.  But, in my limited understanding, I figured the ASA would have to have routes for the 192 subnet traffic that was inbound, right?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38293750
I mean from a layer 3 perspective.  FA3 on the 1711 should be on same subnet as the DC (DNS server) and therefore shouldn't need to involve the ASA in the routing... it should send traffic right to it.

Have you tried to telent to port 53 on the DNS server from the 172 side?  To confirm that there's no Windows firewall (or other 3rd party software firewall) doing the blocking?
0
 

Author Comment

by:Quantifiable
ID: 38293761
I did the first time you posted, but I have not since you asked today.  I will do that on my way out of the office this afternoon.  I have to drive over to the dorm to do that.  I'll post the results when I have tried.
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38293769
I think that your problem is that the 1711 is set to route all traffic for the 172 network through the ASA.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293783
Back up a bit...you're saying the 1711 is connected to a Dell managed switch - not going through the ASA first and then to the Dell managed switch?

If so then yes I agree with @mlongoh...ASA isn't part of the loop...has something changed from your question a few days back? Or is this the exact same config?
0
 

Author Comment

by:Quantifiable
ID: 38293793
Exact same config.


1711 --> Dell switch --> LRE (172 subnet) --> LRE Concentrator--> Dell Switch --> ASA
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38293797
smckeown777 - look at the attached DormLink.pdf file.  There's one attached to the initial question, but it's updated 2 post below.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293816
Ok, then the ASA shouldn't be used, since its not in the path between the 172 and the 192 subnets...don't know what a LRE Concentrator is though!!

Ok, maybe my fault from the beginning as I mis-read the config diagram...

Which means you are routing 172 traffic to the ASA...not needed

Remove this line from the 1711 config

no ip route 172.16.0.0 255.255.252.0 172.16.3.1
0
 

Author Comment

by:Quantifiable
ID: 38293841
Did that after mlongoh suggested that was a problem, but I still have the same issue.

An LRE Concentrator is a Cisco Long-Range Ethernet concentrator.  - Switch, actually.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293853
Ok, final question...

Is the DC/DNS server connected to the same switch? I mean you have

1711 --> Dell switch --> LRE (172 subnet) --> LRE Concentrator--> Dell Switch - DC/DNS?

Or have you

1711 --> Dell switch --> LRE (172 subnet) --> LRE Concentrator--> Dell Switch - ASA - DC/DNS?

After you removed the ip route from the 1711 can you post results of...

sh ip route
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38293859
Work backwards from the DC to diagnose your problem.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293871
@mlongoh - between the 1711 and the Dell managed switch - says LRE connection
0
 

Author Comment

by:Quantifiable
ID: 38293873
Alright, easy question first.

mlongoh:  The LRE  is on the diagram in the description of the link between the 172 dell switch, and the 1711 router.  **edit:  I did a poor job representing the hardware on that one**

smckeown777:  The first one.  The DC and the ASA would be parallel, and not inline.  The ASA is firewalling between the 10Mbps fiber connection and the 172 subnet.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293899
Cool, then the ASA isn't part of the loop...

After you removed the ip route command...can you still ping your DC?
Post output from command

sh ip route (run on the 1711)
0
 

Author Comment

by:Quantifiable
ID: 38293913
I'll have to go to the dorm for that.  When I leave the office here soon, I will go to the dorm on my way home.  I'll post those results.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293923
Not 100% clear on something...how did you remove the route command if you don't have access to the 1711!! Or am I missing something? Or are you physically bouncing between locations as we post ;)
0
 

Author Comment

by:Quantifiable
ID: 38293938
I have telnet access to the 1711, but I cannot ping the DC (172 subnet) from a machine behind the 1711 unless I am physically present.  The most current request was to ping the DC and post ip route.  I can post ip route, but I can't post ip nat tr after that until I have been there and tried it.  I might be confused though.

CCDORM1711# sho ip rou
     184.43.0.0/32 is subnetted, 2 subnets
C       184.43.97.92 is directly connected, Dialer1
C       184.43.97.1 is directly connected, Dialer1
     172.16.0.0/22 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, Vlan1
C    192.168.2.0/24 is directly connected, Vlan2
S*   0.0.0.0/0 [1/0] via 184.43.97.1
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38293975
No confusion...I was the one asking for sh ip route...so no hassle, understand that you can't do the DC thing until you are on the dorm yes...

Based on the routing table you should be able to access the 172 network, so this one is def confusing...ok we'll wait on your further testing thanks
0
 

Author Comment

by:Quantifiable
ID: 38295656
I went to a workstation on the 192 side and made sure I could ping the 172.16.3.254 address (domain controller / dns).  That was successful.

I, then, tried to telnet from that workstation to 172.16.3.254 53 and received "Connection failed"

I ran sh ip nat tr and there was absolutely NO traffic registered from the 192.168.2.250 address (the workstation I was using) after the Telnet attempt.

Very weird.  So, I confirmed my physical configuration at the dorm:

FA0/0:  DSL connection to internet
FA0/1:  172.16.3.19  (LRE connection to main campus)  [VLAN 1]
FA0/3:  Dell Switch [VLAN 2]
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38296049
Have you tested your ability to telnet to the DC on port 53 from a device/workstation on its local subnet (172.16), just to confirm that the DNS server service is accessible and responding?
0
 

Author Comment

by:Quantifiable
ID: 38296163
Yup.  No issues there.
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38296196
I'm assuming that you plugged into the Dell Managed Switch to test that.  What about plugging into the LRE (before the 1711) and doing the same test?  Just to eliminate the devices between the 1711 and the DC?  My expectation is that it would work as well.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38296314
This LRE device, haven't heard of it before, its a layer2 switch just? So there's no chance of any ACL/other configs on it that is allowing ICMP(ping) traffic but nothing else?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38296374
Exactly what I'm wondering... that's what I'm suggesting we test for and try to eliminate from the equation.
0
 

Author Comment

by:Quantifiable
ID: 38297290
I will head-over there right now to test the direct-to-LRE connection.  It is just a layer 2 connection.  

Basically, it's like an ethernet repeater that allows you to use cat3 cable to get about a 10Mbps connection.  Here is some light reading on the LRE
0
 

Author Comment

by:Quantifiable
ID: 38297343
As of this posting, I am connected to the LRE at the Dorm.  I have received an IP Address from the main campus network, and I am able to telnet to the DC's DNS service.

I'll plug the LRE into the router again.  And, by the way, the thing the Cisco 575 LRE module is plugged-in to is that 2900 switch I linked a few posts back.  Just a layer 2 managed switch with no VLANs

Also, yes, I did plug-in to the Dell switch.  I can get to the internet fine from this side, just can't get back over to the main campus network with anything more than an ICMP packet.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297509
Ok, so issue is with the router 1711

Maybe where I applied the ACL earlier wasn't enough, try this to test

conf t
int vlan 1
ip access-group 102 out
exit
exit

Lets see if that helps...
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297518
OK, if I understand what you posted correctly, that confirms that everything works beyond the 1711.  So, the issue appears to be at the 1711.
0
 

Author Comment

by:Quantifiable
ID: 38297524
Maybe I'm starting to think like a router jockey, because I did that already this morning and still had the same issue.

At one time, I had the following combinations of ACL 102 applied:

1.  VLAN 1:  out
     VLAN 2:  in

2.  VLAN 1:  in
     VLAN 2:  in

3.  VLAN 1:  in
     VLAN 1:  out
     VLAN 2:  in
     VLAN 2:  out

I know most of those were self-defeating configs, but I tried them anyway -- just for fun.
0
 

Author Comment

by:Quantifiable
ID: 38297528
I agree with both of you.  Everything does appear to point to the 1711.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297530
Ah I think i spotted it, its not ACL...

conf t
int vlan 1
ip nat inside

The vlan 1 interface isn't being natted...try that to see...
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297576
Why NAT when routing is all you want?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297591
It looks to me like VLAN1 isn't associated with an interface.
0
 

Author Comment

by:Quantifiable
ID: 38297666
To answer the question:  I'm not a router-jockey, so I wouldn't have known the difference had I not been through all of this.  I'm kind of learning on the fly.

Interfaces 1 - 4, by default, are part of VLAN 1.  I only need to specify if I want them to be a part of any other VLAN.  However, I went ahead and tried it, but it still shows "as if" it is not assigned.  It's a default assignment.

Taking a cue from your routing vs. NAT question, I don't remember when we took out the:
ip route 172.16.0.0 255.255.252.0 172.16.3.19 permanent
statement, but we did.  I put that back, and added:
ip route 0.0.0.0 0.0.0.0 Dialer1 permanent

Neither made a difference.

The other thing to remember is that in our previous configuration, this worked.  But, then, we had a 1711 on both sides -- still with the LRE connecting us to the main campus.  The only things that have changed are:

1.  We are now using an ASA 5505 running ios 8.2(5) on the main campus instead of a 1711

2.  We are now using CIDR on the main campus network instead of classful routing.

3.  We are no longer using RIP between both because, as I have learned, security devices aren't routers.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297691
You are correct, vlan 1 doesn't need to be assigned to an interface, its default to all interfaces...

As for the route question it shouldn't be related to the ASA, since the ASA doesn't touch anything because essentially we are just connecting at layer 2 from one end to the other...

So things aren't working with any of the changes we've posted?
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297720
Also back to this point
'The other thing to remember is that in our previous configuration, this worked.  But, then, we had a 1711 on both sides'

So I'm going to ask this again - where on the dorm side was the 'other 1711'?
Cause based on the diagram provided we are connecting from the existin 1711 through this LRE device to a switch - no sign of the other 1711/ASA in that loop that I can see?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297722
Just to be clear... no judgement... just the question that popped into my head.

So you have 2 different Internet connections on your network? One at the Dorm (DSL) and the other at Main Campus through the ASA?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297733
I think that in place of the ASA there was another 1711.
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297749
Two different Internet connections clarifies the NAT requirement on the 1711, but you shouldn't be NATing between the 192.168.2.0 and the 172.16.0.0 networks.  There's no need for that additional overhead.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297751
Yes I know that...but I'm still confused...since we've established that the ASA isn't part of the problem, why then would having another 1711 make this work? If the 1711 was in the same place as the existing ASA I mean? See what I mean?
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297759
Yes I also see your point in relation to natting between both 192 and 172 networks...shouldn't be needed, just wanted to see if it made a difference in the equation
0
 

Author Comment

by:Quantifiable
ID: 38297773
mlongoh -- you are correct.
0
 

Author Comment

by:Quantifiable
ID: 38297784
And, please forgive me for introducing confusion.

I realize the other 1711 had nothing to do with this. I was just trying to give a before and after view of the changes so that all things could be configured.

smckeown777, the layout I provided is the exact same way it was before I upgraded to the ASA on the main campus end (only there was a 1711 in place of the current ASA).  Same physical connections.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297802
Right...so that's where my confusion is coming from...why would replacing an existin 1711 with an ASA introduce this issue...since they aren't IN FRONT of the connection from the main campus to the dorm

Based on the diagram you have your existing 1711 - LRE - managed switch - DC/DNS

So nowhere in that loop does the ASA/(or old 1711) come into the equation!! Or am I still missing something?
0
 

Author Comment

by:Quantifiable
ID: 38297815
Nope, you're not missing anything that I can see.

Now, I think the answer to this question is "no that can't be it," but I'm going to ask anyway.

Is the fact that I'm using CIDR affecting me?  I figure the ISPs are handing down CIDR configurations all the time, so the 1711 should be just fine.  But, is there that off-chance that it's flipping me the bird over the subnet?
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297838
When you say 'using CIDR' what are you referring to exactly?

Your 172.16 subnet? Cause that's an private internal range and no relation to your ISP...and no relation to the issue(that I can see...)
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297845
Well given that you previously had traffic to the 172.16.0.0 network routed to the inside address of the ASA (presumably the inside address of the old 1711 when it was in place), it looks like the old 1711 was configured in such a way that it handled the routing (inefficient as it was).  That's my best guess regarding why it worked before.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297867
@mlongoh if you are referring to this line

ip route 172.16.0.0 255.255.252.0 172.16.3.1

Then that was put in place by my suggestion on his original question here
http://www.experts-exchange.com/Hardware/Networking_Hardware/Routers/Q_27820618.html

So it may not have been in place using the original 1711

@Quantifiable, have you your original 1711 config by any chance still? I mean when you still had the other 1711 where the ASA is currently?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297913
Yeah, that's what I was looking at.  OK, so that blows that theory.

I'm curious about this ACL line:
access-list 10 permit 192.168.2.0 0.0.0.255

Given that the subnet is /32 shouldn't that inverse mask be different from 0.0.0.255?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297932
Oh wait, I see from the config that VLAN 2 specifies a /24 subnet, so I'm a little confused between the diagram and the config regarding the subnet.

I realize that you've made a few changes to test with, but I haven't been able to keep up with them, so if my observation is moot, let me know.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38297947
Em...run that by me again! What subnet is /32?

That ACL looks fine,  its saying permit all traffic that is 192.168.2.1-254, I think...

@Quantifiable, post most recent configs as well please, for current 1711 and ASA...
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297952
I suspect that it may be the problem.  VLAN 2 is masking to class C, and so it can't talk nicely to the DC at 192.168.3.254?
0
 

Author Comment

by:Quantifiable
ID: 38297956
@mlongoh -- that would be the correct wildcard mask.  It's to route internet traffic to the dialer interface, but not anything else.

I'm looking for the old configs.  I found the main campus config for the previous 1711, but I can't seem to find the dorm-side config prior to this.
1711-PreReConfig.txt
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38297973
Sorry... got thrown by the diagram's subnet label.  Disregard.
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38298031
Regarding the ACL, I thought you needed to specify a source and destination and use ANY to represent all.  

For example access-list 10 permit IP 192.168.2.0 0.0.0.255 ANY would allow all IP traffic from the 192.168.2.0 network to anywhere.

Do I have that right?  Or does the IOS truncate access-list 10 permit IP 192.168.2.0 0.0.0.255 ANY to just access-list 10 permit 192.168.2.0 0.0.0.255?
0
 

Author Comment

by:Quantifiable
ID: 38298054
I believe it truncates.

Current configs:
ASA-Post.txt
DORM-CURR-CFG.TXT
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38298139
Thanks for the updated config... and sorry if I'm confusing the situation with my questions.  It's been 5 years since I touched a Cisco router.

If I have it right, access-list 102 is currently applied to VLAN2, so all traffic received on that interface with a source of 192.168.2.0 is allowed through.

Is it possible that the DC has a default gateway of 172.16.3.1 and thus is sending all response packets to the ASA, where they are dropped?
0
 

Author Comment

by:Quantifiable
ID: 38298333
The DC does have a default gateway of 3.1 .

What if i give the DC a secondary IP of 192.16.2.254?  Will that accomplish what I'm looking for?

That was part of the reason I was assigning ACLs to the ASA.
0
 

Author Comment

by:Quantifiable
ID: 38298354
Wait a minute, that can't be why.  The ASA has a route inside 192.168.2.0 255.255.255.0 172.16.3.19 statement

Also,  remember that I can ping anything I want to on either side.  I'm just not getting any other traffic.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38298365
Good thinking mlongoh...that would explain things for sure...

Although no I don't recommend adding a secondary IP to your DC, that will mess things up on your LAN on that side...

Yes but we removed the route statement on your 1711 pointing to the 172.16.3.1 on the ASA if I remember correctly

So the ASA does need to be in the loop(I've been looking at this question/config for so long I forgot why its in the loop!)

To test this lets work from the DC...
Add this command to your DC

route add 172.16.0.0 255.255.0.0 172.16.3.19
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38298376
Sorry I'm blind...that should have been

route add 192.168.2.0 255.255.255.0 172.16.3.19
0
 

Author Comment

by:Quantifiable
ID: 38298382
Yeah, I translated ;)
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38298391
Again I'll correct myself, been a long day ;)

route add 192.168.2.0 MASK 255.255.255.0 172.16.3.19
0
 

Author Comment

by:Quantifiable
ID: 38298400
The reason I am curious whether this will work is because I can ping stuff from the main part of campus too, and I can't access any of the machines there.

For example:

I have a machine at the dorm (where I was earlier) that has an ip address of 192.168.2.250.  I can ping that from my laptop right now (172.16.2.0).

I tried to VNC to that machine (with the firewall turned OFF) and I get nothing.

I have entered the new route into the DC, and tried to ping the 2.250 machine only to get a general failure.  When I pull-out the route in the DC, I can ping the machine again.


C:\Users\Administrator>ping 192.168.2.250

Pinging 192.168.2.250 with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.

Ping statistics for 192.168.2.250:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Administrator>route delete 192.168.2.0 255.255.255.0 172.16.3.19
route: bad argument 172.16.3.19

C:\Users\Administrator>route delete 192.168.2.0 mask 255.255.255.0 172.16.3.19 m
etric 1 if 1
 OK!

C:\Users\Administrator>ping 192.168.2.250

Pinging 192.168.2.250 with 32 bytes of data:
Reply from 192.168.2.250: bytes=32 time=46ms TTL=126
Reply from 192.168.2.250: bytes=32 time=51ms TTL=126
Reply from 192.168.2.250: bytes=32 time=43ms TTL=126
Reply from 192.168.2.250: bytes=32 time=43ms TTL=126

Ping statistics for 192.168.2.250:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 43ms, Maximum = 51ms, Average = 45ms

C:\Users\Administrator>

Open in new window

0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38298405
Yes the ping traffic is working...this is why this question is so confusing...

Try this

tracert 192.168.2.250

from the DC - and post output
0
 

Author Comment

by:Quantifiable
ID: 38298421
As I post this, remember that I am using an Untangle server in transparent bridge mode.  There will be an extra hop that will seem confusing -- this is normal in transparent bridge.
And, I tried this once without the untangle server in between with the same overall results (just minus the extra hop).

C:\Users\Administrator>tracert 192.168.2.250

Tracing route to CC-8GJKK51 [192.168.2.250]
over a maximum of 30 hops:

  1    45 ms    45 ms    44 ms  172.16.3.19
  2    44 ms    43 ms    43 ms  192.168.2.253    [i]Untangle Server[/i]
  3    45 ms    44 ms    43 ms  CC-8GJKK51 [192.168.2.250]

Trace complete.

C:\Users\Administrator>

Open in new window


More about Untangle here
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38298438
Ok, so that says its bypassing the ASA, which is good(takes it out of the loop)
Its going straight to the 1711(3.19 interface)

But are we sure the Untangle server isn't stopping normal TCP/UDP traffic and allowing ICMP? Think I mentioned this on the previous post you had? If you take it out of the loop completely are we seeing the same results?
0
 

Author Comment

by:Quantifiable
ID: 38298446
Yes, we see the same results when I take it out of the loop completely.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38298492
Right, so we are all the way back to ACL...since obviously routing is working as ICMP is working...

Might not get back to you until tomorrow(late over here)

I'll see what else I can think of in the meantime...
0
 

Author Comment

by:Quantifiable
ID: 38298501
I'm tempted to close this one out.  I can't see using up any more of your time.  I already feel bad for this.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38298508
No leave it open, others will be looking and may have input, no hassle we are here to help...talk tomorrow
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38298996
If the DC has a default route pointing it to 172.16.3.1, and you pulled the static route off the DC, then how could the tracert's first hop not be to 3.1?
0
 

Author Comment

by:Quantifiable
ID: 38299000
Because the ASA has a route statement in it:

route inside 192.168.2.0 255.255.255.0 172.16.3.19

Open in new window


That's more of a guess than a statement
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38299772
Actually I think its because they are on the same subnet - therefore you don't need to pass through default gateway to get to 3.19

I.e. the DC is on the 172.16.0.0/22 subnet - so is the 1711(FA3 - 172.16.3.19)
So the DC doesn't need to pass traffic through the ASA to get to the 1711

@Quantifiable quick question - what was the main reason for replacing your old 1711 with an ASA?
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38301196
So, traffic coming from the 192.168.2.0 network is going from the 1711 directly to the DC, but the response is going from the DC to the ASA to the 1711.  And as far as the ASA's ACL is concerned, that's new session traffic (not established).  And, even though the traffic is being routed by the ASA to the 1711, the ASA doesn't show up in the tracert because it's not hopping subnets at that point.

So, it's likely that the ASA's ACLs need to be examined because it really is part of the whole thing, and at this point appears to be the only factor left that could be causing the problem.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38301276
Yes...makes sense(I think!)
Plus since the ASA is the only change in the network and broke things its probably the cause...

Are you up to speed on ASA's mlongoh? Looking at the config the main line that allows comms between the 2 networks is

same-security traffic permit intra-interface

So all traffic flowing in and out of the SAME interface should be talking...this was all I thought was needed to make things work...its allowing ICMP to travel so I'm confused as to what else is missing...
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38301325
Well I believe that the ACLs applied to the interface still come in to play.  And the effective result shows that traffic isn't getting through.
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38301367
I'm not up to speed on the ASA, but I believe that the same-security traffic permit intra-interface command primarily is to allow traffic to get routed back out the interface that it came in on.  I believe that the ACLs applied to the interface still have to be considered.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38301384
Yes...but there are no ACL's applied!! So traffic should flow...unless the ASA works differently(I'm not 100% on ASA either)

Just to test...

@Quantifiable, can you add these lines to your ASA config...

conf t
access-list 102 extended permit ip any any
access-list 103 extended permit ip any any
access-group 102 in interface inside
access-group 103 out interface inside

Test with those lines(think I have the syntax correct) to see what we can get...
0
 

Author Comment

by:Quantifiable
ID: 38301752
I entered the lines you requested, and I can still ping the other side, but I cannot get any other conversation.  I have tried VNC to a known address, HTTPS to a known address, and still no dice.
0
 

Author Comment

by:Quantifiable
ID: 38301758
And the reason for going to the ASA was two-fold:

1.  Out main campus internet service was bumped-up and we wanted something that was newer

2.  Most importantly, we wanted the ability to syslog in detail for traffic inspection.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38302074
Ok, I don't think we are going to get this one solved and I think its due to the way the network is configured...let me explain where I am coming from...

Basically when you are connecting 2 networks(different subnets etc) traffic is passed from one router to another, i.e. you have your internal LAN, router's WAN - far side router WAN - far side LAN...

So anyone on the 172.16 net has default GW set to their router - it passes traffic out its WAN, to the other side WAN, to their 192.168 LAN

Now in your case things a a little different...
You have an ASA, its the default GW for LAN clients on the 172 side
So client on the LAN wants to get to 192.168 - it therefore sends traffic to router - which in turn knows how to get to 192.168...
Here's the difference though - the 172 network is DIRECTLY connected to the OTHER SIDE router as well as the ASA - through your LRE link - eg your 1711 has a 172.16 interface which links through the LRE to a switch on the far side, which in turn is connected to the LAN on the ASA side

So in effect there are 2 routes to get to the other side - through the ASA, and directly through the LRE - 1711...

So in effect this I think is breaking how things work

Now I may be wrong(correct me if I am of course!), but due to the setup of the network I can't see this ever working

So the next question you may ask is how did this work with the 1711 previously
That I have no answer for, bar to say that the ASA isn't a router, and maybe that's the reason it won't allow this to work like the previous 1711...but again I'm guessing

To ask another question - what do you mean by this?
'
2.  Most importantly, we wanted the ability to syslog in detail for traffic inspection. '
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38302219
I think I'm in partial agreement... though I would like to know what would happen if you changed the DC's default gateway (for testing purposes only) to 172.16.3.19, and then tried to access it from the 192.168.2.0 network.  If you were able telnet to the DNS server on it at that point, then I'd say "Yes, the world is as we perceive it and we need to change the network design."

At that point, I'd put the ASA between the 1711 and the 172.16 subnet.  So traffic has to go from 1711 to the ASA and back the same route.  This would require another VLAN for the connection between the 1711 and the ASA, but if the ASA has the ability to offer up another interface (VLAN), then that's the way I'd go with it.
0
 
LVL 24

Accepted Solution

by:
smckeown777 earned 1000 total points
ID: 38302246
Yes good test, I'd agree with the default GW setting to test and see...

Also agree that a 3rd subnet between the ASA and the 1711 may make life easier(i.e. make this work), it will handle this ok as its the Security Plus license to can create up to 20 vlans if needed...
0
 
LVL 12

Assisted Solution

by:mlongoh
mlongoh earned 1000 total points
ID: 38302515
I'm thinking it would look something like this (attached PDF).
DormLinkProposed.pdf
0
 

Author Comment

by:Quantifiable
ID: 38303428
Well, curse me for not asking the question I thought was stupid around comment 45.  I considered putting a buffer subnet between the two networks.  So, I'm going tot ale the decommissioned 1711 and put it between the LRE and the dorm 1711.  I'll create a 172.16.5.xxx/255.255.255.252 subnet in between.

I'll try the default GW change, but on a different server.  My DC is the only DNS right now.  I have four other servers I can try.  I'll do that before buffering the connection.

I'll let you know as soon as I have it done.
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38304869
Sorry Quantifiable, I'm not seeing what putting the old 1711 in between the Dorm 1711 and the LRE will do for you.
0
 

Author Comment

by:Quantifiable
ID: 38305080
I see what you are saying.  I need to put the ASA between the inbound internet connection and a router.  Then I can get the routing I want between networks, and still have divide who goes out which internet connection.

Do I understand that correctly?

And, btw, I have not done the gateway change yet.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38305295
Em...not sure what you mean when you say 'I need to put the ASA between the inbound internet connection and a router'

No need for another router, what you need is to have your existing LRE passing the traffic over to the other LRE, and into a switch

What you need is to put the ASA next in line - then everything else BEHIND the ASA

So you have

1711 - LRE - LRE - switch - ASA - 172 LAN...

Think that is what's needed...
0
 

Author Comment

by:Quantifiable
ID: 38312838
Sorry about the lack of attention here.

The LRE has to be looked at as one unit.  So, the text diagram above would really be:

1711 --> LRE --> Switch --> ASA --> 172 LAN

I cannot put the ASA "between" all of that per se' as the ASA does not differentiate between "inside" and "outside" except by VLAN.

What I can do, is change the IP address on the other side of the router from 172.16.3.19, to 172.16.5.1, then I can create a tertiary VLAN in the ASA, and assign one port to that VLAN.  Plug that into the switch as well, and I should be good ...... ????
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38313214
From a layer 3 perspective, you would be doing what we're suggesting.

192.168.2.0 LAN --> 1711 --> {through LRE} ASA --> 172 LAN

But we also strongly suggest that you do the default route test from the 172 subnet just to make sure that everything is as we believe it to be.
0
 

Author Comment

by:Quantifiable
ID: 38313266
I did do the default route test -- and you were correct.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38313335
Great, least that confirms why things weren't working!! Happy days...

Yep proceed if possible with the new config and hopefully things will start working as planned...
0
 
LVL 12

Expert Comment

by:mlongoh
ID: 38313351
Cool.

So you'll want to adjust the ASA's config to support the new vlan and you'll want routing adjusted so that packets from the 172.16 network destined for the 192.168.2.0 network is routed to 172.16.5.1.  And the Dorm 1711 needs to route traffic from 192.168.2.0 to 172.16.5.2 (assuming that this is the IP assigned to the new VLAN on the ASA).

And of course, the ACLs for both the 1711 and ASA need to support this as well.
0
 

Author Closing Comment

by:Quantifiable
ID: 38343116
This has been a ridiculous ride.  You guys have been stellar in your help and perseverance -- much appreciated!!

I think it all boils-down to the ASA being flaky.  I completely bypassed the routing issue and connected the remote LRE directly to my network for now and that's working just fine.  

I discovered that my ASA keeps dropping off the network.  I run a ping -t 172.16.3.1 from my laptop and there will be a string of good pings, and then I will get a "Request timed out" error every so often.  Sometimes up to 4 or 5 in a row.

I tried running a ping 8.8.8.8 repeat 1000 from inside the ASA and it completed with no hiccups and no latency.  I ran that several times.  But, I ping the ASA several times from the inside network and get skiddish results.

Trying to think smart (big stretch) I moved the connection from the switch to the ASA off of fast0/1 to fast0/4 and still had the same issues.

It looks like I need to replace this ASA, which was apparently purchased used with the knowledge that ports were bad.  Hmmmm.... Not good.

I'm going to mark this closed and assign both of you equal points.  I'm sure that all you guys have suggested should have worked.
0
 
LVL 24

Expert Comment

by:smckeown777
ID: 38343179
Good to hear you got an answer to the issue, been a hard one for sure, but glad to have helped sir...good luck with whatever you try next!!
0

Featured Post

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I found an issue or “bug” in the SonicOS platform (the firmware controlling SonicWALL security appliances) that has to do with renaming Default Service Objects, which then causes a portion of the system to become uncontrollable and unstable. BACK…
Quality of Service (QoS) options are nearly endless when it comes to networks today. This article is merely one example of how it can be handled in a hub-n-spoke design using a 3-tier configuration.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

872 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question