On Mon, 2002-08-26 at 15:49, Mikes work account wrote:
> OK. So the problem is with one address: x.x.x.201. I am assuming you
> have a pool of dynamic addresses assigned to the VPN hosts. Is the .201
> address out of a supernetted/CIDR network ip range and therefore
> unroutable?
> ** It is out of the range now since we took it out. It was the first to be
> assigned. Now the next address is working fine.
I assume you took it out of a pool of addresses, not changed your CIDR
masked bits. What I was referring to above is that under non-class
specific netmasks like 192.168.199.x/26 you are dealing with a different
range of IP addresses than in standard netmasks like 192.168.199.x/24.
>
> Perhaps another host on the network claimed the .201 address by accident
> (or was accidentally statically assigned)? Can you ping the .201 address
> from another VPN host?
> ** No, nothing answers on that address.
Good. No other machine appears to have that address.
> Are the packets from the .201 VPN host reaching the Linux server? Setup
> a box to connect from the outside world as a vpn client (or use a
> consultant as a guinea pig) with the .201 address. Try to ping any other
> connected VPN hosts. Attempt a connection to the Linux server and run
> tcpdump on the appropriate interface.
> ** We could ping any address except the one Linux server. The other Linux
> server was able to be pinged.
>
OK. The problem appears to be a single address connecting to a another
specific address/host.
> $ tcpdump -i ethx host x.x.x.201
> **This gives me a parsed error
All the command above is supposed to do is listen on interface (x) and
filter the output for the x.x.x.201 address.
What version of tcpdump are you running? You could read the tcpdump
manpages to look for the correct syntax for your version.
-- 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:05:08 EDT