VPN Concentrator Behind PIX?

Discussion in 'Cisco' started by sefoca, Dec 4, 2004.

  1. sefoca

    sefoca Guest

    We are installing a VPN 3030 Concentrator.

    We have a pix 515 which is our only access to the internet. (No routers).

    I see that I can put the VPN 3000 behind the Pix, and I would like to do
    this.

    I can't find any documentation for this on cisco.com. It's all Concentrator
    to Network Device, instead of Concentrator through Network Device.

    Anyway, I'm wondering what conduits / acl permits I need to put on the Pix.

    I'm also a little confused by the routing.

    Here is my setup

    Pix e0 64.64.64.1 --- Pix e1 192.168.10.1

    VPN Pub: 64.64.64.3 --- VPN Priv 192.168.10.3

    There is a default route on the VPN to 64.64.64.1, and I can ping the
    internet from the VPN.

    But my users cannot connect to the VPN.

    Do I need a tunnel route? Or a route on the Pix to ... where?

    Thank you.
     
    sefoca, Dec 4, 2004
    #1
    1. Advertising

  2. sefoca

    sefoca Guest

    A thought just occurred to me:

    If my VPN (64.64.64.3) is inside the PIX, do I need to do a static nat for
    it?

    Or just permit various vpn protocols to get to the vpn host? (In which
    case, I think I would need some sort of route statement on the pix?

    Oh well, thanks again.

    Confused


    "sefoca" <> wrote in message
    news:coth8k$...
    > We are installing a VPN 3030 Concentrator.
    >
    > We have a pix 515 which is our only access to the internet. (No routers).
    >
    > I see that I can put the VPN 3000 behind the Pix, and I would like to do
    > this.
    >
    > I can't find any documentation for this on cisco.com. It's all

    Concentrator
    > to Network Device, instead of Concentrator through Network Device.
    >
    > Anyway, I'm wondering what conduits / acl permits I need to put on the

    Pix.
    >
    > I'm also a little confused by the routing.
    >
    > Here is my setup
    >
    > Pix e0 64.64.64.1 --- Pix e1 192.168.10.1
    >
    > VPN Pub: 64.64.64.3 --- VPN Priv 192.168.10.3
    >
    > There is a default route on the VPN to 64.64.64.1, and I can ping the
    > internet from the VPN.
    >
    > But my users cannot connect to the VPN.
    >
    > Do I need a tunnel route? Or a route on the Pix to ... where?
    >
    > Thank you.
    >
    >
     
    sefoca, Dec 4, 2004
    #2
    1. Advertising

  3. In article <cothi2$>, sefoca <> wrote:
    :A thought just occurred to me:

    :If my VPN (64.64.64.3) is inside the PIX, do I need to do a static nat for
    :it?

    Or equivilent, such as nat 0 access-list . A VPN concentrator is
    a "server", and you have to tell the PIX -somehow- to allow the
    packets to get to the right place. That's a two-part job in PIX:
    configuring the ACLs to permit the packets, and configuring the PIX
    to get the packets through to the right internal machine.


    :Or just permit various vpn protocols to get to the vpn host? (In which
    :case, I think I would need some sort of route statement on the pix?

    Ummm, are you talking about the IPSec or PPTP traffic -to- the
    VPN concentrator [i.e., the tunneled traffic], or are you talking
    about what happens after that traffic is de-encapsulated?


    To answer your question of what to let through: it depends on which
    types of VPN you want to support. Normal IPSec uses the ESP IP protocol
    (it's not a port, it's a protocol just as 'tcp' is a protocol),
    and uses UDP port 500 (isakmp), and may use the AH IP protocol
    if you have configured for AH.

    If you have configured support for IPSec NAT-T (NAT Traversal), then
    you need UDP port 500 (isakmp), and UDP port 4500, and an additional
    port may be dynamically opened; in this situation, the ESP and AH
    protocols do not need to be accessible [but if ESP is accessible then
    ESP packets will go directly; if you have configured IPSec to request
    AH, then if you have NAT-T turned on, then the AH protocol will be used
    only if the protocol is reachable and there is no NAT anywhere along
    the route [AH and NAT are philosophically incompatible.]

    The original implimentation of NAT-T used UDP port 10000 instead
    of UDP port 4500, so you will see that sometimes.

    If you are using L2TP, then because L2TP is layered on top of
    IPSec, the requirements are as indicated above.

    If you are using PPTP, then my recollection is that you need
    UDP port 500 (isakmp) and the IP protocol GRE.


    NB: the IP protocols ESP and GRE will work with one-to-one NAT,
    but [in the absence of NAT-T support] the IP protocol AH will only
    work if there is no address translation (the public IP is the
    same as the private IP.) In the absence of NAT-T support, PIX 6.3
    can be configured to support *one* PAT'd VPN tunnel -through- the PIX...
    but if you activate that feature then you cannot have any VPN tunnels
    ending -at- the PIX.
    --
    And the wind keeps blowing the angel / Backwards into the future /
    And this wind, this wind / Is called / Progress.
    -- Laurie Anderson
     
    Walter Roberson, Dec 5, 2004
    #3
  4. sefoca

    John Smith Guest

    just a little fyi, cisco's official recommendation is to place the
    concentrator in parallel with the pix... the external int. of the conc. will
    have a public ip (just like the pix) and the internal interface of the conc.
    will be connected to a dmz interface of the pix. this way , those coming
    thru on the vpn can still be firewalled...

    "sefoca" <> wrote in message
    news:coth8k$...
    > We are installing a VPN 3030 Concentrator.
    >
    > We have a pix 515 which is our only access to the internet. (No routers).
    >
    > I see that I can put the VPN 3000 behind the Pix, and I would like to do
    > this.
    >
    > I can't find any documentation for this on cisco.com. It's all
    > Concentrator
    > to Network Device, instead of Concentrator through Network Device.
    >
    > Anyway, I'm wondering what conduits / acl permits I need to put on the
    > Pix.
    >
    > I'm also a little confused by the routing.
    >
    > Here is my setup
    >
    > Pix e0 64.64.64.1 --- Pix e1 192.168.10.1
    >
    > VPN Pub: 64.64.64.3 --- VPN Priv 192.168.10.3
    >
    > There is a default route on the VPN to 64.64.64.1, and I can ping the
    > internet from the VPN.
    >
    > But my users cannot connect to the VPN.
    >
    > Do I need a tunnel route? Or a route on the Pix to ... where?
    >
    > Thank you.
    >
    >
     
    John Smith, Dec 5, 2004
    #4
  5. sefoca

    sefoca Guest

    Thank you for the reply.


    "> :If my VPN (64.64.64.3) is inside the PIX, do I need to do a static nat
    for
    > :it?
    >
    > Or equivilent, such as nat 0 access-list . A VPN concentrator is
    > a "server", and you have to tell the PIX -somehow- to allow the
    > packets to get to the right place. That's a two-part job in PIX:
    > configuring the ACLs to permit the packets, and configuring the PIX
    > to get the packets through to the right internal machine.
    >


    I guess my confusion is this: I do not have a 3rd card (DMZ) in the pix.

    Is there a way to put the concentrator behind the pix if the pix just has
    public and private interfaces?

    I should have spelled that out previously, I'm sorry.

    The problem is, if I assign a public IP to the vpn concentrator, I don't see
    how I can do a static nat for that same IP on the pix. The statement would
    be something like "static (inside,outside) 64.64.64.3 64.64.64.3".
     
    sefoca, Dec 5, 2004
    #5
  6. sefoca

    sefoca Guest

    "John Smith" <> wrote in message
    news:...
    > just a little fyi, cisco's official recommendation is to place the
    > concentrator in parallel with the pix... the external int. of the conc.

    will
    > have a public ip (just like the pix) and the internal interface of the

    conc.
    > will be connected to a dmz interface of the pix. this way , those coming
    > thru on the vpn can still be firewalled...


    Thanks, I didn't realize that was the recommendation. I've seen marketing
    material that says you can put the thing just about anywhere -- outside,
    inside, parallel....

    Unfortunately, I only have two cards in the pix. It's a 515 so I have space
    for a DMZ, I just need to get the concentrator in place for the time being.

    Thanks again.
     
    sefoca, Dec 5, 2004
    #6
  7. sefoca

    John Smith Guest

    btw, that recommendation is taken directly from the CCSP CSVPN coursebook...

    "sefoca" <> wrote in message
    news:couvr6$...
    >
    > "John Smith" <> wrote in message
    > news:...
    >> just a little fyi, cisco's official recommendation is to place the
    >> concentrator in parallel with the pix... the external int. of the conc.

    > will
    >> have a public ip (just like the pix) and the internal interface of the

    > conc.
    >> will be connected to a dmz interface of the pix. this way , those coming
    >> thru on the vpn can still be firewalled...

    >
    > Thanks, I didn't realize that was the recommendation. I've seen marketing
    > material that says you can put the thing just about anywhere -- outside,
    > inside, parallel....
    >
    > Unfortunately, I only have two cards in the pix. It's a 515 so I have
    > space
    > for a DMZ, I just need to get the concentrator in place for the time
    > being.
    >
    > Thanks again.
    >
    >
     
    John Smith, Dec 5, 2004
    #7
  8. sefoca

    sefoca Guest

    Well, here's what I did.

    When you said the concentrator was essentially a server, I realized that it
    might be possible to treat it thus.

    I unplugged the outside interface of the concentrator.

    I did a static translation of the inside interface.

    I allowed the protocols you mentioned.

    conduit permit gre host 64.---.---.3 any (hitcnt=67)
    conduit permit esp host 64.---.---.3 any (hitcnt=521722)
    conduit permit ah host 64.---.---.3 any (hitcnt=0)
    conduit permit udp host 64.---.---.3 eq isakmp any (hitcnt=9)
    conduit permit udp host 64.---.---.3 eq 10000 any (hitcnt=0)

    And it works. Sort of.

    Most of the people connecting are behind a 3002 VPN HW Client.

    They are now able to connect to the concentrator well enough to get out to
    the internet.

    (These 3002s advertise split tunneling, but if their head-end (the
    concentrator) goes down, then they go down.)

    I am still not able to ping the remote 3002s. I suspect I need a route
    statement on the pix.

    Here's what I have:

    PIX# sh route
    outside 0.0.0.0 0.0.0.0 64.---.---.1 1 OTHER static
    outside 64.---.---.0 255.255.255.248 64.---.---.2 1 CONNECT static
    inside 192.168.10.0 255.255.255.0 192.168.10.1 1 CONNECT static

    I *think* I need another outside route that tells my computers here how to
    reach the remote clients. I'm not sure if I need to point it to the
    internal address of the VPN concentrator, or the NATted address of the VPN
    concentrator.

    I guess I'll try both after hours and see what happens.

    Thanks again for your input.
     
    sefoca, Dec 5, 2004
    #8
  9. In article <couvn4$>, sefoca <> wrote:
    :I guess my confusion is this: I do not have a 3rd card (DMZ) in the pix.

    :Is there a way to put the concentrator behind the pix if the pix just has
    :public and private interfaces?

    Certainly possible.


    :The problem is, if I assign a public IP to the vpn concentrator, I don't see
    :how I can do a static nat for that same IP on the pix. The statement would
    :be something like "static (inside,outside) 64.64.64.3 64.64.64.3".

    You can static an IP to itself; PIX refers to that as "Identity NAT".
    It has the effect of sayin "This IP address is on the inside, and it
    is okay to allow new connections to be made to it, provided those
    connections satisfy the ACLs."

    What you need to watch out for is that the PIX does not allow two
    interfaces to have the same IP address range. As I have posted
    the work-arounds for this before, I'll just point you to them rather
    than retyping them:

    http://groups.google.ca/groups?selm=br5nb8$p2i$


    --
    Take care in opening this message: My grasp on reality may have shaken
    loose during transmission!
     
    Walter Roberson, Dec 5, 2004
    #9
  10. In article <covi34$>, sefoca <> wrote:
    :Well, here's what I did.

    :When you said the concentrator was essentially a server, I realized that it
    :might be possible to treat it thus.

    :conduit permit gre host 64.---.---.3 any (hitcnt=67)

    :And it works. Sort of.

    Sorry, I don't debug configurations that include conduits. As soon as
    Cisco started allowing ACLs access-group'd to interfaces, they started
    discouraging conduits, and within a few subreleases they started
    officially saying that conduits were deprecated. That was in 5.3(2) if
    my memory serves. There were some bugs in the interaction of conduits
    and ACLs that Cisco -tried- to fix in the 5 series releases. By the
    time of 6.0, Cisco started running into bigger problems with conduits
    not working properly with new features, which they worked on through
    6.0 (which didn't last very long). By 6.1(1) Cisco started admitting
    there were substantial bugs with conduits, and by 6.2(1), gave notice
    that conduits were not going to be supported in 7.x and that Cisco was
    no longer going to try to fix the conduit problems.

    It is my philosophy that there is no point in taking time to try
    to debug problems with conduit configurations when the problems might
    be due to long-standing bugs in the implimentation that won't be fixed.
    And 7.x with no conduit support will be out Real Soon Now (they are
    now quite a bit behind on releasing it; it went into beta testing
    at the beginning of the year.)
    --
    When your posts are all alone / and a user's on the phone/
    there's one place to check -- / Upstream!
    When you're in a hurry / and propagation is a worry/
    there's a place you can post -- / Upstream!
     
    Walter Roberson, Dec 5, 2004
    #10
  11. In article <couvr6$>, sefoca <> wrote:

    :"John Smith" <> wrote in message
    :news:...
    :> just a little fyi, cisco's official recommendation is to place the
    :> concentrator in parallel with the pix... the external int. of the conc.
    :will
    :> have a public ip (just like the pix) and the internal interface of the
    :conc.
    :> will be connected to a dmz interface of the pix. this way , those coming
    :> thru on the vpn can still be firewalled...

    :Unfortunately, I only have two cards in the pix. It's a 515 so I have space
    :for a DMZ, I just need to get the concentrator in place for the time being.

    If you are using the PIX 6.3 software release, then your 515 will
    support "logical interfaces", which is a virtual interface with a different
    IP address range placed onto a physical interface. You can have
    several logical interfaces with different IP ranges on the same physical
    interface. In order for this to work, though, you have to have
    a router or switch with IEEE 802.1Q VLAN support: each logical
    interface corresponds to a different tagged VLAN.
    --
    Any sufficiently advanced bug is indistinguishable from a feature.
    -- Rich Kulawiec
     
    Walter Roberson, Dec 5, 2004
    #11
  12. sefoca

    verne Guest

    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Gorsuch

    Pix-to-Pix VPN - BOTH BOXES BEHIND NAT!!!

    Michael Gorsuch, Oct 23, 2003, in forum: Cisco
    Replies:
    1
    Views:
    1,677
    Walter Roberson
    Oct 24, 2003
  2. Corbin O'Reilly
    Replies:
    2
    Views:
    3,226
    Corbin O'Reilly
    May 26, 2004
  3. Kai
    Replies:
    0
    Views:
    7,678
  4. Tomi
    Replies:
    3
    Views:
    1,959
  5. John Strow
    Replies:
    1
    Views:
    507
Loading...

Share This Page