Link to home
Start Free TrialLog in
Avatar of UnifiedIT
UnifiedIT

asked on

Wierd Remote access networking problem

Hi there,

I am having a wierd problem accessing a remote network, lets call this network AWAY.

Here is the situation, When I am at my corporate office and want to access AWAY via Terminal Services, SSH, or a HTTP Remote management browser (Linksys Firewall Browser) etc... I cant reach it from my OFFICE network.

Now here is where it starts to get wierd.

I can connect VIA Remote Desktop/ SSH or whatever from my DMZ, or another Network.

I can connect to other IP addresses via RDP etc.. from OFFICE

OFFICE to AWAY connections used to work

Now the last thing I just tried was NATTING a new IP to my computer at OFFICE and attempting to connect to AWAY with the new Public IP. This also fails?

So, it looks like there is something in my Firewall (3Com Superstack 3) that is restricting a connection to my AWAY IP address.


I have specifically made policies to allow connections to the AWAY address be allowed from the LAN at OFFICE and looked for anything that specifies the AWAY address, but to no avail.

Does it sound like I am on the right path, or have I overlooked something obvious?

Thanks,

Mike
ASKER CERTIFIED SOLUTION
Avatar of rccguy
rccguy

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of UnifiedIT
UnifiedIT

ASKER

thanks rccguy,

Yeah, I can connect to AWAY from other networks, including the DMZ at my OFFICE.

I have been trying to track it back, but Its really wierd ( like I stated in my title) :)

SOLUTION
Avatar of The--Captain
The--Captain
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Well there is definetly a policy setup in your firewall that is preventing you from connecting from Office.  I would suggest going through them and see what might be giving you the problem.  If your comfortable with posting it I'll try to help you figure it out.  We'd also need to know the type of firewall your using.  I'm betting that SSH or some service is turned off or something as been setup to restrict access to outside networks in the firewall.  To verify try a tracert on the away network and see where if the problem is accessing the network or if it could be a protocol issue.
Ok...

I cant ping or trace route the public IP of the remote network from the OFFICE LAN.

I can tracert/ping the AWAY network from my DMZ though..

The same goes for the gateway that I try to ping for the remote networks ISP?

All I see when I tracert is the first hop (my routers ethernet port) then it dies?

It look like it must either be my firewall, or possibly something along the line of ACL's on my routers? Ill have to check into some more here!

Any other ideas? Opinions etc...
rcguy,

one more thing before I post policies..

Its a 3com superstack 3 firewall and I because I see that all the services that I try to connect to at this IP (AWAY) are not working, lets just go with the http interface at the AWAY site. Since it was http, I would think that any policy would almost have to be specific to the AWAY IP address? Simply because I can use this, SSH, RDP etc on other remote addresses, my last post suggests that the firewall has a problem with the whole subnet!

If I jump a subnet up or down, I can ping those.... for ex I can ping x.x.118.whatever, cant ping x.x.119.whatever, can ping x.x.120.whatever..  I know that comcast owns the x.x.118.0/23 block, so the first two fall within their network...

hmmm...
No, no, not tracert (although that can help some), but tcptraceroute...

tcptraceroute (originally a linux tool but I think there are now windoze equivalents) will send packets on a particular tcp port (ie ssh), but otherwise behaves exactly like traceroute.  Using tcptraceroute will tell you exactly who is blocking your packets.

Cheers,
-Jon

Thanks for the help guys.

This ended up being something kinda simple.

First, thanks for the new tool there Captain, that will be helpful in the future, it didnt exactly solve my problem this time, but helped lead to me getting this.

I went back and looked at what was changed along with policies as rc suggested. It was actually a VPN SA that I was testing for the remote network. Apparently, the network info that I entered was wrong, and as soon as I deleted the SA, all was well.

Thank you for you help again.

Mike