|
|
| Slinky 2002-10-14, 11:49 pm |
| I have a combination NAT and RRAS server setup with the private NIC having an address of 192.168.1.254 and the public one an address of 64.30.210.xx. RRAS works when I try to connect 192.168.1.254 but it says "There is no answer" when I try to connect to 64.30.210.xx. I'm connecting from a computer with an IP of 192.168.1.1. I thought I had it working before to where it would connect to both IPs but now I can't figure out what I did wrong. BUT if I'm on the other computer I can connect to both addresses. :shrug: Like I said before RRAS works great, PPTP, L2TP, you name it. Any thoughts? I think I'm overlooking something obvious. | |
| KScheler 2002-10-15, 2:22 pm |
| Have you checked your routing tables?Something may be messed up there or you may need to enter a static route. | |
| Pavlov 2002-10-15, 3:30 pm |
| Have you changed any of the dial in permissions on the account you're trying to connect with? Or perhaps a policy getting in the way? | |
| Slinky 2002-10-15, 4:10 pm |
| It has to be something on the server because I tried to connect on my third computer and it says the same message. I've looked through the RRAS properties, IAS, and the policy but I didn't see anything that it could be. Really strange. I didn't mess with any user properties, and the routing table looks fine. I can ping the other IP so I'm assuming thats good enough. It seems like the RRAS server doesn't want to respond to clients trying to connect to that IP, but it works on the local machine. So I don't know.  | |
|
| you are trying to create a tunnel between 192 and 64. when going over to the external ip of the machine, you have nat apply, which change to 64 to 64 .
I don't work on any MS system, let alone crappy IAS, RRAS so good luck, I would explore along that line tho. nat behavior and tunneling behavior/permission etc. | |
| Slinky 2002-10-15, 4:26 pm |
| That sounds logical, but I have no idea where to start on that. | |
|
| http://support.microsoft.com/defaul...;EN-US;Q259335&
try that first, I don't have time to check its 100 percent relevant but seem to be so.
I will follow this up later on in the day when I have more time but this seem to be the general problem most ppl have with tunneling technolgoies and nat as it rely on the source address to establish the tunnel which NAT will either change or unable to change.
edit:
I am referring to this.
* If the Virtual Private Network (VPN) client is behind any network device performing Network Address Translation (NAT), the L2TP session fails because encrypted IPSec Encapsulating Security Payload (ESP) packets become corrupted. If the VPN client is on the same computer as Windows Internet Connection Sharing/Network Address Translation, the client is most likely able to establish an L2TP session because NAT does not perform any IP address or Port translation when packets originate from its own node.
try to search for thigns like that on technet or specific to the microsoft service.
oh. and I should also add this, don't know if microsoft do anything but this is common.
to deny anything with internal ip originating from external interfaces to guard against any attack.
well, yours would be , as it is an internal ip trying to establish/exploint (in its mind) its external interface. prime candidate to drop the connection.
I still tihnk its more likely problem with natting a request whose source was natted but just more thoughts for you to dwell on.
ok really done for awhile now gluck. | |
| Slinky 2002-10-15, 4:45 pm |
| I've actually read that before, but I didn't think anything of it because I swear I had it working before to where I could connect to either IP. When I get home I'll disable NAT and see if it works that way and I'll change the IP of my other computer to be on the 64.30.210.xx network. Then if it magically works, I'll know it was NAT. | |
|
| the general rule is nat b4 ipsec on its way out and ipsec b4 nat on its way back,
when you nat an encrypted packet as you are doing, you change the packet and the packet will be drop as it has been alterred.
now, here is my ignorance as I really has not read too much into l2tp etc to know whether the ipheader is protected and the detail of its session establishment. but that's the general logic when confronted with these type of issue and through monitoring the session establishment, you can narrow down why and where this process fail. | |
|
| Historically, one of the problems with L2TP/IPSec is that IPSec peers cannot be placed behind a network address translator (NAT) because Internet Key Exchange (IKE), the protocol used to negotiate SAs, and IPSec-protected traffic are not NAT-translatable. However, a new set of Internet drafts describe IPSec NAT traversal, in which IKE messages and processing are modified and IPSec-protected packets are encapsulated as User Datagram Protocol (UDP) messages. This allows L2TP/IPSec connections to be created for client and server computers that support IPSec NAT traversal that are located behind one or multiple NATs.
Microsoft L2TP/IPSec VPN Client supports IPSec NAT traversal as described in the Internet drafts titled "UDP Encapsulation of IPSec Packets" (draft-ietf-ipsec-udp-encaps-02.txt) and "Negotiation of NAT-Traversal in the IKE" (draft-ietf-ipsec-nat-t-ike-02.txt). Support for IPSec NAT traversal is planned for the Windows .NET Server family and for many third-party VPN servers. No configuration for IPSec NAT traversal is required. Microsoft L2TP/IPSec VPN Client automatically determines whether there are any NATs in the path and whether the VPN server is capable of doing IPSec NAT traversal. If both of these conditions are true, Microsoft L2TP/IPSec VPN Client automatically uses IPSec NAT traversal.
http://www.microsoft.com/technet/tr...ty/vpnclnta.asp
see if there is anything here that will help. this document will be my reading for the nite when i get back hehe. so much to read/learn/brush upon... | |
| Slinky 2002-10-15, 6:42 pm |
| You got it mikop, that was the problem. I disabled NAT on my computer and changed the IP on my other computer so that it was on the same network as 64.30.210.xx and it connected right up. I didn't think that the packets would be translated if they were destined to the public interface of NAT, but I guess I was wrong. Thats the thing I hate most about NAT and firewalls is that it makes setup so complicated if not damn near impossible. GRRRRR!!! 
Thanks to all that threw in their $.02. | |
| Zaraspook 2002-10-15, 7:05 pm |
| Yep both NAT and IPSec change the IP headers and can't be used together. Therefore, if you're using NAT use PPTP. Don't use L2TP/IPSec. If I remember correctly, I had a question to that effect on one of the exams, either 216 or 221. | |
| Slinky 2002-10-15, 7:17 pm |
| Yep, I just got L2TP/IPSec to work last night, and thats where my troubles started. I was messing with PPTP a few weeks ago and I was using the public IP of NAT and it was working fine. So I never did change the address when I switched over to L2TP and thats where I went wrong, but all is fine now and I'll never forget that. Thanks guys. What a learning experience. | |
| Pavlov 2002-10-15, 9:09 pm |
| Nice work and a good learning experience indeed. And a great read for all the member who drop into this thread  | |
|
| heh just browsed to this article and felt that it was worthy read, enough to bring this thread up on top because NAT and IPSec etc are commonly deployed nowaday | |
| jocampo 2002-11-07, 4:34 pm |
| Excellent topic...excellent question and explanation...i have learn a lot today! Thanks all! That's why i love this forum! |
|
|
|