Mathew - I read your write up many times and this thing is clear like day and night. Since both sides need to have a matching rule and the side that has static IP can not write a dynamic address in its remote gateway is the main difficulty. I have an old Linksys and that accepts static IP for its wan. It also accepts dynamic IP for ipsec and so it connected wih my pfsense 1.2rc4 within seconds. See the picture attached...
It worked... You should be a teacher. You are so good in conveying the fundamentals & concepts. Thanks a ton. Best Regards Anil Garg Matthew Grooms <[EMAIL PROTECTED]> wrote: > Von: Anil Garg [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 28. Februar 2008 04:51 > An: [email protected] > Betreff: [pfSense Support] IPSEC > ... > Have looked at all documents and spent many hours without avail... > Will some of you learned people suggest a way out.. I can only > get a Public IP address at one location and I am happy to do pay > for that. > > But the second location being a AT&T DSL in San Jose, CA - this > is not an option,..... > > Much appreciate your help and guidance. > Anil, To answer your question with respect to IPsec in general, the solution to your problem depends on a lot of different factors. Having one IPsec peer using a non-public address pre-supposes that the address will be translated to a public address by a NAT device. So the question could have been stated as "can one IPsec peer operate behind a NAT device?". The answer is yes, but the question is still complicated. Who controls the NAT device and how sophisticated is the NAT logic? The IKE protocol, which based on UDP, is typically used to establish IPsec connectivity. The source address of UDP traffic is easily NATd on the outbound path. With this in mind, if the peer behind the NAT device always initiates negotiations then you shouldn't have too much of a problem. Where an issue will occur is when the peer that has the public address attempts to initiate an exchange to the peer behind the NAT device. If you control the NAT process and the NAT device is somewhat sophisticated, you can teach it to perform a static NAT which will translate the destination address of a packet sourced from the public peer to the private peer address. This is typically referred to as port forwarding. If traffic always originates from the peer behind the NAT, you can typically turn contact off for the publicly addressed peer and avoid this situation all together. So that addresses IKE traffic which provides negotiation and key setup, but there are other protocols that make up IPsec. To provide protection and message authentication, the ESP protocol is typically used to encapsulate and encrypt protected traffic. ESP is an IP protocol, like TCP or UDP, but its header contains no port values. This makes it difficult to pass transparently through a NAT device because you don't have ports to translate and build state information with. For NAT devices that hide many privately addressed hosts behind a single public address, valid state information is an essential key to translating a public destination address to the appropriate private destination address when processing inbound packets. The only data a NAT device has to work with to correlate state to an inbound ESP packet is the source and destination addresses. However, this should be adequate if there is only one IPsec peer behind the NAT device communicating with the publicly addressed peer and traffic is bidirectional. Once again, if you control of the NAT device it should be possible to always translate the destination address of all ESP traffic sourced from a specific peer to the private destination address of the NATd peer. Why do I feel like I need my dry erase board? :) What if you don't have control over the NAT device or its too primitive? Your probably out of luck unless both ends of the connection support NAT-T or Nat Traversal which is an extension to the IKE/IPsec protocol family. What it does is multiplex both IKE and encapsulated ESP traffic onto a single UDP port which passes more easily through NAT devices. It also defines ways of keeping Firewall/NAT states from expiring by constantly sending traffic between the two hosts. This allows rekey attempts to be initiated by either IPsec peer. As far as I know, NAT-T is not currently supported by pfsense but I have high hopes that it will be introduced into the mainline FreeBSD sources soon. Probably more info than you wanted but I hope it helps, -Matthew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<inline: delete.png>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
