LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Other *NIX Forums > Solaris / OpenSolaris
User Name
Password
Solaris / OpenSolaris This forum is for the discussion of Solaris, OpenSolaris, OpenIndiana, and illumos.
General Sun, SunOS and Sparc related questions also go here. Any Solaris fork or distribution is welcome.

Notices


Reply
  Search this Thread
Old 12-10-2013, 08:51 AM   #1
TronCarter
Member
 
Registered: Oct 2009
Posts: 36

Rep: Reputation: 0
Can't SSH from out of subnet IP


I can SSH into my Solaris 10 box just fine from the same subnet, for instance:

server: 192.168.23.23
client: 192.168.23.46

Both are on the same side of the enterprise firewall. However, when I am on the outside of the firewall and use the company VPN, I am unable to SSH into the server. It just waits for a while and says "unable to connect". The VPN is in an entirely different IP range of:

10.40.x.x

This is the only thing I can see as a difference. I am able to SSH through the VPN to other linux boxes inside the firewall, just not this Solaris 10 box.

Is it a netmask issue? Currently it is 255.255.255.0.

I installed Solais myself, so I know I didn't set up any IP filtering.

Tron
 
Old 12-10-2013, 09:00 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
Very little to go on, but presuming there are no other firewalls between your endpoints, and no restrictions on the VPN configuration itself, I'd be checking the return route. Maybe the default gateway on the server is wrong? Can you SSH to another local box and then connect to it?
 
Old 12-10-2013, 09:00 AM   #3
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
I guess the route to the 10.40.0.0/16 network is not know to the solaris machines. Also this depends on the overall network architecture.
Could just check what routes are present on the other machines and compare those with the faulty ones.

To make sure its a route issue you could run a tcpdump session or just create a log target from and to this network with iptables.

*damn to late*
 
Old 12-10-2013, 09:08 AM   #4
TronCarter
Member
 
Registered: Oct 2009
Posts: 36

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by acid_kewpie View Post
Very little to go on, but presuming there are no other firewalls between your endpoints, and no restrictions on the VPN configuration itself, I'd be checking the return route. Maybe the default gateway on the server is wrong? Can you SSH to another local box and then connect to it?
Yes, I can SSH to other local boxes and then SSH to it.

Code:
netstat -rn

default              192.168.23.1         UG        1       2540 igb0
 
Old 12-10-2013, 09:09 AM   #5
TronCarter
Member
 
Registered: Oct 2009
Posts: 36

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by zhjim View Post
I guess the route to the 10.40.0.0/16 network is not know to the solaris machines. Also this depends on the overall network architecture.
Could just check what routes are present on the other machines and compare those with the faulty ones.

To make sure its a route issue you could run a tcpdump session or just create a log target from and to this network with iptables.

*damn to late*
How do I check what routes are present on the other machines?
 
Old 12-10-2013, 09:30 AM   #6
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
Code:
ip route
or
Code:
route
should give you some output. The latter should be known by more than one OS.
 
Old 12-10-2013, 02:15 PM   #7
TronCarter
Member
 
Registered: Oct 2009
Posts: 36

Original Poster
Rep: Reputation: 0
From a working linux box (I can VPN SSH into it):

# route

Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.23.1    0.0.0.0         UG    0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
192.168.23.0    *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     0      0        0 eth0
From the Solaris box (I believe the netstat command is equivalent on Solaris):

Code:
# netstat -rnv

IRE Table: IPv4
  Destination             Mask           Gateway          Device Mxfrg Rtt   Ref Flg  Out  In/Fwd 
-------------------- --------------- -------------------- ------ ----- ----- --- --- ----- ------ 
default              0.0.0.0         192.168.23.1         igb0    1500*    0   1 UG   58219      0 
10.0.0.0             255.0.0.0       10.0.0.10            igb1    1500*    0   1 U       17      0 
192.168.23.0         255.255.255.0   192.168.23.173       igb0    1500*    0   1 U       75      0 
192.168.169.0        255.255.255.0   192.168.169.110      ibd0    2044*    0   1 U        0      0 
224.0.0.0            240.0.0.0       192.168.23.173       igb0    1500*    0   1 U        0      0 
127.0.0.1            255.255.255.255 127.0.0.1            lo0     8232*    0   3 UH      36      0
ibd0 is an infiniband card, but I don't believe it's involved in the problem.
 
Old 12-11-2013, 01:56 AM   #8
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
right, so you've a route for 10.0.0.0/8 via 10.0.0.10 which doesn't exist on the first box.
 
Old 12-11-2013, 05:56 AM   #9
TronCarter
Member
 
Registered: Oct 2009
Posts: 36

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by acid_kewpie View Post
right, so you've a route for 10.0.0.0/8 via 10.0.0.10 which doesn't exist on the first box.
Oh, I forgot to mention that igb1 is connected to a SAN that has an IP of 10.0.0.50. igb1 doesn't "see the outside", it only sees a switch and the SAN. I think you might be on to something though, because the range of IP's that can't connect (on igb0) are all 10.40.x.x, 10.80.x.x, and 10.82.x.x. So if I were to change the subnet mask of that route to 255.255.255.0, would that (in theory) make only 10.0.0.x IP's route to igb1, and 10.40.x.x route normally?
 
Old 12-11-2013, 06:09 AM   #10
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
yes, it would. But is that a locally attached subnet? If so there shouldn't be any route tehre at all., as it's already local.
 
Old 12-11-2013, 06:31 AM   #11
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
As far as the usage of ip addr add 10.0.0.10/24 goes it creates a route to the 10.0.0.0/24 network automaticaly. So I'd say that one needs a route. Or is there something I dont understand the word "local" wrong.

Anyways. Create a more specific route to the SAN. Either just a very small subnet like /30 and have the other 10.0.0.0/8 routes go through the default gateway (Could just delete that one). Or create routes for 10.40.0.0/16 through the default gw. Also add 10.80/16 and 10.82/16. Also I would just create a more strict subnet for the SAN.
 
Old 12-11-2013, 07:37 AM   #12
TronCarter
Member
 
Registered: Oct 2009
Posts: 36

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by acid_kewpie View Post
yes, it would. But is that a locally attached subnet? If so there shouldn't be any route tehre at all., as it's already local.
Yes, the SAN and igb1 (as well as some igb1's in other computers) are manually configured for 10.0.0.x and they are only seen to each other. igb0 is the connection to the LAN that users log in on. I suppose we could have chosen any IP range when we initially set the SAN up, but didn't see this as being a problem.

zhjim, I am sort of following you, but I'm not real clear with the /24, /16, etc parts. You are saying to create a route to 10.40.0.0 with a mask of 255.255.0.0? (as well as 10.80.x.x and 10.82.x.x) Would I need to delete anything, or just add those three? I think it makes sense to also delete the 10.0.0.0 255.0.0.0, but it's early and I'm no expert.

If I were to just change the mask of the existing route to 255.255.0.0, would it just route all 10.0.x.x traffic to igb1, and all other traffic (10.40.x.x) would be handled normally by igb0, the adapter the request came in on?
 
Old 12-11-2013, 08:59 AM   #13
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
Quote:
Originally Posted by TronCarter View Post
zhjim, I am sort of following you, but I'm not real clear with the /24, /16, etc parts.
The /24, /16 are just other notations for subnets. like /24 is 255.255.255.0. Its a binary thing. 255.255.255.0 has 24bits set to one.

Quote:
Originally Posted by TronCarter View Post
If I were to just change the mask of the existing route to 255.255.0.0, would it just route all 10.0.x.x traffic to igb1, and all other traffic (10.40.x.x) would be handled normally by igb0, the adapter the request came in on?
Sounds good also I would go one subnet down to 255.255.255.0. This would leave you with 254 possible host address to use for the SAN and similar things.
This route (pun intended) would also make the creation of routes for 10.40.0.0 and alike unnecessary. Due to the default route handeling them as you already noted.


As a generel rule of thumb I normaly keep the netmask as small as possible. By this most of the time have the default route is doing its job and you dont have to worry that much.

Last edited by zhjim; 12-11-2013 at 09:00 AM.
 
Old 12-11-2013, 09:33 AM   #14
TronCarter
Member
 
Registered: Oct 2009
Posts: 36

Original Poster
Rep: Reputation: 0
IT WORKS!!!!!! In /etc/netmasks I added the line:

Code:
10.0.0.0       255.255.255.0
and restarted the network. I can now connect from the VPN.

Thank you zhjim and acid_kewpie for all of your help!!
 
Old 12-11-2013, 09:47 AM   #15
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
Your welcome. Please mark the thread as solve. Use the "Thread Tools" at the top of the page.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
web access works from same subnet but not from different subnet linuxandtsm Linux - Newbie 2 11-27-2012 02:23 PM
[SOLVED] VLAN with 2 Router and 2 Subnet - Is device in different subnet works? velusawme Linux - Networking 2 07-23-2011 10:16 AM
two NICs on same subnet and ssh independently powah Linux - Networking 5 04-09-2007 12:56 PM
no outgoing ssh connection in subnet with shorewall/squid linux_marine Linux - Networking 2 11-21-2006 02:30 PM
Can't access ssh or httpd from outside subnet vortech Linux - Networking 1 10-03-2002 04:39 PM

LinuxQuestions.org > Forums > Other *NIX Forums > Solaris / OpenSolaris

All times are GMT -5. The time now is 09:36 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration