Here are some ideas:
a) tcpd - tcp wrappers?; check hosts.allow and hosts.deny in /etc.
** There is nothing in any of the host* files to indicate any issues with
VPN or a specific IP Address.
b) Firewall dropping packets according to preset rules? -- iptables,
ipchains, PIX, etc.
** This began in the middle of a work day,,,out of the blue so to speak.
No one was working on the firewall at that time or before for that matter.
We reassigned the available IP addresses to exclued the *.201 and now all is
working just fine. Would like to know why tho.
c) Routing? -- VPN subnet does not know how to get to the Linux server?
** Two other consultants are getting in just fine, as long as they are not
the first to login during the day. The first person to attempt to login
gets assigned the *.*.*.201 address and is denied access to the Linux server
programs.
d) A less likely scenario is that the service the VPN client needed to
connect to required a reverse resolution for the ip, and the forced IP
address supplied to the host had an existing PTR record.
** I think that if this was the case, all of the consultants would be
denied access.
> And where can I find out why the server denied access to that
> one address?
>
Logs, logs, logs. Look in /var.
Attempt a reconnect under the same conditions. Run any unreachable
service in debug. Run tcpdump on the appropriate interface filtering for
the assigned VPN ip.
-- Matt Miller Systems Administrator MP TotalCare gpg public key id: 08BC7B06
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:04:19 EDT