Switch to full style
Use this forum to post questions relating to WinGate, feature requests, technical or configuration problems
Post a reply

SAP connectivity issue

Dec 05 04 2:10 pm

Hi all,

Situation is an added component of SAP using SSL is having great difficulty.

Initially the site required an upgrade of the router to allow port 443 traffic to be seen as interesting packets to keep the connection alive whilst a user completed an online submission.

This worked and all usage on the Wingate machine directly to the router/ISDN & WAN holds for the default time outs.

However as a client the user sometimes cannot connect with SAP reporting WSAEconnect failures at the outset right through to ten minute sessions without fault, this is variable in other words.

As a work around I implemented a Port Range in NAT of 443 from Local Pc's to the Internet with a 600 second time out, without benefit.

Stuck at this point as all the other users have SAP sessions only on Port 3200 & 3600 without issue it's just one user who has the SSL requirement and it's become very difficult with this new method beginning in October 2004.

Wingate system is Win2k, V6.0.3 & KAV, all clients are XP Pro, using NAT [with WPAD]. DNS on all the clients points to the host servers [not Wingate] and the domain suffix is registered in DNS also.

Any thoughts appreciated, prior to some Debug logs being provided here next week.

Thanks!

Nev.

Re: SAP connectivity issue

Dec 07 04 12:51 pm

Nev wrote:Hi all,

Situation is an added component of SAP using SSL is having great difficulty.

Initially the site required an upgrade of the router to allow port 443 traffic to be seen as interesting packets to keep the connection alive whilst a user completed an online submission.

This worked and all usage on the Wingate machine directly to the router/ISDN & WAN holds for the default time outs.

However as a client the user sometimes cannot connect with SAP reporting WSAEconnect failures at the outset right through to ten minute sessions without fault, this is variable in other words.

As a work around I implemented a Port Range in NAT of 443 from Local Pc's to the Internet with a 600 second time out, without benefit.

Stuck at this point as all the other users have SAP sessions only on Port 3200 & 3600 without issue it's just one user who has the SSL requirement and it's become very difficult with this new method beginning in October 2004.

Wingate system is Win2k, V6.0.3 & KAV, all clients are XP Pro, using NAT [with WPAD]. DNS on all the clients points to the host servers [not Wingate] and the domain suffix is registered in DNS also.

Any thoughts appreciated, prior to some Debug logs being provided here next week.

Thanks!

Nev.


No thoughts on this anybody?

Dec 07 04 3:57 pm

If you're using NAT, it should all be flowing through fine. Not intercepting, right?

Busy investigating an issue between SSL, Plugins and Cascaded Proxies at the moment - so that *might* be related. (Doubtful, though)


Is it possible to tell who is breaking / refusing the connection? A packet capture might help there. (If you get one, I can tell you what to look for, as it's private data)

Dec 08 04 11:25 am

Pascal wrote:If you're using NAT, it should all be flowing through fine. Not intercepting, right?

Busy investigating an issue between SSL, Plugins and Cascaded Proxies at the moment - so that *might* be related. (Doubtful, though)


Is it possible to tell who is breaking / refusing the connection? A packet capture might help there. (If you get one, I can tell you what to look for, as it's private data)


Thank you for the response Pascal, now it appears as though even using the Wingate machine on this connection is intermittent.

Oddly enough this connection is erratic, so the first time I put all traffic on this machine directly to the connection / router [rather than via the localhost] it seemed to hold and I left assuming it was reliable.

However the user has told me it didn't make any improvement on a remote session into Wingate, so it is now a service issue and Wingate has held true to delivering traffic as you [and I] expected!

Nev.
Post a reply