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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Microsoft VPN problem throught a Gauntlet Firewall

Status
Not open for further replies.
Feb 20, 2002
265
GB
Hi

We have a staff member who connects to a client via Microsoft VPN, this is done on a dial-up. That all works great. So as we try it from behind our Gauntlet firewall it does not work, no real supprise there, the quiestion though is what ports would I need to open for this, and is that going to work, ie the VPN is originating from an internal IP and I assume the Firewall is just going to let the VPN traffic straight through as it is encripted.

Any info would be great.

Simon
 
If your firewall hasa log facility on it, you could clear it and then attempt another connection. Log would show you then ?
 
Well this is a problem I have with Gauntlet, great program, really bad logging, I have been looking at the logs, but I am getting problems trying to get this information displayed.

Simon
 
Well, I had a gander and I believe the port used for Microsoft VPN is port 1723.

Hope it helps.
 
Yep I found that port, opened it, but still does not work.

As I said in the first post, My user attempts to open a connection to the other machine, but there ip address will be a 192.168.***.***, an internal address, needless to say if the other server trys to repley to my users machine, if it repleys to the 192.168.***.*** its guna get dropped by the first internet router it comes across, but if this information is encripted by my user I am assuming the firewall will not be able to examine (ie change) the IP address to the internet IP of the firewall!!

I could be wrong with all this.

Sim
 
hmm, the data might be encrypted but the packet headers naturally wont be, the packet header is what the router/firewall examines.
 
OK cool, so packet headers will not be encrypted, well that should make life easier.
So it should just be a matter on letting traffic out through the firewall, as I have said I have opened port 1723, but that has not fixed it....

Simon
 
I have internal traffic on port 1723 to be let out and to expect a reply....

Sorry don't know if you know gauntlet...
 
No fraid not :) I only really have experience with set firewall rules, eg:

ALLOW 1723 OUT >1023 TCP

etc etc
 
Hi

OK is that a packet filter firewall yer?? Gauntlet also has the proxy rules, but yes, the rule is very much as you have wrote above...
 
Unfortunately I havent any experience with the port usge of MS VPN, but I will have a look.
 
I believe you still have to allow for GRE tunneling in addition to 1723 being open. GRE is a protocol 47. I suggest the following:
If your doing connectivity for PPTP then follow following setting.

Site 1
1. Allow port 47 from trusted and untrusted network
2. Allow port 1723 from trusted and untrusted network
3. Absorb traffic from untrusted
Site 2
1. Allow only port 47 for trusted and untrusted network
 
Hi thanks for the information.

I have got this to work, but funny as it may seem have not had to open port 47, what I have done is this

Create a NAT for the user.
Opened a bidirectional port 1723 (locked do to the hosts IP)

And that works.

What does port 47 do??

Simon
 
It's actually protocol number 47 you need to open, which is GRE (General Routing Encapsulation). GRE is effectively the encapsulation of an arbitrary network protocol (in this
case IP) over another arbitrary network protocol (again IP).

See the following for the RFC ftp://ftp.funet.fi/index/rfc/rfc1701.txt

By created a 1-1 NAT mapping outside of the dynamic outbound NAT performed by your firewall you may circumvented this, but it doesn't have to be this difficult.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top