1. Home
  2. Networking Firewalls
  3. SBS 2003 sudden authentication prob over router based vpn

SBS 2003 sudden authentication prob over router based vpn

Helll, I hope someone can help me on this one

I'm going to try to post this question in a watchguard forum as well but i would really appreciate hearing from someone in the microsoft fold about what they think i should do to make progress

I've built many servers over the years and so am not a novice, but am really struggling with this issue and need some help

Our configuration has been running fine four about 26 months

Last thursday we started having an intermittent problem and last friday the problem became a permanent fault

VERY BRIEF DESCRIPTION (more details follow) We have a back-to-back VPN running between two watchguard soho6 router appliances - DSL connects to internet at both ends on the server end the lan is 10.0.0.x, the server is 10.0.0.10 on the remote end the lan is 10.0.1.x users on remote end have happily used outlook 2003 to establish pop3 connection to server for 24 months outlook is configured to use local hosts file to reslove server by name to 10.0.0.10

OBSERVED PROBLEMS: PROBLEM1. users in the remote office can send email but not receive email via pop3 when accesing the server through the vpn tunnel by it's inside the lan address (10.0.0.10) PROBLEM2. users in the rmote office cannot completely load owa (https://server/exchange, or http://server/exchange) when accessing the server via the vpn tunnel

HOWEVER NOTE1 owa is working in the LAN just fine (users in 10.0.0.x subnet have no problem) NOTE2 both methods work fine if i open up the required ports, install certificates, etc and access them by true FQDN

formatting link
pop3 is fine owa is fine, but i do not want to have that exposure to the internet NOTE3: no changes have been made to routers, server or workstations that can account for this - we built a stable well performing system 2+ years ago and have been problem free until now. subsequent scans show us to be virus free, netstat shows no unexpected connections, etc.

PROBABLY IMPORTANT OBSERVATIONS: OBSERVATION1: Users in remote offices are still able to access shares on the server via the vpn tunnel OBSERVATION2: POP3 sessions from remote users using VPN tunnel do authenticate on server, and do ask for data, but stall when retrieving data OBSERVATION3: POP3 packet capture on problem machines show that commands to retrieve messages go to from the remote office to the server, and that the server does send the data back to the remote user's pc - but the data is not "seen" on the client pc as part of a pop3 session. Yep, that's right .... i have captured the pop3 data packets tha tthe server sends back to the remote machine that have the data that is the message, but the remote machine does not recognize that data as pop3 reply to POP3 RETR command. When i rdp across the vpn to client machine, and run telnet pop3 session this is how it looks TELNET SERVER 110 OK ,,, my server banner here USER usename OK PASS password OK STAT some numbers RETR 1 nothing .... no reply no response, no data, just steady underline (not blinking) message one is a small one.

OBSERVATION4: the stalled telnet session does respond to quit command if i wait about a minute

OBSERVATION5: user in remote offices that access OWA via VPN tunnel NEVER GET A LOGIN PROMPT ON THEIR MACHINE, they get a white background, a blue vertical bar for the left hand menu objects, and nothing else, but the progress bar in the bottom very slowly progresses until page cannot be displayed

OBSERVATION6: on one problem machine:

- i have completely uninstalled all antivirus (was using symantec client security 3 enterprise edition)

- i have disabled the windows firewall the latest windows updates that have been installed are

913446 4 weeks before probelm started 911927 4 weeks before probelm started 908531 4 weeks before probelm started 911562 after problem started 912812 after problem started 911567 after problem started some of which seem like they might be involved, but nothing definitive

OBSERVATION7: the server is lightly tasked, 4gb ram, lots of free drive space the server responds to all LAN, VPN and external queries that i send to it EVEN the ones on the problem machines (see observation 3 above)

the only windows updat that has been applied since 2004 is

867460 which was 2 days after the probelm was first reported

it could be a coincidence and the problem could have been

the windows update is a dot net fix that seems to very involved with server side process communications, but again - the server seems to be working fine and sending data to the client machines.

THE REAL QUESTION If i can copy a file over the vpn and it arrives intact, why can i not transmit properly formatted pop3 data from the server to the client?

Again, the SERVER DOES PROCESS AND REPLY to the POP3 RETR 1 command and that data DOES travel over the VPN at the client machine but the client machine does not seem to recognize it as such.

thanks in advance for your kind consideration to this matter

e
Reply to
ericjmail
Loading thread data ...

Since the VPN passes all data in the SOHO6tc setup, you've proven it's not the firewalls causing the problem.

If the traffic was being blocked the SOHO log would show it.

Look at your Server for the cause.

Apply Office 2003 Service Pack 3 to fix known POP issues - this worked for all of our users that run POP.

Reply to
Leythos

Do you mean to apply the MS Office SP to the server? I thought the SP would not install unless Office was present.

Reply to
Tom Del Rosso

No, you said your clients, using Outlook, were having problems with POP, that means they were using Outlook to PULL email to their computers via a POP connection. Apply Office 2003 SP3 to the clients computer that is running Outlook.

Reply to
Leythos

Ok, but I was only asking out of curiosity. I'm not the OP.

Reply to
Tom Del Rosso

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.