Cisco → [HELP] Cisco or RDP ? Where's the issue?

Hi everyone,

I recent issue came up and I'm trying to determine if its the cisco or what. I'm trying to RDP into my 10.10.10.100 host from my 192.168.1.3 host. This would obviosuly traverse the internal cisco.

I'm having some connectivity issues where sometimes I can get into the machine via RDP (3389) and for about 15 seconds...then it drops for like what seems 3-5 minutes and sometimes I can get back in...etc etc.

Would the Cisco by default drop this traffic? I'm assuming not, since I can sometimes get into it via RDP, but not for very long. I tried creating an ACL just to see, but it didnt help.

Maybe its the linksys router that is causing the issues? I can ping the host (10.10.10.100) that's connected via wifi to the linksys all day long. Its just the RDP thats being a bi*ch

Any ACL saying deny ip to host 192.168.1.3 I wonder?

Good catch, but I don't have anything currently applied to the interfaces on the Cisco. So that can't be it.

I have done some more troubleshooting. I took it off wifi and plugged in directly into a port on the switch (vlan 2) and it still gave me the issue.

So then I took another PC, hooked it up on the same vlan, and I can RDP into that other netbook host no problem. Its when I'm on the 192.168.1.0 vlan that I can't.

Yet I can ping any host on the ciscolab vlan all day long. Just ports arnt working. Argh


home-cisco#sh run
Building configuration...

Current configuration : 956 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname billiauhome-cisco
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$JIO9$PTTq/iHpS4FhuTmt.k5S1.
enable password
!
no aaa new-model
!
resource policy
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
ip subnet-zero
ip cef
!
!
no ip dhcp use vrf connected
!
!
!
!
!
!
interface FastEthernet0/0
ip address 192.168.1.16 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.10.10.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0/0
no ip address
shutdown
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
ip http server
!
ip access-list extended LabSecurity
deny ip any host 192.168.1.3
deny ip any host 192.168.1.4
permit ip any any
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
password
login
!
end


Procurve


Running configuration:

; J9147A Configuration Editor; Created on release #W.14.72

hostname "home-sw1"
module 1 type J9147A
ip default-gateway 192.168.1.1
vlan 1
name "LAN"
untagged 1-24,37-48
ip helper-address 192.168.1.1
ip address 192.168.1.15 255.255.255.0
no untagged 25-36
exit
vlan 2
name "CISCOLAB"
untagged 25-36
ip address 10.10.10.2 255.255.255.0
exit
console inactivity-timer 5
snmp-server community "public" unrestricted

home-sw1#

Thanks for the configs... and yes, don't see anything wierd and whacky yet...

Let me know if you get the other stuff I recommended in your previous thread, OP.

Regards

Are you referring to the telnetting bit?

No I cannot telnet. I was able to a few times, but like I said, at the same time the RDP dropped..I could no longer telnet in.

Of course now it seems like telnetting and RDP dont work at all, even if for a few seconds like last time. My have just been lucky when I connected yesterday for 10 seconds...it probably shouldnt have worked to begin with if there is a problem somewhere.

I know its not the netbook (host) because I hooked up a PC and did the same thing. I can ping it, but can't telnet, rdp, etc to any host on vlan 2.

So I think I may have just noticed the problem. Look at the red lines in this attachment. My UTM is blocking port 9696, which is that host port number for RDP that I changed in the registry along time ago.

I had no idea packets were traversing my UTM to get to my vlan 2 (procurve) --> Cisco 1840 --> then my host ? hmmm

So my diagram is basically
Internet --> Astaro UTM NIC #1 --> Astaro UTM NIC #2 plugged into Procurve port 47 --> Cisco 1840 0/0 (192.168.1.*) plugged into port on VLAN 1 --> Cisco 1841 0/1 (10.10.10.1) plugged into port on VLAN 2. --> Hosts plugged into any port associated with VLAN 2.

I hope that helps.

This sounds like switch port configuration issue where some ports are configured as part of improper VLAN

Actually maybe it makes sense? My hosts on the 192.168.1.0 VLAN all have their gateway set to 192.168.1.1 which is the UTM. So the firewall should be blocking packets, logically speaking of course.

I believe what you have here is improper network design. Best practice of connection between firewall and router is point-to-point. What I notice here is that you have firewall, router, and hosts within the same broadcast domain, which lead to problems. Communication between router and hosts can be intercepted by the firewall which may lead to sporadic interconnecting issue (among other things).

Here is what I suggested. First you need to choose whether the hosts have gateway of router or firewall. The hosts cannot have both routers and firewall sitting in the same broadcast domain.

What you can do is to setup sub-interfaces on router where one sub-interface has point-to-point connection to the firewall and another sub-interface is a default gateway to hosts. If you need some protection between your lab and your hosts, some ACL can be implemented.

I'm trying to understand all this, so I do apologize. Maybe this is why I should stay away from networking, lol. I don't think I can have a proper setup because I need another NIC for my Astaro UTM Firewall then. I think I need to setup this physically correct before I take your suggestions into account.

With that said...my initial thought was to have the home network (192.168.1.0/24) traverse the UTM only out to the internet. The Cisco Lab hosts (10.10.10.0/24) would traverse the Cisco router, which would route packets to the UTM, and then out the internet. That was my concept.

I think I have it setup that way, but again it may be improper, which is why I'm open to ideas for how to setup this up physically. Maybe the procurve is throwing it all off? I thought I had setup the procurve correctly, because I broke out the home network into 1 vlan, and the cisco lab into vlan 2...wouldn't this be separate broadcasts domains?

I could take your suggestion into account by firewall to router (point to point) and use a crossover cable going from my UTM NIC #2 to the Cisco 0/0 interface. However at that point, then my home network would sit behind the cisco, which is what I DIDNT want.

Thoughts? Thanks aryoba!!

No need to quit yet. This is just one of those learning curves any novices have to go through Additional NIC on your Astaro will be nice, so then you can learn some DMZ aspect. For this first-stage setup though, you can still use what you have now. It will be just a matter of paper design as redesign consideration.With what you have now, you can no longer have the Home network only traverse the Astaro. Just like the rest of your network, all traffic have to go through the Procurve switch and the Cisco router. Those traffic will eventually pass through the Astaro when the traffic are intended to reach the Internet.Let's put the crossover and straight-through cabling aside for a moment. If I were you, I would do some paper design first for feasibility assessment.

If your Astaro is capable of doing 802.1Q (dot 1Q) trunking, then you can setup one between the Astaro and the Procurve switch. Similarly, there will be another trunk between the Cisco router and the Procurve switch.

These trunks will be creating logical ports which is the similar to having multiple (more than 2) physical ports. This way you don't need to add a third NIC on your Astaro.

Here is the best way to lay out this network...but again it would require additional nics.

Let me re-read your post about what I can do currently tho.

Assuming the Astaro is capable to support the trunk, you can have more ports without adding a third NIC on your Astaro.

It does do trunking, I know that much. I'm just trying to grasp what exactly it will do for me, or where you are going with this.

Are you saying creating trunk ports will allow my home network not to traverse the UTM when talking to the cisco network? err wait... you are saying by trunking the ports off the switch, its like having another nic....so I could theortically break it up like my diagram I posted.

Surely that depends on what you are trying to accomplish?
I'd be interested to hear pro's and cons but as far as i can see all you are doing is separating your lab from your domestic internet LAN. If you are going to set up some sort of redundancy (HSRP, VRRP, GLBP) then I can see why you would do it that way.

Me, I have my domestic internet LAN as one of the vlan's on my network, which currently has 5 vlan's. Yes if I make a cock up in the lab I'll probably disconnect myself from the internet, but as that is one of the most important issues I will face in real life it makes more sense (at least to me) to mirror in the lab the sort of networks I will see in the field, at least as far as many SMB's are concerned. It also allows me to play with ACL's and other "firewall" features so I can practice picking and choosing what traffic goes where, when, and how. Being able to ping 8.8.8.8 and resolve www.google.com is a very useful thing to be able to test against when configuring features in IOS.

I just re-read this and don't get this. My home network may traverse the procurve at layer 2, but it DOES not touch the cisco router. At least to my knowledge and tracert tests.According to me! lol I drew it out on paper the way I wanted it and the way it makes sense to me. Unless you can find flaws in it? While I can appreciate introducing the Cisco into my home network and troubleshooting config changes that may break my internet, I don't want to do that. I can just as well, break things on the Cisco Lab and fix them in a real world scenario too.

All I'm trying to do here at the end of the day, is use what equipment I have to isolate the two networks, but at the same time, talk to one another (to a point). But again, not having home network, talk to the Cisco for internet, just to talk to the Cisco Lab hosts.

Am I out of my league here? lol I feel like how I have it setup now works...although maybe improper? But without additional NICS for either new interfaces or configuring trunk ports on the astaro, I'm kinda stuck.

Assuming you are able to configure the Astaro to trunk to Procurve, here are the things you can do.
1. Setup trunk port between Astaro and the switch. Similarly setup trunk port between Cisco router and the switch
2. Create multiple VLAN to go through the trunk ports. Make sure that only VLANs 100, 200, and 300 to pass through the Cisco router trunk port. The Astaro trunk port will be only for different VLAN (i.e. VLANs 2 and 3)
3. Dedicate VLAN 2 for only the Home network using the Astaro as gateway.
4. Dedicate VLAN 3 for point-to-point between Astaro and Cisco router
5. VLANs 100, 200, 300 termination stay at Cisco router (as they are now)
6. Create necessary static routes and security zones
7. Test connectivity

This is where I'm slightly confused. I already have intervlan routing on my procurve acting as a layer 2 switch. Creating the trunk just allows intervlan routing between vlans or switches (if I had multiple). That's the point of the router and using 802.1q correct?

If you have inter vlan routing then your pro-curve is acting as a layer 3 switch assuming it has that functionality. If it doesn't then the Astaro or one of the routers will need to handle the routing.

That's the thing. IP routing isn't even enabled. Only ip addresses are assigned to the two vlans.

Oh and yes it does have that functionality

So basically the traffic flow would be:

RDP client -> UTM -> static route to Cisco -> RDP server

and then back again

RDP server -> Cisco -> RDP client

If thats the case, then likely what is happening is the UTM is creating a session for the flow (client -> server), but after not seeing anything come back in the opposite direction through the session (server -> client) it drops it. Probably because it thinks the flow is a dud (one way data flow.)

You'll probably find you can fix it by adding a static route on your RDP client box to point the lab subnet directly at the Cisco to bypass the UTM.

The reason for the asymmetric dataflow above is because your RDP client knows its default gateway as the UTM and sends all its packets there. The UTM knows to route packets for the lab subnet to the Cisco so punts them over to it. But on the way back, the Cisco knows that the RDP client is directly connected to one of its interfaces (due to same subnet) so sends the packets diretly to the client instead of back through the UTM.

Maybe, just maybe, if the UTM can do ICMP redirects you might be able to fix it as it would tell the client "hey you can actually just go straight to the Cisco instead of me" but as a firewall I dont like those chances for some reason.