Dynamic Site to Site

Do you need that the HQ opens the connection to the Plant C?

If not, you can start the IPsec connection from C to HQ. I did it with pix 501 and a VPN concentrator where the 501 had a public dynamic IP. The VPN was LAN to LAN.

-as

But my pix in Plant C is going to have a private IP. Plant C will start the connection though.

Got this for HQ, while Plant C is the same config as Plant B, with the latter working a treat:

sysopt connection permit-ipsec

crypto ipsec transform-set aptset esp-3des esp-md5-hmac crypto dynamic-map mydyn 20 match address SPAIN crypto dynamic-map mydyn 20 set transform-set aptset

crypto map aptmap 10 ipsec-isakmp crypto map aptmap 10 match address FRANCE crypto map aptmap 10 set peer xx.xx.xx.xx crypto map aptmap 10 set transform-set aptset

crypto map aptmap 20 ipsec-isakmp dynamic mydyn

crypto map aptmap interface outside

isakmp enable outside isakmp key xxxxxxxxx address xx.xx.xx.xx netmask xxx.xxx.xxx.xxx no-xauth isakmp key xxxxxxxxx address 0.0.0.0 netmask 0.0.0.0 isakmp policy 10 authentication pre-share isakmp policy 10 encryption 3des isakmp policy 10 hash md5 isakmp policy 10 group 2 isakmp policy 10 lifetime 86400

In article , wrote: :But my pix in Plant C is going to have a private IP. Plant C will start :the connection though.

Please quote appropriate context, to make it easier on those of us who go through a lot of postings.

You indicated in your initial posting that Plant C has a dynamic IP address from the ISP, and you indicate now that Plant C will have a private IP address. When you talk about private IP addresses, are you talking about the "inside" network, or are you saying that the ISP is assigning a dynamic *private* IP to C's PIX?

It doesn't really matter either way. As long as you are not trying to use traditional AH (Authentication Header), C's ISP can assign any IP it wants to the PIX (as long as it doesn't overlap the internal range!). When C's PIX initiates packets out to the public network, the packets will travel through the ISP's internal infrastructure to the ISP's gateway to the public network. At that point, if the ISP did happen to assign one of the RFC1918 private IP ranges to the PIX, the ISP will be responsible for performing NAT into a public IP, and it will be that public IP that will appear on the packets that reach your other hosts. When your hosts reply to that public IP, the replies will reach the ISP's gateway, and the ISP would then be responsible for any necessary NAT'ing to get into the IP address space that it had handed to C's PIX, and the ISP will then deliver the packets through its infrastructure in order to reach C's PIX.

If the ISP assigns a dynamic public IP to C's PIX, then the ISP will not need to do any NAT, but that won't affect the flow of packets in any significant way.

When you are using a crypto dynamic map at HQ to receive the IPSec packets from C's PIX, the -only- point at which you care about C's PIX IP address is in constructing an "isakmp key" shared key. For that particular statement, you would like the IP range narrowed down as much as feasible. PIX 6.x only allows you a single isakmp key with IP 0.0.0.0 mask 0.0.0.0, so to be able to handle multiple dynamic connections with different shared keys, you'd like to make the scope of the key as specific as you can to avoid overlaps.

The router of C has a dynamic public ip address, but the Pix in C picks one up from the router's dhcp. Whereas the router has a public IP, the Pix outside address is 100.1.4.2 and an internal of 10.1.4.10.

Must admit I'm a little lost on this one. I'm no pix expert, nor a vpn expert, but the static solution was a doddle. This dynamic stuff isn't though. Anyone out there with a sample config of a similar setup?

Cheers.

Walter Robers> > :But my pix in Plant C is going to have a private IP. Plant C will start

In article , wrote: :The router of C has a dynamic public ip address, but the Pix in C picks :one up from the router's dhcp. Whereas the router has a public IP, the :Pix outside address is 100.1.4.2 and an internal of 10.1.4.10.

100.1.4.2 is in address space that is not allocated yet, but IANA could choose to allocate it to real hosts at any time, so it is not a good choice for addresses. You should stick to the RFC1918 reserved ranges, 10/8, 172.16/16 - 172.31/16, 192.168.0/24 - 192.168.255/24 .

But other than that quibble, there isn't any problem as long as PIX C will be the one initiating the connection and the receiving PIX has the appropriate crypto dynamic map, and provided that either you do not use AH or else that you turn on isakmp nat-traversal.

If you have isakmp nat-traversal on then everything can go via udp; if you do not have it on, then C's ISP router will need to forward ESP (IP -protocol- 50, *not* "port" 50!) to C's PIX.