PIX - vpn lan-to-lan

Discussion in 'Cisco' started by Allie, Sep 28, 2004.

  1. Allie

    Allie Guest

    I searched cisco/google and cannot find any example/reference to my
    situation. I don't know if it can be done.

    Scenario:

    PIX 515 ver. 6.2(2) (will update if necessary) will have a VPN lan-2-lan
    connection to a router (Cisco) at a customer location.

    Access has to be limited to one machine/IP on my side and one machine/IP on
    the customer side. The machine on my side cannot be on my internal LAN.
    Since my PIX has 6 interfaces, can I put this machine on an interface with
    security 80 and allow it to access the customer machine? Can somebody give
    me a configuration example?

    I use NAT and PAT and may have to add VPN client access to the mix.

    Help greatly appreciated.

    Grace
     
    Allie, Sep 28, 2004
    #1
    1. Advertising

  2. In article <oj36d.124073$>,
    Allie <> wrote:
    :pIX 515 ver. 6.2(2) (will update if necessary) will have a VPN lan-2-lan
    :connection to a router (Cisco) at a customer location.

    :Access has to be limited to one machine/IP on my side and one machine/IP on
    :the customer side. The machine on my side cannot be on my internal LAN.
    :Since my PIX has 6 interfaces, can I put this machine on an interface with
    :security 80 and allow it to access the customer machine?

    Yes. The configuration would likely be barely different than what you
    have. The configuration of the outside interface and the crypto maps
    would barely change; the configuration of the other interfaces may
    change a little.

    If the client is to be able to initiate connections back to you
    (even if just DNS), then the easiest way to proceed would be to add
    a static (dmz, outside) statement that forces a particular mapping
    from the DMZ IP to the IP as known to the customer. For example,

    static (dmz, outside) 64.65.66.67 192.168.123.45 0 0

    for the case where you want the customer to send to 64.65.66.67
    and have the packets delivered to your dmz machine 192.168.123.45 .
    You probably do NOT want to use identity NAT (where the internal
    and external IPs are the same) as your inside interface is probably
    already set to use that address range, so getting that IP untranslated
    over to the other interface would require a 'route' statement and
    a router on the internal interface. Easier to use NAT.

    Ensure that the ACL you are applying against the outside interface
    includes the customer access, written exactly as if the access was
    going to be for an inside machine -- the ACL applied to the outside
    does not need to know which machine on which internal interface will
    handle packets, as the outside ACL is logically processed -before- NAT.
    [The reality is more complex than that.]

    Write a new ACL and apply it (via 'access-group ACLNAME in interface dmz')
    to the dmz interface. That ACL should permit only the traffic to the
    client.

    If you do not have an ACL against the inside (security 100) interface,
    you are going to have to add one, or else the hosts on the inside
    interface may be able (in some configurations) to start connections to
    host on the DMZ interface. Your message implied that one machine should only
    talk to the client and not at all to your other machines. You can,
    though, skip this ACL if you are *not* using
    'nat (inside) 0 access-list' -- if you are not using that, and you
    do not add static (inside, dmz) statements, then the inside interface
    will not be able to communicate with the dmz machine unless you have
    a global (dmz) POLICYNUMBER statement where the POLICYNUMBER
    matches a nat (inside) POLICYNUMBER statement. But it's better practice
    to be explicit about blocking unwanted access, instead of supposing
    that no-one will ever add in that global (dmz) "trying to be helpful"
    or as more dmz machines get added.


    That's about it. Just static'ing to the dmz interface, adding the
    acl against the dmz interface, and adjusting the ACLs on all your
    other internal interfaces to prevent any unwanted internal traffic
    to the new machine. It's fairly simple.

    Ah, a point while I remember: the access-list that you have
    in your 'match address' for your crypto map, should use the IP address
    as known to the client as the source IP, *not* the internal IP address.

    --
    Rome was built one paycheck at a time. -- Walter Roberson
     
    Walter Roberson, Sep 28, 2004
    #2
    1. Advertising

  3. Allie

    Allie Guest

    Walter, thank you so much for confirming the solution. I needed to know
    before tomorrow if it could be done. The actual implementation is a few
    weeks away so now I can work on configuration.

    Thanks a lot for your advice. It's always invaluable - while researching my
    problem I went thru a lot of your posts where you advised other PIX users
    and it was the greatest learning experience.

    Grace

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cjahgf$i9$...
    > In article <oj36d.124073$>,
    > Allie <> wrote:
    > :pIX 515 ver. 6.2(2) (will update if necessary) will have a VPN lan-2-lan
    > :connection to a router (Cisco) at a customer location.
    >
    > :Access has to be limited to one machine/IP on my side and one machine/IP

    on
    > :the customer side. The machine on my side cannot be on my internal LAN.
    > :Since my PIX has 6 interfaces, can I put this machine on an interface

    with
    > :security 80 and allow it to access the customer machine?
    >
    > Yes. The configuration would likely be barely different than what you
    > have. The configuration of the outside interface and the crypto maps
    > would barely change; the configuration of the other interfaces may
    > change a little.
    >
    > If the client is to be able to initiate connections back to you
    > (even if just DNS), then the easiest way to proceed would be to add
    > a static (dmz, outside) statement that forces a particular mapping
    > from the DMZ IP to the IP as known to the customer. For example,
    >
    > static (dmz, outside) 64.65.66.67 192.168.123.45 0 0
    >
    > for the case where you want the customer to send to 64.65.66.67
    > and have the packets delivered to your dmz machine 192.168.123.45 .
    > You probably do NOT want to use identity NAT (where the internal
    > and external IPs are the same) as your inside interface is probably
    > already set to use that address range, so getting that IP untranslated
    > over to the other interface would require a 'route' statement and
    > a router on the internal interface. Easier to use NAT.
    >
    > Ensure that the ACL you are applying against the outside interface
    > includes the customer access, written exactly as if the access was
    > going to be for an inside machine -- the ACL applied to the outside
    > does not need to know which machine on which internal interface will
    > handle packets, as the outside ACL is logically processed -before- NAT.
    > [The reality is more complex than that.]
    >
    > Write a new ACL and apply it (via 'access-group ACLNAME in interface dmz')
    > to the dmz interface. That ACL should permit only the traffic to the
    > client.
    >
    > If you do not have an ACL against the inside (security 100) interface,
    > you are going to have to add one, or else the hosts on the inside
    > interface may be able (in some configurations) to start connections to
    > host on the DMZ interface. Your message implied that one machine should

    only
    > talk to the client and not at all to your other machines. You can,
    > though, skip this ACL if you are *not* using
    > 'nat (inside) 0 access-list' -- if you are not using that, and you
    > do not add static (inside, dmz) statements, then the inside interface
    > will not be able to communicate with the dmz machine unless you have
    > a global (dmz) POLICYNUMBER statement where the POLICYNUMBER
    > matches a nat (inside) POLICYNUMBER statement. But it's better practice
    > to be explicit about blocking unwanted access, instead of supposing
    > that no-one will ever add in that global (dmz) "trying to be helpful"
    > or as more dmz machines get added.
    >
    >
    > That's about it. Just static'ing to the dmz interface, adding the
    > acl against the dmz interface, and adjusting the ACLs on all your
    > other internal interfaces to prevent any unwanted internal traffic
    > to the new machine. It's fairly simple.
    >
    > Ah, a point while I remember: the access-list that you have
    > in your 'match address' for your crypto map, should use the IP address
    > as known to the client as the source IP, *not* the internal IP address.
    >
    > --
    > Rome was built one paycheck at a time. -- Walter Roberson
     
    Allie, Sep 28, 2004
    #3
  4. In article <9%36d.124438$>,
    Allie <> wrote:
    :Walter, thank you so much for confirming the solution. I needed to know
    :before tomorrow if it could be done.

    There's a proviso I should add to my "It's simple" solution.

    You did not give any indication of what kind of traffic would be
    flowing between the dmz machine and the client. Some kinds of traffic
    do not work at all well with NAT. NETBIOS between peer PDCs (Primary
    Domain Controllers) is probably the example most often encountered.

    That is the only NAT problem that I have myself encountered, but
    I have seen some discussions in which people whose opinion I respect
    have said that NAT has a *lot* of problems when you look closely.
    My recollection is that Melinda Shore in particular took that position
    a few months ago (possibly in comp.security.misc).

    NAT problems are more likely in multimedia and multicasting.
    If, though, you are just doing standard ftp/smtp/rlogin/ssh/http kind
    of work, then NAT is not likely to give you any grief on PIX.
    --
    If a troll and a half can hook a reader and a half in a posting and a half,
    how many readers can six trolls hook in six postings?
     
    Walter Roberson, Sep 28, 2004
    #4
  5. Allie

    Allie Guest

    Currently, I have this connection working thru VPN Lan-2-Lan between Cisco
    VPN 3005 and a customer's router. Things are changing, we are becoming part
    of a corporate WAN and I have to remove the internal PC from my LAN but I
    need to provide connectivity some other inexpensive way. So, I am looking
    at PIX.

    The traffic between the two machines will be data transfer: map drive from
    machine in dmz to a share on a customer machine (net use *
    \\ipaddress\share), copy data to the dmz machine, may need to use VNC for
    remote troubleshooting. So, should I expect NAT problems? And do I need to
    use NAT for the dmz machine? On the VPN 3005 it's not NATed. The remote
    subnets are different. Sorry if I sound like an idiot but I reconfigure
    these things very seldom so it's a learning curve all over.

    Grace

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:cjajf7$2hc$...
    > In article <9%36d.124438$>,
    > Allie <> wrote:
    > :Walter, thank you so much for confirming the solution. I needed to know
    > :before tomorrow if it could be done.
    >
    > There's a proviso I should add to my "It's simple" solution.
    >
    > You did not give any indication of what kind of traffic would be
    > flowing between the dmz machine and the client. Some kinds of traffic
    > do not work at all well with NAT. NETBIOS between peer PDCs (Primary
    > Domain Controllers) is probably the example most often encountered.
    >
    > That is the only NAT problem that I have myself encountered, but
    > I have seen some discussions in which people whose opinion I respect
    > have said that NAT has a *lot* of problems when you look closely.
    > My recollection is that Melinda Shore in particular took that position
    > a few months ago (possibly in comp.security.misc).
    >
    > NAT problems are more likely in multimedia and multicasting.
    > If, though, you are just doing standard ftp/smtp/rlogin/ssh/http kind
    > of work, then NAT is not likely to give you any grief on PIX.
    > --
    > If a troll and a half can hook a reader and a half in a posting and a

    half,
    > how many readers can six trolls hook in six postings?
     
    Allie, Sep 28, 2004
    #5
    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. GVB
    Replies:
    1
    Views:
    2,873
    Martin Bilgrav
    Feb 6, 2004
  2. Chris Kranz

    LAN-to-LAN involving PIX and VPN

    Chris Kranz, Aug 23, 2005, in forum: Cisco
    Replies:
    3
    Views:
    1,292
    Walter Roberson
    Aug 23, 2005
  3. Svenn
    Replies:
    3
    Views:
    755
    Svenn
    Mar 13, 2006
  4. wmmalii
    Replies:
    0
    Views:
    3,203
    wmmalii
    May 17, 2006
  5. elinor
    Replies:
    2
    Views:
    1,813
    elinor
    Nov 16, 2006
Loading...

Share This Page