I have 5 offices in Texas VPN’d into our Seattle office where we have two Solaris Servers. I can ping the Solaris servers from within our Seattle office; however I cannot from the remote offices. I have checked the VPNs and I can ping any other piece of equipment from the remote sites except the Seattle servers.
When trying to ping a computer at one of the remote sites from the Solaris servers to a computer I get the following reply: ” ICMP Communication Administratively Prohibited from gateway”.
I’m questioning the ip configuration of our Solaris servers in Seattle. When running the command “/sbin/ifconfig -a/” , I received the following in return:
lo0: flags=1000849
mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0:
flags=1000843
mtu 1500 index 2 inet 10.10.10.21 netmask ff000000
broadcast 10.255.255.255 ether 0:3:ba:18:6f:5
The segment in Seattle is 10.10.10.0 with a subnet of 255.255.255.0 and a Gateway 10.10.10.1; however, this is not what I see above. One of the remote sites uses the 10.140.59.0 segment. Do I have to configure routing tables within each Solaris or just properly configure the ip settings? Can you comment?
Well, my first comment is “um, that’s far beyond my own understanding of networking and network configuration”, but fortunately one of the Friends of Ask Dave Taylor has come to the rescue with this detailed response:
interesting … but you do not tell us enough .. for example, is the internet connection via private or public networks? i assume that it is provide by public networks thus there is some “confusion”. Also assume that you use some kind of hardware which provides for the VPN tunnels as between remote office and Seattle servers. This I assume because you mention below that the route is 10.10.10.1 which is a class A private IP Address space.
I hope the explanation below helps highlight the position.
Seattle | Remote |
Private IP 10.10.10.21 | Private IP 192.168.0.10 |
Router IP 10.10.10.1 | Router IP 192.168.0.1 |
Public Interface IP xxx.xxx.xxx.xxx | Public Interface yyy.yyy.yyy.yyy |
VPN Hardware listens on xxx.xxx.xxx.xxx
When VPN Hardware listens on xxx.xxx.xxx.xxx and gets a connection from yyy.yyy.yyy.yyy it will SPAWN a local looking IP Address eg. 10.10.10.55 for itself and assign the other side with a corresponding local looking IP Address eg. 10.10.10.77
The remote side will then start sending all outgoing data from virtual interface 10.10.10.77 (Remote Virtual) –> 10.10.10.55 (Seattle Virtual)
Alongside this, the default route will usually also be 10.10.10.55.
When the Seattle Servers get any incoming on the virtual interface of 10.10.10.55 it treats it as a trusted network connection and assumes that anything incoming with the virtual IP of 10.10.10.77 (Remote) is part of its on LAN.
Note that ALL VPN connectivity server/client is controled by your HARDWARE VPNs. Running ifconfig on the Solaris will do nothing but report whatever static IP assigned to the local NIC.
Its just that the Solaris machines will treat 10.10.10.77 and .55 as local area connections and “should” not be able to notice that it is truely a VPN connection or tunnel.
The important thing to remember here is that VPNs _do not_ use “true” IP Addresses assigned by DHCP/PPP in the usual way. Thats probably why your remote site with 10.140.59.x (real IP) reports accordingly.
To further illustrate the point. If I choose to dial up normally with plain of modem .. the ISP will _assign_ my connection with an IP and for itself with another IP. After that all my outgoing/incoming traffic will be via my assigned IP routed out to the other side where it gets forwarded accordingly.
Quite similar with VPN when the VPN server listens on an interface for incoming request and assignes one for itself and another for the client.. even thru a regular DSL (in otherwords public network).
Hence if you have the software for it … you may connect to your Seattle VPN connection if the hardware will accept the incoming VPN request and start your VPN session … even if you were at a cyber-cafe with some outgoing public IP Address space.
Cannot PING
Ping operates at ICMP level and ordinarily root level and/or suid level access is requires to even run ping. Note the suid bit on ping may be removed.
It seems strange to me that if you can ping a .. say network printer at Seattle from remote side, you should also be able to ping your Solaris Servers… one possible explnation is that you may have some kind of IDS (Intrusion Detection System/Prevention) on the Solaris machines and if it cannot make out the incoming ping it rejects it.
Assuming you use Ipsec .. you will need to include #ping -P [blah] coz it needs to go out using the ESP transport mode… i got no experience here but seen man ping. It may be relevant.
Hope this helps.
kjteoh