Antonio King
asked on
IP PROTOCOL 47 (GRE)
Experts,
I am currently trying to configure my firewall to let through IP PROTOCOL 47 (GRE). When adding rules the only protocols I'm able to select are TCP(6), UDP(17) and ICMP(1). Does this mean that my firewall doesn't support GRE? I have a SonicWall SoHo3, which is fairly old I believe.
I am trying to get the Windows 2003 native VPN working for my users to connect.
Any help is greatly appreciated.
Regards,
Alan
I am currently trying to configure my firewall to let through IP PROTOCOL 47 (GRE). When adding rules the only protocols I'm able to select are TCP(6), UDP(17) and ICMP(1). Does this mean that my firewall doesn't support GRE? I have a SonicWall SoHo3, which is fairly old I believe.
I am trying to get the Windows 2003 native VPN working for my users to connect.
Any help is greatly appreciated.
Regards,
Alan
You didnt say what make your firewall is. Sounds like a web based config though.
You need to add a new service called gre and allocate port 47 to this. You will then be able to select gre in your firewall rules.
Jess
You need to add a new service called gre and allocate port 47 to this. You will then be able to select gre in your firewall rules.
Jess
Sorry you did, and sonicwall works as above. Create the service first :)
I agree with above poster. Create the Service for GRE, and then assign it a port.
/TT
/TT
Hopefully this'll help...
Which ports need to be opened for running VPN
A: PPTP VPN uses TCP Port 1723, IP Protocol 47 (GRE); L2TP: UDP Port 1701; IPSec: UDP Port 500, Pass IP protocol 50 and 51. Note: 47 is a protocol number and not TCP port. The protocol name is GRE. It'll make a big difference when configuring your firewall or router.
ref: http://www.chicagotech.net/vpnsetup.htm
Which ports need to be opened for running VPN
A: PPTP VPN uses TCP Port 1723, IP Protocol 47 (GRE); L2TP: UDP Port 1701; IPSec: UDP Port 500, Pass IP protocol 50 and 51. Note: 47 is a protocol number and not TCP port. The protocol name is GRE. It'll make a big difference when configuring your firewall or router.
ref: http://www.chicagotech.net/vpnsetup.htm
GRE is protocol 47 not port 47. On most routers you are looking for "enable PPPTP pass-through". Some it is simply VPN pass-through, some others it is not supported
ASKER
Thanks for everyones prompt answers.
I am fine with opening all the various TCP and UDP ports on the firewall.
The problem I'm having is understanding what this Protocol 47 (GRE) is, there does appear to be some conflicting views on this as I've found so far. As I understand it, Protocol 47 is a protocol and not port, so when setting up a new service on my firewall I don't have the option of GRE under Protocols, just TCP, UDP and ICMP.
I need to know how to enable this protocol 47 on my SonicWall SOHO3, or if infact it is even supported with this firewall?
Many Thanks once again.
Alan
I am fine with opening all the various TCP and UDP ports on the firewall.
The problem I'm having is understanding what this Protocol 47 (GRE) is, there does appear to be some conflicting views on this as I've found so far. As I understand it, Protocol 47 is a protocol and not port, so when setting up a new service on my firewall I don't have the option of GRE under Protocols, just TCP, UDP and ICMP.
I need to know how to enable this protocol 47 on my SonicWall SOHO3, or if infact it is even supported with this firewall?
Many Thanks once again.
Alan
>>"I need to know how to enable this protocol 47 on my SonicWall SOHO3, or if in fact it is even supported with this firewall?"
On routers without a configuration for GRE service, it is usually called "enable PPTP pass-through", though I could not find it in the online documentation.
Found this regarding the SOHO3
"All versions of SonicOS Enhanced can GRE........SonicOS and Firmware 6.x cannot pass GRE.
From: http://www.sonicwall.com/support/pdfs/technotes/ike_ipsec_implementation_faq.pdf
On routers without a configuration for GRE service, it is usually called "enable PPTP pass-through", though I could not find it in the online documentation.
Found this regarding the SOHO3
"All versions of SonicOS Enhanced can GRE........SonicOS and Firmware 6.x cannot pass GRE.
From: http://www.sonicwall.com/support/pdfs/technotes/ike_ipsec_implementation_faq.pdf
Log in to your sonic wall
Click Access
Click Add Service
Under Add a known service:
Select Custom
Under Name
Type GRE
Under Port Range*
Type 47 and 47
Under Protocol
Select the protocol you are using
If you need both TCP and UDP, you will need a service for each
Call them GREUDP and GRETCP
GRE supports TCP and UDP, better create both if you arent sure
Click Access
Click Add Service
Under Add a known service:
Select Custom
Under Name
Type GRE
Under Port Range*
Type 47 and 47
Under Protocol
Select the protocol you are using
If you need both TCP and UDP, you will need a service for each
Call them GREUDP and GRETCP
GRE supports TCP and UDP, better create both if you arent sure
ASKER
Ok, I seem to have this straightened out in my head now, about Protocol 47 anyway. Thank you RobWill.
Jessmca - I think you are falling into the same trap as me, where you are associating Protocol 47 with TCP & UDP port 47, which it isn't, as far as I understand.
Can someone just tell me if the ports used, and this Protocol 47, has changed since Windows 2000 Server? I previously had Windows 2000 Server in here and the same firewall passed that through fine. It's only since upgrading to Windows 2003 Server that this problem has arisen. I can only assume that Windows 2000 didn't use Protocol 47 for it's VPN functionality and it's new to 2003 server?
Many Thanks,
Alan
Jessmca - I think you are falling into the same trap as me, where you are associating Protocol 47 with TCP & UDP port 47, which it isn't, as far as I understand.
Can someone just tell me if the ports used, and this Protocol 47, has changed since Windows 2000 Server? I previously had Windows 2000 Server in here and the same firewall passed that through fine. It's only since upgrading to Windows 2003 Server that this problem has arisen. I can only assume that Windows 2000 didn't use Protocol 47 for it's VPN functionality and it's new to 2003 server?
Many Thanks,
Alan
Of course it is.
TCP and UDP are the transport protocols. It does not mean other protocols cannot use them. It is called encapsulation.
Create an entry on port 47 for tcp and udp and open it through your firewall. It will work. Trust me :)
TCP and UDP are the transport protocols. It does not mean other protocols cannot use them. It is called encapsulation.
Create an entry on port 47 for tcp and udp and open it through your firewall. It will work. Trust me :)
No it hasn't changed with Server 2003. Assuming you are using the same security protocol for your VPN. As I recall:
PPTP requires TCP port 1723 and protocol 47 (PPTP passthrough)
IPSec requires UDP port 500 and protocols 50 & 51 (IPSec passthrough)
L2TP requires UDP 1701, UDP 500 if using IPSec, UDP 5500 if using NAT-T, and L2TP pass through.
If you are using the Windows PPTP VPN you should only have to enable port forwarding of TCP 1723 to the server and enable GRE as in above methods. Are you configuring the firewall for Port 1723 or forwarding? Should be latter.
PPTP requires TCP port 1723 and protocol 47 (PPTP passthrough)
IPSec requires UDP port 500 and protocols 50 & 51 (IPSec passthrough)
L2TP requires UDP 1701, UDP 500 if using IPSec, UDP 5500 if using NAT-T, and L2TP pass through.
If you are using the Windows PPTP VPN you should only have to enable port forwarding of TCP 1723 to the server and enable GRE as in above methods. Are you configuring the firewall for Port 1723 or forwarding? Should be latter.
ASKER
Ok I'll give it a whirl and let you know. I have heard so much conflicting information on this that I don't know who is right or wrong you see. Anyway, thanks and I'll give it a try.
ASKER
RobWill,
So basically if my firewall worked before with Windows 2000 Server VPN, then I shouldn't need to change any configuration for it to work with 2003, assuming I'm using the same security protocol?
If this is the case then the problem doesn't lien with my firewall.
Thanks,
Alan
So basically if my firewall worked before with Windows 2000 Server VPN, then I shouldn't need to change any configuration for it to work with 2003, assuming I'm using the same security protocol?
If this is the case then the problem doesn't lien with my firewall.
Thanks,
Alan
Alan doesn't hurt to try. You definitely want protocol 47 not port 47 but I have seen them coupled together on one older router a while back. Nothing to loose, but I have never enabled/forwarded 47.
>>"So basically if my firewall worked before with Windows 2000 Server VPN, then I shouldn't need to change any configuration for it to work with 2003"
Right.
What exactly is the problem? Maybe we are "barking up the wrong tree".
Right.
What exactly is the problem? Maybe we are "barking up the wrong tree".
GRE is definitely IP Protocol 47 and not port 47. TCP is IP Protocol 6 and UDP is IP Protocol 17. I don't know why some of you are even arguing this point.
According to a SonicWall FAQ I found you need SonicOS Enhanced instead of Standard to get GRE to work.
Q: Do SonicWALL security appliances support GRE?
A: All versions of SonicOS Enhanced can pass GRE across its interfaces (if configured in the firewall rules to do so), but
cannot initiate or terminate GRE tunnels. SonicOS Standard and firmware 6.x cannot pass GRE and cannot initiate or
terminate GRE tunnels. There are no plans for any version of SonicWALL OS to initiate or terminate GRE tunnels.
So I'm not sure why it was working before and not now, but at least check to see if you have the right OS on there. Have you upgraded the software recently?
According to a SonicWall FAQ I found you need SonicOS Enhanced instead of Standard to get GRE to work.
Q: Do SonicWALL security appliances support GRE?
A: All versions of SonicOS Enhanced can pass GRE across its interfaces (if configured in the firewall rules to do so), but
cannot initiate or terminate GRE tunnels. SonicOS Standard and firmware 6.x cannot pass GRE and cannot initiate or
terminate GRE tunnels. There are no plans for any version of SonicWALL OS to initiate or terminate GRE tunnels.
So I'm not sure why it was working before and not now, but at least check to see if you have the right OS on there. Have you upgraded the software recently?
I second the thought that GRE, generic routing encapulation is it's OWN RFC PROTOCOL. Opening port 47 will NOT help. If you router does not call it GRE, then it is pptp pass-through.
If you need ESP, encapulating security payload, you need PROTOCOL 50.
If you router does not call it ESP, then it is ipsec pass-through.
Note your problem may be due to an obscure and annoying rule that routers cannot have more than one host connect through it using pptp or ipsec. If you find that you used to be able to do it, and now cannot, look for another system that is connecting using pptp to somewhere (it might be a high-end trojan) that is what is causing your new problem
If you need ESP, encapulating security payload, you need PROTOCOL 50.
If you router does not call it ESP, then it is ipsec pass-through.
Note your problem may be due to an obscure and annoying rule that routers cannot have more than one host connect through it using pptp or ipsec. If you find that you used to be able to do it, and now cannot, look for another system that is connecting using pptp to somewhere (it might be a high-end trojan) that is what is causing your new problem
ASKER
Photograffiti - Yes I have updated the firmware on the sonicwall recently, it is running with the latest version (6.6.0.8). I am a little confused however, I have always been running a 6.x firmware on this firewall and it has always passed through the VPN to my old Windows 2000 Server without any problems.
The actual error message I'm getting when I try to connect from a client machine is as below, it will get as far as verifying user name and password, stays on that for a second or two, then pops up with the error:
Disconnected.
Error 619: A connection to the remote computer could not be established, so the port used for this connection was closed. For further assistance, click More Info or search Help and Support Center for this error number.
Many Thanks,
Alan
The actual error message I'm getting when I try to connect from a client machine is as below, it will get as far as verifying user name and password, stays on that for a second or two, then pops up with the error:
Disconnected.
Error 619: A connection to the remote computer could not be established, so the port used for this connection was closed. For further assistance, click More Info or search Help and Support Center for this error number.
Many Thanks,
Alan
Surprised you were ever able to get it to work. As I mentioned above "........SonicOS and Firmware 6.x cannot pass GRE"
Have a look at resolution 1 & 4 for error 619 in the following link:
http://www.howtonetworking.com/vpnissues/error619.htm
Have a look at resolution 1 & 4 for error 619 in the following link:
http://www.howtonetworking.com/vpnissues/error619.htm
I don't fully understand the use of any of these rogue routers, fireboxes, sonicwalls,. I'm strictly a Cisco for people who can afford it, and Linksys (made by Cisco) for people who cannot, kinda guy
Alan-Yeo , were you abel to get this up and running yet?
--Rob
--Rob
ASKER
No, not at the moment, I do need to get this working, haven't had the time to look into it of late.
I am still receiving the error:
Disconnected.
Error 619: A connection to the remote computer could not be established, so the port used for this connection was closed. For further assistance, click More Info or search Help and Support Center for this error number.
I receive this after it connects and then attempts to verify User Name & Password. So I'm pretty sure it's not a problem with my Firewall anymore, as it gets to verifying user name and password and then fails. I can only assume there is something wrong with the configuration on the server.
Any help much appreciated as always.
Alan
I am still receiving the error:
Disconnected.
Error 619: A connection to the remote computer could not be established, so the port used for this connection was closed. For further assistance, click More Info or search Help and Support Center for this error number.
I receive this after it connects and then attempts to verify User Name & Password. So I'm pretty sure it's not a problem with my Firewall anymore, as it gets to verifying user name and password and then fails. I can only assume there is something wrong with the configuration on the server.
Any help much appreciated as always.
Alan
It is possible to make an initial connection but not complete it if the security protocol is not allowed to "pass" and allow communications. Still could be your GRE issue. Can you revert back to an older firmware version that does support GRE.
Also did you see the following pertaining to your 619 error, provided in the link above:
"If the RRAS is in a domain network, add the VPN to the appropriate group. To do this, go to Active Directory Users and Computers>domain name>Users, double-click the RAS and IAS Servers security group. Select the members and add the VPN server to this group."
Also did you see the following pertaining to your 619 error, provided in the link above:
"If the RRAS is in a domain network, add the VPN to the appropriate group. To do this, go to Active Directory Users and Computers>domain name>Users, double-click the RAS and IAS Servers security group. Select the members and add the VPN server to this group."
ASKER
RobWill,
I was under the impression that if the Firewall had worked previously to pass the VPN through with Windows 2000 Server, it should not need to be changed for use with Windows 2003 Server. I haven't changed anything on the firewall since upgrading to Windows 2003 server. This is what I've been lead to believe anyway, would you agree?
Yes I can confirm that the server is in the "RAS and IAS Server" security group.
Does it matter that the old server is still being used to issue DHCP addresses to all clients on this network? I demoted this Win 2000 Server, but left it with the role of DHCP server. The new 2003 server does not issue addresses. Could this affect the RAS, as I know that RAS clients connecting require DHCP to issue them an address?
Thanks for you help.
Alan
I was under the impression that if the Firewall had worked previously to pass the VPN through with Windows 2000 Server, it should not need to be changed for use with Windows 2003 Server. I haven't changed anything on the firewall since upgrading to Windows 2003 server. This is what I've been lead to believe anyway, would you agree?
Yes I can confirm that the server is in the "RAS and IAS Server" security group.
Does it matter that the old server is still being used to issue DHCP addresses to all clients on this network? I demoted this Win 2000 Server, but left it with the role of DHCP server. The new 2003 server does not issue addresses. Could this affect the RAS, as I know that RAS clients connecting require DHCP to issue them an address?
Thanks for you help.
Alan
>>" I haven't changed anything on the firewall since upgrading to Windows 2003 server."
Sorry, thought you had upgraded the Firewall's firmware. Then that shouldn't be the problem.
>>"Could this affect the RAS, as I know that RAS clients connecting require DHCP to issue them an address?"
Not sure. The client will definitely have to obtain an address and likely cannot connect to the DHCP server until the connection is complete. However, RAS will usually negotiate a Windows APIPA 169.254.x.x address with the client's virtual adapter. Can you verify that at any point with IPconfig during the connection phase before the connection is dropped?
Open the RRAS console, right click on the server name and choose properties and look at the IP tab. If it shows DHCP, no static address pool, I think the 169.254.x.x address should be applied.
Sorry, thought you had upgraded the Firewall's firmware. Then that shouldn't be the problem.
>>"Could this affect the RAS, as I know that RAS clients connecting require DHCP to issue them an address?"
Not sure. The client will definitely have to obtain an address and likely cannot connect to the DHCP server until the connection is complete. However, RAS will usually negotiate a Windows APIPA 169.254.x.x address with the client's virtual adapter. Can you verify that at any point with IPconfig during the connection phase before the connection is dropped?
Open the RRAS console, right click on the server name and choose properties and look at the IP tab. If it shows DHCP, no static address pool, I think the 169.254.x.x address should be applied.
ASKER
Here is the complete configuration under ----> Routing and Remote Access ----> Server_Name ----> Properties on the 2003 Server.
I have two network cards in this server, but only one is being used.
General Tab
- "Router" is ticked
- "Local area network (LAN) routing only" is selected
- "Remote access server" is ticked
nothing else selected on this tab
Security Tab
- Authentication Provider is set to "Windows Authentication"
- Accounting provider is set to "Windows Accounting"
nothing else selected on this tab
IP Tab
- "Enable IP routing" is ticked
- Under "This server can assign IP addresses by using:" - "Dynamic Host Coonfiguration Protocol (DHCP)" is selectted
- "Enable broadcast name resolution" is ticked
- Under "Use the following adapter to obtain DHCP, DNS, and WINS addresses for dial-up clients" - "Local Area Connection" is selected
nothing else selected on this tab
PPP Tab
- Everything is ticked
Logging Tab
- "Log all events" is ticked
nothing else selected on this tab
I won't be able to test the ipconfig cmd until I get home from work where I have access to a remote pc. I'll try later and post results if possible. In the mean time could you check the config above for me and see if it looks ok.
Once again, thanks for all your help.
Alan
I have two network cards in this server, but only one is being used.
General Tab
- "Router" is ticked
- "Local area network (LAN) routing only" is selected
- "Remote access server" is ticked
nothing else selected on this tab
Security Tab
- Authentication Provider is set to "Windows Authentication"
- Accounting provider is set to "Windows Accounting"
nothing else selected on this tab
IP Tab
- "Enable IP routing" is ticked
- Under "This server can assign IP addresses by using:" - "Dynamic Host Coonfiguration Protocol (DHCP)" is selectted
- "Enable broadcast name resolution" is ticked
- Under "Use the following adapter to obtain DHCP, DNS, and WINS addresses for dial-up clients" - "Local Area Connection" is selected
nothing else selected on this tab
PPP Tab
- Everything is ticked
Logging Tab
- "Log all events" is ticked
nothing else selected on this tab
I won't be able to test the ipconfig cmd until I get home from work where I have access to a remote pc. I'll try later and post results if possible. In the mean time could you check the config above for me and see if it looks ok.
Once again, thanks for all your help.
Alan
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
RobWill,
After playing around with the settings in Routing and Remote Access I have finally got it working, I ticked the "Allow IP-Based remote access and demand-dial connections" box on the IP Tab. This immediately cured the problem.
Thanks for all you help, points are coming your way.
Alan
After playing around with the settings in Routing and Remote Access I have finally got it working, I ticked the "Allow IP-Based remote access and demand-dial connections" box on the IP Tab. This immediately cured the problem.
Thanks for all you help, points are coming your way.
Alan
hope that helps