can connect to some servers

Hello:  I am having a picular problem with vpn'ing into work.  I have 

the system setup and working in that I can get onto my work lan via
vpn 
thru our BM3.7sp1 server.  The problem is that I can see only about
1/2 
of the servers.  I can see no pattern to shed light on this behavior. 

All servers are NW6sp2.  I can ping only those servers that I can 
browse, all others time out.  I can not see any servers on our branch 

subnets (10.2.1.xxx and 10.3.1.xxx) which are protected networks, and
I 
can not see three of six servers on our main subnet (10.1.1.xxx).

Help always appreciated, Chris Mosentine




0
N0
2/11/2003 2:13:21 AM
novell.bordermanager.vpn 2677 articles. 0 followers. Follow

8 Replies
223 Views

Similar Articles

[PageSpeed] 51
Get it on Google Play
Get it on Apple App Store

Do all the servers have default routes set up in LAN Static Routing in

INETCFG?

Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on 
BorderManager, go to http://nscsysop.hypermart.net ***




0
Craig
2/11/2003 3:42:36 AM
Craig Johnson wrote:
> Do all the servers have default routes set up in LAN Static Routing
in 
> INETCFG?
> 
> Craig Johnson
> Novell Support Connection SysOp
> *** For a current patch list, tips, handy files and books on 
> BorderManager, go to http://nscsysop.hypermart.net ***
> 
Yes.  All servers have thier default route pointing to the vpn server
as 
well as two other routes for our other subnets.  Repeat, ALL the same.


default router 10.1.1.19
10.2.1.0     10.1.1.1 (internal router for p2p t1)
10.3.1.0     10.1.1.1 (internal router for p2p t1)




0
N0
2/11/2003 3:32:08 PM
This is definitely a routing issue, to start with, though you may also

have name resolution issues once you solve the routing issue.

To start with, the only real test you need to do is to ping the 
internal server IP addresses.   If you cannot do that, you won't get 
anything else to work to them either.

I would start by checking where the ICMP packets are going.

On internal server, enable IP filtering, or just load iPFLT.  Then set

filter debug=on, and then set icmp forward filter debug=on.  You can
do 
this on the BMgr server also.

This should show all ICMP packets (not being filtered) hitting the 
server (in the logger screen for NW6).   Start pinging.

If you see ICMP packets getting to the internal servers, and not going

back, then there is a problem on the internal server.   Otherwise,
it's 
probably an issue on the BMgr server.

This simple test can tell an awful lot about routing issues.

Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on 
BorderManager, go to http://nscsysop.hypermart.net ***




0
Craig
2/13/2003 5:40:45 AM
Craig Johnson wrote:
> This is definitely a routing issue, to start with, though you may
also 
> have name resolution issues once you solve the routing issue.
> 
> To start with, the only real test you need to do is to ping the 
> internal server IP addresses.   If you cannot do that, you won't get

> anything else to work to them either.
> 
> I would start by checking where the ICMP packets are going.
> 
> On internal server, enable IP filtering, or just load iPFLT.  Then
set 
> filter debug=on, and then set icmp forward filter debug=on.  You can
do 
> this on the BMgr server also.
> 
> This should show all ICMP packets (not being filtered) hitting the 
> server (in the logger screen for NW6).   Start pinging.
> 
> If you see ICMP packets getting to the internal servers, and not
going 
> back, then there is a problem on the internal server.   Otherwise,
it's 
> probably an issue on the BMgr server.
> 
> This simple test can tell an awful lot about routing issues.
> 
> Craig Johnson
> Novell Support Connection SysOp
> *** For a current patch list, tips, handy files and books on 
> BorderManager, go to http://nscsysop.hypermart.net ***
> 
Craig:  One step forward and two steps back.

I checked my routes, and I did have some problems.  I have now checked

them all and they seem correct.  All internal servers have there
default 
  route to the BM server.

Now, tonight, I gave it another try.  This time I can establish a vpn 

connection, but I cannot see the tree.  BUT I can PING ALL INTERNAL 
SERVERS.  I defined all IP addresses in my local host file.

Could use some more help please????

Chris




0
N0
2/14/2003 1:10:28 AM
In article <8mX2a.1634$Hm3.500@prv-forum2.provo.novell.com>, 
@N0$pam.chartermi.net wrote:
> Now, tonight, I gave it another try.  This time I can establish a
vpn 
> connection, but I cannot see the tree.  BUT I can PING ALL INTERNAL 

> SERVERS.  I defined all IP addresses in my local host file.

OK, now we are almost done.

You have a simple name resolution issue.  SLP is not working over the 

VPN, and VPN has a long history of that.

Best to get the latest VPN client & patch (see tip #1 at the URL
below) 
if you want to try to get SLP working.  With that client, you need to 

set up a static DA entry in the remote PC client32 settings.  Of
course 
you need a DA on the internal network.

I generally don't bother doing that, but instead sidestep the issue by

putting the internal server names and addresses in my remote PC's
HOSTS 
file.  Add the tree name onto the same line as one of the servers.

Now establish a VPN, and ping every server by name.  Also the tree
name. 
If you can do that, you should be able to easily log in to NDS and run
a 
login script.  (Use Client32 login, not the integrated VPN client 
login).

You can also use Client32 advanced login menu, pointing to the IP 
address of one of the servers to get logged in, but your drive
mappings 
will probably fail unless you are using NDS syntax for the mappings.

This is all documented in my BMgr 3.x book - see URL below.


Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on 
BorderManager, go to http://nscsysop.hypermart.net ***




0
Craig
2/14/2003 3:16:30 AM
Craig Johnson wrote:
> In article <8mX2a.1634$Hm3.500@prv-forum2.provo.novell.com>, 
> @N0$pam.chartermi.net wrote:
> 
>>Now, tonight, I gave it another try.  This time I can establish a
vpn 
>>connection, but I cannot see the tree.  BUT I can PING ALL INTERNAL 

>>SERVERS.  I defined all IP addresses in my local host file.
> 
> 
> OK, now we are almost done.
> 
> You have a simple name resolution issue.  SLP is not working over
the 
> VPN, and VPN has a long history of that.
> 
> Best to get the latest VPN client & patch (see tip #1 at the URL
below) 
> if you want to try to get SLP working.  With that client, you need
to 
> set up a static DA entry in the remote PC client32 settings.  Of
course 
> you need a DA on the internal network.
> 
> I generally don't bother doing that, but instead sidestep the issue
by 
> putting the internal server names and addresses in my remote PC's
HOSTS 
> file.  Add the tree name onto the same line as one of the servers.
> 
> Now establish a VPN, and ping every server by name.  Also the tree
name. 
> If you can do that, you should be able to easily log in to NDS and
run a 
> login script.  (Use Client32 login, not the integrated VPN client 
> login).
> 
> You can also use Client32 advanced login menu, pointing to the IP 
> address of one of the servers to get logged in, but your drive
mappings 
> will probably fail unless you are using NDS syntax for the mappings.

> 
> This is all documented in my BMgr 3.x book - see URL below.
> 
> 
> Craig Johnson
> Novell Support Connection SysOp
> *** For a current patch list, tips, handy files and books on 
> BorderManager, go to http://nscsysop.hypermart.net ***
> 
Boy are you a big help.  BTW, I have purchased and regularly use you 
tutorials.  I can login now except for the BM server itself.  I saw a 

note concerning this issue were you suggested adding a static nat 
translation to the BM server.  I have dynamic nat setup on the public 

interface.  I assume I would change this to static AND dynamic and add
a 
nat entry of 10.1.1.19 to 10.1.1.19 (private ip of BM server)?

I took your advice and added the ip addresses to my local host file.

With regards to the internal routing issue I had to resolve, now that
I 
look at my fix, this reminded me that I had this same issue about one 

year ago.  Inetcfg showed the routing to be correct, but TCPCON did
not. 
  Changing the default route in inetcfg and reinitializing did not
work, 
tcpcon still showed the wrong default route.  Only after I deleted the

default route in BOTH inetcfg and tcpcon, and then reinitialized, adn 

then setup the default route anew did it take.

Chris




0
N0
2/14/2003 1:48:14 PM
Craig Johnson wrote:
> In article <8mX2a.1634$Hm3.500@prv-forum2.provo.novell.com>, 
> @N0$pam.chartermi.net wrote:
> 
>>Now, tonight, I gave it another try.  This time I can establish a
vpn 
>>connection, but I cannot see the tree.  BUT I can PING ALL INTERNAL 

>>SERVERS.  I defined all IP addresses in my local host file.
> 
> 
> OK, now we are almost done.
> 
> You have a simple name resolution issue.  SLP is not working over
the 
> VPN, and VPN has a long history of that.
> 
> Best to get the latest VPN client & patch (see tip #1 at the URL
below) 
> if you want to try to get SLP working.  With that client, you need
to 
> set up a static DA entry in the remote PC client32 settings.  Of
course 
> you need a DA on the internal network.
> 
> I generally don't bother doing that, but instead sidestep the issue
by 
> putting the internal server names and addresses in my remote PC's
HOSTS 
> file.  Add the tree name onto the same line as one of the servers.
> 
> Now establish a VPN, and ping every server by name.  Also the tree
name. 
> If you can do that, you should be able to easily log in to NDS and
run a 
> login script.  (Use Client32 login, not the integrated VPN client 
> login).
> 
> You can also use Client32 advanced login menu, pointing to the IP 
> address of one of the servers to get logged in, but your drive
mappings 
> will probably fail unless you are using NDS syntax for the mappings.

> 
> This is all documented in my BMgr 3.x book - see URL below.
> 
> 
> Craig Johnson
> Novell Support Connection SysOp
> *** For a current patch list, tips, handy files and books on 
> BorderManager, go to http://nscsysop.hypermart.net ***
> 
Sorry for not aksing this in my last post.  I have an internal AIX box

which I cannot ping (my linux mySQL server does ping).  I assume it is

also due to a routing issue on that machine, not simply becasue it is 

running AIX??

Chris




0
N0
2/14/2003 1:49:48 PM
In article <0u63a.1922$Hm3.1014@prv-forum2.provo.novell.com>, 
@N0$pam.vrapc.com wrote:
> Sorry for not aksing this in my last post.  I have an internal AIX
box 
> which I cannot ping (my linux mySQL server does ping).  I assume it
is 
> also due to a routing issue on that machine, not simply becasue it
is 
> running AIX??
>
It has nothing to do with AIX, but there could be various causes.   It

may not have a correct default route, or it could be programmed to
block 
ICMP, etc.

On the other question, yes you have it correct regarding the static
NAT 
of the private IP address to itself.  Once you do that, you should be 

able to ping the private IP address over the VPN.

Note that the static NAT trick is not supposed to be needed with NAT 
6.00d or 6.00e, though I sometimes still have to do that.  The latest
NAT 
is included in the BM36SP2A / BM37SP1 patches.

Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on 
BorderManager, go to http://nscsysop.hypermart.net ***




0
Craig
2/17/2003 4:05:50 AM
Reply: