f



Dynamic Site to Site

I have a static site to site vpn tunnel between a pix 515 and a 506. I
now need to add a dynamic site to site vpn tunnel to my configuration.
Basically the 515 is at HQ and the 506s are at satilite plants. Plant A
(HQ) uses static ip addresses, so too does Plant B. However, plant C's
ISP cannot supply static IP addresses for the solution chosen (don't
ask!). Instead, the ISP router in Plant C is going to have a dynamic
public ip and yet the pix is not going to even have a public ip address
at all. Is a site to site tunnel possible in this setup? Can the
required ipsec ports be opened and forwarded to the Plant C's pix on
their ISP router?

Any help would be most welcome.

0
9/20/2005 9:37:02 AM
comp.dcom.sys.cisco 25313 articles. 0 followers. Post Follow

6 Replies
967 Views

Similar Articles

[PageSpeed] 31

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

0
aservin
9/20/2005 9:52:16 AM
But my pix in Plant C is going to have a private IP. Plant C will start
the connection though.

0
morgan
9/20/2005 10:07:44 AM
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

0
morgan
9/20/2005 10:55:44 AM
In article <1127210864.442892.254790@g14g2000cwa.googlegroups.com>,
 <morgan.ian@gmail.com> 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.
-- 
   "No one has the right to destroy another person's belief by
   demanding empirical evidence."            -- Ann Landers
0
roberson
9/20/2005 5:47:15 PM
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 Roberson wrote:
> In article <1127210864.442892.254790@g14g2000cwa.googlegroups.com>,
>  <morgan.ian@gmail.com> 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.
> --
>    "No one has the right to destroy another person's belief by
>    demanding empirical evidence."            -- Ann Landers

0
morgan
9/21/2005 9:14:42 AM
In article <1127294082.679621.142430@f14g2000cwb.googlegroups.com>,
 <morgan.ian@gmail.com> 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.
-- 
   When Love is gone, there's always Justice.
   When Justice is gone, there's always Force.
   When Force is gone, there's always Mom.     -- Laurie Anderson
0
roberson
9/21/2005 5:36:10 PM
Reply: