Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

unable to access AS400 using MUVPN client

Status
Not open for further replies.

rlehto

IS-IT--Management
May 4, 2003
6
US
Installed the Watchguard Firebox 600. Fairly straightforward. One issue. No MUVPN clients can connect to our AS400 via the VPN client. They are using the PRMS client to access the AS400.

This behavior is consistent across platforms. Win98, Win2k, Win ME. None can connect, ping by name, or ping the AS400 by i.p. address. We can ping and connect to any other server or appliance. The i.p. of the AS400 server is
xxx.xxx.1.50, We can ping the servers immediately above and below that range, by name and number.

The name of the AS400 does resolve to the correct i.p. address when pinging by name, DNS is configured correctly. The AS400 client uses TCP port 23 to connect, but that should all be sent down the VPN tunnel. And, the old VPN client was Microsoft's PPTP, and that worked fine with the AS400.

Where do I start? I have run through all that I know. I need to approach this from a new direction. The version of s/w on the Firebox is 6.2
 
Are your MUVPN clients configured for the same subnet as your LAN or a different subnet? If different, then make sure the AS/400 has a route to that subnet via the trusted interface of the firewall.

As for the name not resolving correctly, a few more details would be helpful. When the FQDN is entered in a ping command, the IP is resolved incorrectly? Does the AS/400 have a public IP that is on a public DNS server?
 
The AS400 is unaware of the subnet the VPN clients are on. Does the AS400 have to have a new route added? I had assumed that it would be like all the other boxes, that the routers would take care of any addressing issues, and handle i.p. traffic going to and coming from the AS400.

What you say makes sense. Add a route to the AS400 so it can respond itself to message traffic?
 
Provided the AS/400 is using the same default gateway router as the rest of the machines that do respond properly, there shouldn't be an issue. The routers should handle this as you pointed out. If the AS/400 is using a different gateway or no gateway, you should have your answer.
 
Here is Watchguards response. Not the answer I wanted. Not "you are stupid, set it up like this", the answer is "yeah, that happens a lot, let us know if you fix it..."

Here is response...

"We have been looking into this issue, which appears to be very common with AS/400's and VPN clients.

The best fix we have found so far involves setting the MTU on the remote client's network adapter to a higher number. We strongly suggest you use a value of 1350.

You can find the tool to change your MTU here:
Please ONLY change the field labeled "MTU" next to your network adapter, as other changes could dramatically affect your network and introduce many variables into the task at hand.

Let me know if this resolves the issue or if you need further assistance."
 
Interesting, but could make sense. I don't know much about AS/400's networking ability with regards to IP.

If it does not allow a packet to fragment and your tunnel size is smaller than the packet the AS/400 is trying to send, I can see an issue. Still seems odd though.

Does IBM have anything to say on that issue? We too have an AS/400, but it is being phased out and is never used over the VPN so we've not had a problem. I might do some testing tomorrow just for kicks if I have time.
 
Issue closed. It was simply a matter adding a route (on the AS400) to the new gateway on the network after the firewall install. I was hoping it was something simple, that didn't require doing anything at the clients.
 
Ah - that was the first suggestion, glad it was the case. Still curious about the MTU issue though - guess that will be on the list of things to do when I have freetime (what's that?).
 
I suspect that this may be another case of the 'interesting' MUVPN client. We have successfully proven that the client is slow and doesn't like packet sizes over 1358. It seems like their response to any MUVPN client is to alter the MTU, without actually looking at the client itself.

Have you tried another client? We used the SSH Sentinel client ( and it is far more stable and faster than the WG/Safenet one - plus you don't have to butcher the MTU sizes.

HTH

Paul O
______________________________________
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top