Presumably it's a untrust to (insert dmz here) rule that you need to define. Not sure if an outbound one is required. PPTP is a predefined service that includes IP protocol 47 in it. TCP src
1-65535, destination port 1732, and IP protocol 47.
Do you know the IP address of the person doing the test?
If so create a temporary, IP-address-of-the-person-doing-the-test to VPN gateway allow all rule, and vice versa. Turn on logging. Does it work? If yes, then start narrowing down the rules to just the protcols used in the logs.
I'm setting up a netscreen 25 firewall to use NAT. All is working fine except that people can't VPN in (using PPTP preferably). (I want people to be able to VPN in to a VPN server on the inside and not use the built-in VPN abilities of the netscreen).
I'm finding messages everywhere saying that to allow me to do this, I have to allow in PPTP protocol, which I've done, but I also have to "allow protocol 47" - what exactly is meant by this? In the services rule, I can create a service with a specific IP type - is this what they mean? I've tried doing this - creating a service that allows all ports to all ports with IP proto 47 allowed, but this isn't working. Can anyone shine any light on what exactly "open protocol 47" means in terms of a netscreen firewall?
Not-My-Real-Name wrote: >>Sorry, I meant that "I can create a service with a given transport >>number"... >>
Hi
thanks for your reply! Do you mean the code revision on the netscreen-25?
Since I wrote that post I found out the same info that you are saying, and have created a service allowing anyport->1743 TCP + IP proto 47, plus I tried adding UDP any port (found an article somewhere suggesting that). (Plus obviously I actually created an inbound rule for the firewall that uses that policy.) Still no dice though... interestingly, the client can do an initial connection, bceause they get to the "Verifying username and password..." part, but it hangs there and eventually gets error 721. So it seems the returning traffic is going astray somewhere?
Yes, I know their IP address, and I tried the following... I created a new service called 'all', which allows all ports to all ports for both TCP and UDP, and also added protocol 47 (all ports to all ports) for good measure (which is GRE).
Then I made a VIP setting that mapped from an external usable IP address (not the actual address of the firewall itself) to the internal IP of our VPN server for the service 'all' (see above para), with virtual port
1723 (which is for VPN).
Then I created an incoming policy: to allow traffic from the given user external IP (the one who wants to VPN) to our VIP address on the outside (with the NAT option turned on), and I turned on logging for this rule. When the outside user tries to connect, they almost immediately get this error: "Error 800: could not establish the VPN connection."
The logs do show information for this connection, as follows:
Date/Time 2004-12-15 15:35:12 Source Addr/Port XX.XX.XXX.XXX:1565 [note: have censored real IP here] Translated Addr/Port 192.168.1.55:2261 [inside address of our netscreen] Destination Addr/Port 192.168.1.105:1723 [inside address of VPN server] Duration 1 sec. Service PPTP
So, we're getting through, but connection is having trouble getting established. I'm going to have a look for the logs for our VPN server....
It's not surprising that PPTP is not working across NAT. What you should consider doing, if you insist on using Microsoft 'VPN', is use L2TP and terminate the tunnel on the firewall. It's easy to do and works fine.
Actually, PPTP works quite well across NAT, and even MS PPTP works with it. The problem is that many of the Home/SOHO routers require more than just enabling TCP/1723 through, some actually require that you create a TCP/47 rule - even though it's not TCP.
One linksys router requires TCP 1723 & 47 to forward, while a D-Link unit requires TCP/UDP 1723 & 47 in order for it to work.
My Firewall, a commercial appliance, only requires that I open the PPTP rule and point it at the PPTP server inside the network, which is using NAT.
Just like any tunnel on the NetScreen, the logical flow setting it up as far as navigation is concerned is from bottom to top, so you have to create your IP Pool, a group (under objects), users and then put them into the group, configure your tunnel, then create inbound policy. I might be missing something since I just woke up, but really, it's easier than it sounds. TFM does a good job explaining, so create a login on Juniper and check it out.
---begin rant--- And if I could talk you out of using L2TP or PPTP I would. The NetScreen Remote Client (from Safenet) works nicely and has improved a ton, and using IPSec is just the way to go in my opinion. The NetScreen also can easily be configured using XAUTH to provide Layer 3 information on a virtual interface using IPSec, and utilizing IAS / Radius, your user accounts can be maintained easily. ---end of rant---
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.