Cluster not visible to external IP

Hello
We have SQL 2000 with two servers clustered (one is a failover) to have one
named SQL server. This is fine internally, but external VPN connections
can't reach this server (all other machines are reachable). Permissions not
an issue.
Anyone have any ideas on where to start/look?
ThanksVPN connections will have to be enabled to the underlying node IPs, not the
virtual server IPs.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PB" <hoopitup@.gmail.com> wrote in message
news:OdM$Zy47FHA.1148@.tk2msftngp13.phx.gbl...
> Hello
> We have SQL 2000 with two servers clustered (one is a failover) to have
> one named SQL server. This is fine internally, but external VPN
> connections can't reach this server (all other machines are reachable).
> Permissions not an issue.
> Anyone have any ideas on where to start/look?
> Thanks
>|||We are using the cluster name rather than IP. Will try the actual node name
now, but the only thing then is there is no failover protection.
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:OkktM047FHA.3224@.TK2MSFTNGP09.phx.gbl...
> VPN connections will have to be enabled to the underlying node IPs, not
> the virtual server IPs.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "PB" <hoopitup@.gmail.com> wrote in message
> news:OdM$Zy47FHA.1148@.tk2msftngp13.phx.gbl...
>|||When a client (in this case the firewall) receives an IP packet from a
virtual instance, the sender IP address is the node's physical address, not
the virtual address. You can still connect via virtual IP for name and ARP
resolution, but you will have to enable VPN access via the physical node
addresses.
GNH
"PB" <hoopitup@.gmail.com> wrote in message
news:eUtFO347FHA.1248@.TK2MSFTNGP14.phx.gbl...
> We are using the cluster name rather than IP. Will try the actual node
> name now, but the only thing then is there is no failover protection.
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:OkktM047FHA.3224@.TK2MSFTNGP09.phx.gbl...
>

Cluster not visible to external IP

Hello
We have SQL 2000 with two servers clustered (one is a failover) to have one
named SQL server. This is fine internally, but external VPN connections
can't reach this server (all other machines are reachable). Permissions not
an issue.
Anyone have any ideas on where to start/look?
ThanksVPN connections will have to be enabled to the underlying node IPs, not the
virtual server IPs.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PB" <hoopitup@.gmail.com> wrote in message
news:OdM$Zy47FHA.1148@.tk2msftngp13.phx.gbl...
> Hello
> We have SQL 2000 with two servers clustered (one is a failover) to have
> one named SQL server. This is fine internally, but external VPN
> connections can't reach this server (all other machines are reachable).
> Permissions not an issue.
> Anyone have any ideas on where to start/look?
> Thanks
>|||We are using the cluster name rather than IP. Will try the actual node name
now, but the only thing then is there is no failover protection.
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:OkktM047FHA.3224@.TK2MSFTNGP09.phx.gbl...
> VPN connections will have to be enabled to the underlying node IPs, not
> the virtual server IPs.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "PB" <hoopitup@.gmail.com> wrote in message
> news:OdM$Zy47FHA.1148@.tk2msftngp13.phx.gbl...
>> Hello
>> We have SQL 2000 with two servers clustered (one is a failover) to have
>> one named SQL server. This is fine internally, but external VPN
>> connections can't reach this server (all other machines are reachable).
>> Permissions not an issue.
>> Anyone have any ideas on where to start/look?
>> Thanks
>|||When a client (in this case the firewall) receives an IP packet from a
virtual instance, the sender IP address is the node's physical address, not
the virtual address. You can still connect via virtual IP for name and ARP
resolution, but you will have to enable VPN access via the physical node
addresses.
GNH
"PB" <hoopitup@.gmail.com> wrote in message
news:eUtFO347FHA.1248@.TK2MSFTNGP14.phx.gbl...
> We are using the cluster name rather than IP. Will try the actual node
> name now, but the only thing then is there is no failover protection.
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:OkktM047FHA.3224@.TK2MSFTNGP09.phx.gbl...
>> VPN connections will have to be enabled to the underlying node IPs, not
>> the virtual server IPs.
>> --
>> Geoff N. Hiten
>> Senior Database Administrator
>> Microsoft SQL Server MVP
>>
>> "PB" <hoopitup@.gmail.com> wrote in message
>> news:OdM$Zy47FHA.1148@.tk2msftngp13.phx.gbl...
>> Hello
>> We have SQL 2000 with two servers clustered (one is a failover) to have
>> one named SQL server. This is fine internally, but external VPN
>> connections can't reach this server (all other machines are reachable).
>> Permissions not an issue.
>> Anyone have any ideas on where to start/look?
>> Thanks
>>
>sqlsql

Cluster not visible to external IP

Hello
We have SQL 2000 with two servers clustered (one is a failover) to have one
named SQL server. This is fine internally, but external VPN connections
can't reach this server (all other machines are reachable). Permissions not
an issue.
Anyone have any ideas on where to start/look?
Thanks
VPN connections will have to be enabled to the underlying node IPs, not the
virtual server IPs.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PB" <hoopitup@.gmail.com> wrote in message
news:OdM$Zy47FHA.1148@.tk2msftngp13.phx.gbl...
> Hello
> We have SQL 2000 with two servers clustered (one is a failover) to have
> one named SQL server. This is fine internally, but external VPN
> connections can't reach this server (all other machines are reachable).
> Permissions not an issue.
> Anyone have any ideas on where to start/look?
> Thanks
>
|||We are using the cluster name rather than IP. Will try the actual node name
now, but the only thing then is there is no failover protection.
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:OkktM047FHA.3224@.TK2MSFTNGP09.phx.gbl...
> VPN connections will have to be enabled to the underlying node IPs, not
> the virtual server IPs.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "PB" <hoopitup@.gmail.com> wrote in message
> news:OdM$Zy47FHA.1148@.tk2msftngp13.phx.gbl...
>
|||When a client (in this case the firewall) receives an IP packet from a
virtual instance, the sender IP address is the node's physical address, not
the virtual address. You can still connect via virtual IP for name and ARP
resolution, but you will have to enable VPN access via the physical node
addresses.
GNH
"PB" <hoopitup@.gmail.com> wrote in message
news:eUtFO347FHA.1248@.TK2MSFTNGP14.phx.gbl...
> We are using the cluster name rather than IP. Will try the actual node
> name now, but the only thing then is there is no failover protection.
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:OkktM047FHA.3224@.TK2MSFTNGP09.phx.gbl...
>

Client Network Utility cannot create alias for VPN SQL server connection?

I am trying to connect two SQL servers in different non-trusted domains.
SQLServer11 in Domain A and SQLServer22 in domain B. This is through a VPN
connection. Domain A has the VPN server. On SQLServer22 I could ping
SQLServer11.mydomain.local at IP address 192.168.100.50. On SQLServer22 I
use the client network utility to create an alias for SQLServer11 as
follows:
Network Libraries: TCP/IP
Server name: 192.168.100.50
Port No: 1433
Server alias: SQLServer11
Then I registered the new SQLServer11 in enterprise manager. But I keep
getting the error message "SQL server does not exist or access
denied.ConnectionOpen(Connect())" .
Why is this so? And how can I rectify the problem'If you use ping -a <ip address> does it bring back the correct name for the
server? If you ping SQLServer11 does it return the proper ip address? If
you are using NT authentication to register then try SQL authentication..
Verify that it is using port 1433 and that SQL Server is actually listening
on TCP/IP.
Rand
This posting is provided "as is" with no warranties and confers no rights.