"Invalid username or password" over Win2k3 VPN

Hi folks,

This question may be better suited for the Openfire forum, but I thought I would post it here as I don’‘t know where the culprit is. Here’‘s the situation; I’‘m running Openfire 3.3.1 on a Windows 2003 SP2 server. I have a mix of Spark 2.5.2 and 2.5.3 clients. Most of my clients reside on the corporate LAN and connect via the Openfire server’‘s private IP, with no problems whatsoever. I also have some telecommuters that run Spark clients on their home machines. These folks connect to our corporate PPTP VPN server, and once they are connected, they connect their Spark clients to the Openfire server’'s private IP just as the corporate LAN users do.

Here’‘s where it gets tricky. I have an old Windows 2000 Server, running RRAS, which has been acting as my VPN server for a few years now. When my telecommuters VPN in to this server, their Spark clients authenticate just fine and they can use Spark all day without problems. However, I’‘m in the process of replacing my old Windows 2000 servers with new Windows 2003 servers, which I’‘ve already done for Openfire. I’'ve setup RRAS on a new Windows 2003 SP2 server and have configured PPTP VPN as identical to the Windows 2000 config as possible. When I point my telecommuters to the new VPN server, they can authenticate with the VPN server just fine. They also can access any host on the network, including the server running Openfire, via ICMP, RDP, FTP, HTTP, SMB, etc. However, their Spark clients will no longer authenticate with the Openfire server. The Spark client will sit on the “authenticating” status for about 2 minutes, and then state, “Invalid username or password”.

Now I know that the Spark clients are finding the Openfire server, because if I point them to an invalid server IP, the client immediately states that it cannot find the server. I should note that in Openfire I have “Client Connection Security” set to custom with Old SSL method set to “not available” and TLS method set to “Optional”. I’‘ve checked everything that I can think of on my VPN server, and I do not have any input or output filters setup, as well as no firewall between it and the Openfire server. I’'ve also enabled debugging on the Spark client, to capture the authentication process, but it did not provide any useful info. My next step will be to use a network sniffer to capture a network trace of the authentication process, but I wanted to post this first in case someone had some suggestions.

Thanks much.

-Ryan

I have a theory, though it could be complete rubbish.

Does the IP pool your new gateway gives out differ from the old one? The only time I’‘ve seen this before is when Openfire (or the Windows server it’'s running on) attempts to use an odd domain controller to authenticate clients, cannot talk to it and times out after a period of time.

Whilst it shouldn’'t matter - does you address you have on your client belong to subnet that is associated with the same site as the 2000 servers pool?

Thanks for the reply DeeJay. My old VPN server and my new VPN server both hand out 10.0.0.0/8 addresses, though in different ranges (i.e. 10.30.1.x and 10.40.1.x). I should note, for what it’‘s worth, that the server running Openfire is a domain controller and is also running DNS. But that shouldn’‘t really matter as I’‘m not using Openfire with AD authentication. I’'m just using local authentication built-in to Openfire. Therefore, the authentication process is the same for the clients, regardless of which VPN server they connect to.

Does anyone have any other suggestions for my issue? Thanks for any help you can provide.

Hi guys,

I enabled debugging on the Openfire server and here’'s what was captured when a VPN client tried and failed to connect:

java.io.IOException: An existing connection was forcibly closed by the remote host

at sun.nio.ch.SocketDispatcher.read0(Native Method)

at sun.nio.ch.SocketDispatcher.read(Unknown Source)

at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)

at sun.nio.ch.IOUtil.read(Unknown Source)

at sun.nio.ch.SocketChannelImpl.read(Unknown Source)

at org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.j ava:232)

at org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcesso r.java:206)

at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProce ssor.java:44)

at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProce ssor.java:506)

at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:43)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

Any ideas?

How about on your client? The Spark logs should give more information.

If you telnet to your server on port 5222, does the connection stay open (until you press a key and Openfire drops it)?

DeeJay -

Yes, when I telnet into the server on port 5222, my telnet client sits on “connecting to…”, so it looks like it is in fact holding the connection open. This happens on both local clients on my LAN, and on the VPN clients. So I think this furthers my notion that I’'m not dealing with a port blocking issue.

I’'ve taken a look at the ERROR.LOG file on the Spark client, and here is what is being captured:

No response from the server.:

at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication .java:58)

at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:345)

at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:785)

at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:185)

at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:589)

at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:129)

at java.lang.Thread.run(Unknown Source)

java.net.SocketException: Connection reset by peer: socket write error

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source)

at sun.nio.cs.StreamEncoder.implFlushBuffer(Unknown Source)

at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)

at sun.nio.cs.StreamEncoder.flush(Unknown Source)

at java.io.OutputStreamWriter.flush(Unknown Source)

at java.io.BufferedWriter.flush(Unknown Source)

at org.jivesoftware.smack.PacketWriter.writePackets(PacketWriter.java:274)

at org.jivesoftware.smack.PacketWriter.access$000(PacketWriter.java:40)

at org.jivesoftware.smack.PacketWriter$1.run(PacketWriter.java:87)

java.net.SocketTimeoutException: Read timed out

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(Unknown Source)

at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)

at sun.nio.cs.StreamDecoder.implRead(Unknown Source)

at sun.nio.cs.StreamDecoder.read(Unknown Source)

at java.io.InputStreamReader.read(Unknown Source)

at java.io.BufferedReader.fill(Unknown Source)

at java.io.BufferedReader.read1(Unknown Source)

at java.io.BufferedReader.read(Unknown Source)

at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:2971)

at org.xmlpull.mxp1.MXParser.more(MXParser.java:3025)

at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1144)

at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)

at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:368)

at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:44)

at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:76)

java.net.SocketException: Connection reset by peer: socket write error

at java.net.SocketOutputStream.socketWrite0(Native Method)

at java.net.SocketOutputStream.socketWrite(Unknown Source)

at java.net.SocketOutputStream.write(Unknown Source)

at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source)

at sun.nio.cs.StreamEncoder.implFlushBuffer(Unknown Source)

at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)

at sun.nio.cs.StreamEncoder.flush(Unknown Source)

at java.io.OutputStreamWriter.flush(Unknown Source)

at java.io.BufferedWriter.flush(Unknown Source)

at org.jivesoftware.smack.PacketWriter.writePackets(PacketWriter.java:274)

at org.jivesoftware.smack.PacketWriter.access$000(PacketWriter.java:40)

at org.jivesoftware.smack.PacketWriter$1.run(PacketWriter.java:87)

java.net.SocketTimeoutException: Read timed out

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(Unknown Source)

at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)

at sun.nio.cs.StreamDecoder.implRead(Unknown Source)

at sun.nio.cs.StreamDecoder.read(Unknown Source)

at java.io.InputStreamReader.read(Unknown Source)

at java.io.BufferedReader.fill(Unknown Source)

at java.io.BufferedReader.read1(Unknown Source)

at java.io.BufferedReader.read(Unknown Source)

at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:2971)

at org.xmlpull.mxp1.MXParser.more(MXParser.java:3025)

at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1144)

at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)

at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:368)

at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:44)

at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:76)

The OUTPUT.LOG file captured this:

Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is falseAcquire TGT from Cache

Principal is null

null credentials from Ticket Cache

authentication failed Unable to obtain Princpal Name for authentication

‘‘Connecting to’’ means that it hasn’'t/cannot connect. You should (with a windows client) see a blank black window with a flashing cursor.

To me - your issue looks network related. Can you traceroute to the server from the VPN client?

Your logs just seem to show an inability to connect the OUTPUT file you posted is just informational (referring to Kerberos auth which I assume you are not using).